A Key Attribute to Scrum Project Planning: Determining Scrum Team Velocity
16 July 2013
The key motivation for this article came from the Scrum and Agile projects that I have been working on so far. I started in the Agile "space" almost five years ago as an Agile team software developer; now I'm a Certified ScrumMaster leading development teams and developing projects using Scrum and Agile practices.
Throughout this journey within Scrum and Agile practices, I have faced a key scenario again and again: Every project's business side needs to know from the development team how much time the given product backlog will take to deliver, and the development teams always struggle to provide accurate estimates.
This is an effort to put forward an approach to the Scrum and Agile community that will help businesses get what they want from the development team and development teams provide what they have been asked for, with high degree of accuracy on both sides. Remember that anything can happen in this world, and things can go against the plan; however, we still do planning, and planning based on data and facts always delivers a higher degree of certainty.
So let's start with the big picture. I have assumed that readers of this article are familiar with most Scrum and Agile vocabulary. However, as a refresher, the important ones here include product vision, product owner, product backlog, backlog items, business value, highest priority, user story, acceptance criteria, user story points, iteration planning, backlog grooming, iteration grooming, sprint planning, task breakdown, task estimation, team velocity, sprint burn-down chart, iteration burn-down chart, show and tell, sprint retrospective, and action mining. This is a big list, but I believe it is important to set the right context.
From the above vocabulary, I am going to pick just five entries: product backlog, user story, user story points, team velocity, and task estimation. These five entries can provide the full magic to the whole Scrum project. The philosophy and rules behind these five terms, if applied in their right spirit, will deliver what businesses need from a Scrum team and what a Scrum team can deliver to a Scrum project.
It's all about establishing a correlation between various artifacts or vocabulary words in order to get to a single decision point, and if the correlation is logically correct, then there is the chance of a high degree of accuracy. So there is a strong correlation among those select five terms. A product backlog is a high-level listing of business requirements in business-priority order; a user story elaborates a product backlog entry into low level-business requirements as multiple acceptance criteria; user story points are a collective measure of complexity, uncertainty, and effort as seen by the team at a high level, not in terms of of clock hours but as a number (1,2,3,5,8,13,40,100). The lower the number given by the team to a story, the more the team is confident about the estimate in clock hours; the higher the number, the more the risk of wrong estimates. So every effort should be made to break the user story to lowest possible level. Team velocity is the speed (rate) at which a team is able to deliver the user story points per sprint. Task estimates are the time the team needs to complete a task associated with that user story.
Now this needs an extra attention, because here is a catch. After a team has done the task breakdown for a given user story, the team is more comfortable in understanding that task and can better gauge how the task will be done hour by hour. Hence team is better positioned to estimate this task in actual clock hours. So let the team estimate each user story in story points as given above, based on what the team understands at that stage of project. When stories get a high number, further break them down to a level at which team can assign points between 1 and 8. This will give a better idea of how many story points this product backlog has, which is important in measuring team velocity. Then, before the start of each sprint (a.k.a. iteration) during sprint planning, let the team do a task breakdown and estimations for each task in actual clock hours, without thinking about the user story points until the total estimate in hours fills the available clock hours for that sprint.
It is highly likely that at the end of the sprint, the team might not be able to achieve all the estimated tasks. There could be many reasons, but that's OK. Over a couple of sprints, a basis for determining team velocity will be established, within the given number of hours for a sprint and how many story points are achievable by the team.
Now, as I mentioned above, the speed (rate) at which the team delivers story points in a sprint is the velocity achieved in that sprint, and over the period of a couple of sprints the actual team velocity can be easily worked out by averaging the previous sprint velocities. Once the team velocity has been established, it will be easier to accurately plan and align the product release time from both the business and the team perspective. As the team gains more experience, sprint by sprint, the trend is that once the team attains a sustainable velocity, the continuous effort made throughout the Scrum process increases the team's velocity, and teams start delivering more product backlog items per sprint, resulting in a highly productive Scrum team.
In this article I have tried to put in the right context and focus a science- and facts-based approach to determine team velocity by establishing a correlation between product backlog, user stories, user story points, and task estimation.
Before I conclude, it's worth mentioning here that, for a given product backlog, estimations for user stories in user story points will vary from one Scrum team to another. Hence each team velocity will also be different for a given product backlog. However, in good team spirit, such a comparison should be avoided. The historical data collected and complied at the organizational level, though, can become a solid foundation for management to get a high-level idea and figure out the effort to work, which can help in project budgeting and cost estimation.
I hope this article will help ease the whole Scrum project planning process. I would welcome any suggestions or feedback. Thanks for reading.
Current rating: 0 (0 ratings)