Scalable Agile Estimation and Normalization of Story Points: Introduction and Overview of the Blog Series (Part 1 of 5)

Agile estimation topics such as relative size effort estimation in story points and velocity based on story points are well-known.  Relative size estimation done as a team effort leads to improved shared understanding of stories.  It takes less time than estimating effort in time units (ideal hours or idea days).  Relative size estimates in story points are more stable than estimates done in time units.  Estimating agile project duration and costs based on backlog size in story points, velocity and cost per story point are well covered in many agile books, training and certification programs.  Agile estimates are estimates, and not commitments or contracts.  When used correctly, estimates help agile planning process.  When used inappropriately, agile estimates are prone to gaming and misuse.  Many agile textbooks offer good introduction to relative size estimation, story points, velocity and related concepts.  If you are not familiar with them, I recommend reading Agile Estimating and Planning book by Mike Cohn.

As agile projects need to scale up from a single team agile project to a multi-team (team of teams) agile program to an agile portfolio of coordinated agile programs to an entire agile enterprise managing a set of coordinated agile portfolios, agile estimation becomes much more challenging.  We need appropriate estimation methods that can scale up to handle large agile projects consisting of several tens of agile teams involving several hundreds of team members. Scalable agile estimation methods are required to provide estimates at the team, program and portfolio levels. For scalable agile estimation methods to work properly, story points across the space dimension (teams, epic hierarchies, feature group hierarchies, goals, project hierarchies, programs, portfolios, etc.) as well as across the time dimension (sprints) need to have the same meaning and the same unit of measure.  In other words, story points need to be normalized so they represent the same amount of work across the space and time dimensions.

Figure 1: Agile estimation at the portfolio, program and team levels

There is often a need to roll-up lower team-level effort estimates (story point estimate representing the effort for an entire story consisting of tasks and tests) to program-level effort estimates (feature estimates, where a feature is a collection of stories) and to portfolio-level effort estimates (epic estimates, where an epic is a collection of features).   This is called bottom-up estimation and is shown with a bottom-up arrow in Figure 1.   However, during portfolio planning and program planning sessions, most lower story-level story estimates are not available; therefore, estimation effort needs to go top-down from the portfolio-level to program-level down to story-level.  This is called top-down estimation and shown with a top-down arrow in Figure 1.

The rest of this Part 1 summarizes what to expect in the blog series consisting of the remaining 4 parts (Parts 2 through 5).

In Part 2 of the blog series I will first review the key assumptions that must be satisfied for the traditional velocity-based planning to work properly.  I will then present three specific challenges associated with the traditional velocity-based planning, and will explain how those challenges are exacerbated as agile projects need to scale up.

In Part 3 of the blog series, I will present two existing and published scalable agile estimation methods and present my critique on those methods.

• Method 1: This method is covered by Mike Cohn in his Agile Estimating and Planning book.
• Method 2: The Scaled Agile Framework^® (pronounced SAFe™) developed by Dean Leffingwell is an interactive knowledge base for implementing agile practices at enterprise scale.  It is becoming popular for planning and developing large-scale agile projects.  I will present the story point normalization method used in SAFe.  This method is based on identifying a baseline story of 1 ideal developer day (1 IDD) effort by each team.  Therefore, I call this method “1-IDD Normalization Method” (1NM for short). 1NM not only assigns a standard amount of work for 1 story point for all teams, programs and portfolios, it also equates 1 story point to 1 ideal day of effort covering design, code development, testing, defect fixing work.  Unlike traditional story points which are unitless numbers, 1NM equates 1 ideal day of effort to 1 story point.   This becomes the basis for assigning common meaning to story points across different teams, programs and portfolios.
  [Full Disclosure:  I am a certified SAFe Program Consultant (SPC).]

In Part 4 of the blog series, I will present a scalable agile estimation method, called Calibrated Normalization Method (CNM).  I have developed, taught and applied CNM while working with clients in my agile training and coaching engagements since 2010.  CNM is a fully general method for story point normalization.   Its calibration process is based on calibrating the size of a 1-story point story by each team using a sample of up to 3 stories from its sprint backlog.    CNM was developed by me in 2010 well before the SAFe Academy started offering training and certification tests for SPC in 2012.  CNM has evolved and benefited from refinements based on the actual use and feedback from by clients since 2010.  Part 4 emphasizes the CNM bottom-up estimation (from teams to programs up to portfolios).

In Part 5 of the blog series, I will explain how CNM performs the top-down estimation (from portfolios to programs down to teams).    CNM estimates the scope of work at the portfolio and program levels without knowing lower-level story point details which are not available during portfolio or program planning sessions.  Clearly these estimates can only be rough as lower-level story point details are not available.   Rough estimates done during portfolio planning are later progressively elaborated and revised during program-level release planning and team-level sprint planning as more information becomes available about lower-level story points as well as teams’ actual measured velocity.  CNM uses a fractal (i.e., “self-similar”) approach in the progressive elaboration of estimates using normalized story points.

In Part 5, I will also compare and relate 1NM with CNM, and explain how CNM fully address all three specific challenges to be explained in Part 2.     1NM can be thought of as a special case of CNM.  CNM is a fully general method for story point normalization, supporting both top-down and bottom-up estimation efforts.  Although CNM is independent of SAFe, it can be easily used in conjunction with SAFe.   I will also provide an Excel-based template for story point normalization math required to support CNM.

Stay tuned for Parts 2 through 5 of this blog series.  You don’t need to be a SAFe-expert to understand the blog series, as I will explain 1NM (SAFe’s normalization method).

At the end of Part 5, I will make available a single file version (as a PDF document) of this 5-part blog series.

Acknowledgements: I have greatly benefited from discussions and review comments on this blog series from my colleagues at VersionOne, especially Andy Powell, Lee Cunningham and Dave Gunther.

Your feedback: I would love to hear from the readers of this blog either here or by e-mail (Satish.Thatte@VersionOne.com) or hit me on twitter (@smthatte).

Part 2: Estimation Challenges Galore! – published on 4 November 2013.

Part 3: Review of published scalable agile estimation methods – published on 7 November 2013.

Part 4: Calibrated Normalization Method for Bottom-Up Estimation – published on 18 November 2013.

Part 5: Calibrated Normalization Method for Top-Down Estimation – published on 2 December 2013.

The post Scalable Agile Estimation and Normalization of Story Points: Introduction and Overview of the Blog Series (Part 1 of 5) appeared first on VersionOne Blog.