Agile Development

The Art of Scrum Planning

In traditional project management, the project plan – sometimes just called ‘The Plan’ – is the most important artifact of the entire project.  This is the single source of truth, the beacon amid a cloud of uncertainty that will clarify to stakeholders when each major milestone hits and the date by which – come hell and high water – we go to production.


In Scrum, planning takes on another meaning entirely.  Some snicker when Scrum and planning are brought up in the same sentence. “I plan to re-plan” says a popular t-shirt at a recent Agile conference. Yet, as much as we’d like to avoid being deterministic and pretend we can predict the future, business sponsors and product owners are going to need some idea of when a given product can hit the shelves. Marketing campaigns need to be aligned, strategic players need to be involved, messaging need to take place – often many months in advance. Simply stating that “we’ll know it when we get there”‘ is simply not acceptable.

So how does project release planning work using Scrum?

First, the team priotitizes the stories. There are a number of ways to prioritize the user stories, but ultimately this is the responsibility of the product owner. Business value is often a critical factor in this regard, but so are elements such as risk associated with the given story and dependencies on other stories. After prioritizing the user stories, the team has a good idea of the order in which the stories should be implemented.

Once the stories have been prioritized, the next step involves estimating the stories in terms of relative story points. This ensures that the team has a general idea of the effort required to implement a given story. Granted, this is not going to be a to-the-hour accurate estimate, but it will give the team a general idea of the effort required to implement each story.

Finally, the team will divide the total number of story points with the team’s historical velocity. For instance, if it is estimated that the total product backlog consists of some 60 story points and the team’s velocity is 15, it would be a fair estimate to state that the release would take 4 sprints for a product release. Now, it may be wise to add an additional hardening sprint to make sure documentation, lagging system test cases and other loose ends are tied up – but the overall estimate would be a fairly accurate one.

So what would be the duration of the project of this size? This would depend on the iteration length, but let’s say your sprint duration is two weeks. Given 4 sprints to work on the 60 story points and an additional hardening sprint, we’re looking at an overall duration of 10 weeks.

Is this going to be 100% accurate all the time? Like any estimate, this should be viewed as an educated guess and no guarantee. Nevertheless, for planning purposes, I am confident you will find this estimate to be just as accurate – if not more so – than the estimates typically provided in traditional waterfall processes.