Scrum‑Based Project Management and Estimation Practices in Nokia’s Mobile Development Team

This case study describes the author’s experience as the first Agile and Lean consultant at Nokia China in early 2012, observing that Nokia had experimented with Scrum since 2005‑2006 but had not fully standardized the practice across its loosely organized divisions.

The development organization was split into dozens of Scrum teams, with roughly 500 engineers in the feature‑phone software line, each managed by a Line Manager. Product owners belonged to a separate Product Management Team (PMT) and were not under the Line Manager’s authority. A diagram (Figure 1) illustrated the team hierarchy, where the Tech Lead also acted as Scrum Master and the PMT product manager served as Product Owner.

Each Scrum team followed an iterative workflow (Figure 2), supported by a dedicated continuous‑integration team. However, late‑stage integration problems and slow defect convergence indicated a “ScrumBUT” situation.

The narrative then shifts to a specific “Audio UI” sub‑team that had just completed a difficult sprint (“death march”). The team suffered low morale, inexperienced members, and tight deadlines for a new mobile phone project involving about 200 people across hardware, platform, and software groups over a ten‑month cycle.

Key project characteristics include long duration, large staff count, high quality requirements, and a massive legacy codebase (≈15 million lines of Symbian code). The Product Owner and Scrum Master had already produced an initial user‑story list with effort estimates expressed in person‑weeks, formatted as “As a user, I’d like to …”.

The author guided the team through re‑splitting the backlog into smaller stories, clarifying ambiguities, and designing a decoupled architecture (Figure 4) that isolates the new feature behind a proxy layer.

For estimation, the team adopted a point‑based method using the Fibonacci sequence and a custom “quick‑sort relative estimation” technique, resulting in 39 user stories totaling 126 points (Figure 5). The estimation deliberately excluded testing, code‑review, and unit‑test effort, based on the assumption that these activities scale proportionally with development work and do not affect the critical path.

The article also discusses why time‑based units are avoided, how to handle them if necessary (using short “ideal hours”), and emphasizes that the ultimate responsibility for realistic planning lies with the product manager.

In conclusion, the author stresses the importance of disciplined product‑owner driven backlog refinement, point‑based estimation, and vigilant project management to enable developers to write code happily.