Planning work for the next iteration is a basic activity within iterative software development. A group responsible for the product and business strategy prepares a list of prioritized items describing what should be done, while a development team provides an estimate on how many of these work items can be finalized during the iteration.
Early Scrum books (e.g., Agile Development with Scrum) teach that the software development process is highly empirical and cannot simply be reduced to a set of mathematical formulas. As a result, any attempt to derive a precise, long-term schedule with a detailed work path from any technical architecture will inevitably fail. Instead, a team should observe and measure progress while the work rolls out and, based on observation, adjust their plans and create a forecast for the future.
There are two general approaches to building an estimate. In the first, the team estimates the size of the work items (e.g., user stories and use cases). At the end of the iteration, the team sums up estimates for all delivered items. The resulting number is called the velocity. After a few sprints the team may start calculating an average velocity based on results from the past. The only available conclusion is that the team is able to do on average K work items per iteration. The team performs no assessments in respect of comparing the planned and delivered items.
In the second approach, as in the first, the team estimates the work items. However, they also commit to a number of work items they believe they can finish within an iteration. The team not only measures the velocity but also compares it to the their declared commitment. The goal is to minimize the discrepancy between the team's commitment and velocity.
In the first approach, the team members measure only how much they can deliver. But, what if the team struggles to deliver anything at all? Finishing even one user story might be challenging, especially for agile software development newbies. Some teams end up in a permanent cycle of over-commitment preceded by a few sprints without any tangible results. During these situations, should you (as a team member, a team coach, or a manager) only keep measuring the team’s velocity? Do the team members fully embrace their work if they deliver only every second or third sprint, leaving the other sprints empty? My answer to both these questions is no.
About the author
Aleksander Brancewicz helps agile teams achieve outstanding results. In his career he has coached teams comprising of agile newbies as well as very experienced agile team members. Besides agile team building his areas of interest are new media product management and software architecture. He lives together with his wife and daughter in Amstelveen in the Netherlands.
