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 scrum masters, 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 a feature and product development. In addition, aligning the product deliverables with other needs such as marketing and sales requires estimates on deliverables and timelines.

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 timelines.

Updated: Learn more about agile continuous planning.