Why Agile Product Planning Is Important

Most agile product planning revolves around the commitment of stories to an iteration. This specifically addresses how many stories, story points, or features can be completed in an iteration. Stories are estimated in points and a team's velocity is measured as the total number of successfully completed story points in an iteration. If the velocity is consistent, the team can estimate the stories that can be committed in future iterations.

This process can work well for single (or few) iteration estimations. But what happens when stakeholders require some longer term, multiple iteration estimations. Given a long list of priority features, how many of them will be completed 10 iterations out?

When I talked to agile practitioners and scrummasters, some of them were against this level of estimation. After all, the point of agile is to be able to prioritize features based on changing needs, so why bother even trying to estimate feature delivery over multiple iterations?

Point taken, but this line of thinking misses the point. Long term estimation doesn't imply a rigid, non-agile plan. The plans may change, but given your best estimation today, the stakeholder should have the right to know whether the complete product deliverable as visioned today can be delivered in a reasonable amount of time and cost.

This is really critical when development teams in a large enterprise want to adopt an agile development process. Enterprises invest in product development based on financial merits and other drivers and want time estimates for feature and product development. In addition, aligning the product deliverables with other needs such as marketing and sales requires estimates on deliverables and time lines.

So even though a team may be following an agile development process and allow stakeholders to adjust priorities, it's still important for the managers of these teams to adopt methodologies for estimating product deliverables and time lines.


  1. Mike Cohn often emphasizes that the point of velocity it release planning, not iteration planning.

    Since velocity is not highly consistent (if it is, you are probably inadvertently gaming the numbers), it is a poor tool for planning individual iterations.

    If you finished 20, 28, and 12 points in your last 3 iterations, you should be able to predict completing *about* 200 points worth in the next 10 iterations. However you should be less confident predicting you will complete ~40 points in your next two iterations.

    Cohn prefers commitment-based iteration planning to velocity-based iteration planning. I agree; In my experience, velocity-based iteration planning creates unrealistic expectations that velocity will stay constant from iteration to iteration, and creates incentives to game the system.

    (For more details, check out Cohn's book, Agile Estimation and Planning.)

  2. Thanks for sharing, I will bookmark and be back again
    Agile Process


Comments on this blog are moderated and we do not accept comments that have links to other websites.