A Key Attribute to Scrum Project Planning: Determining Scrum Team Velocity

16 July 2013

Raj Kumar
British Airways plc


 
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.
 
Remember that available clock hours will always be fixed in a sprint, and the team knows straightaway how much time, in ideal hours, is available to them. However, the number of user story points worth of work that fit in a sprint may vary depending on the degree of complexity associated with the selected user stories in that particular sprint. This variation may be slightly higher for a new Scrum team; for an experienced Scrum team it will settle down to almost consistent user story points in each sprint, as the team gains more experience in estimating user stories in terms of user story points and tasks in clock hours.
 
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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Zach Bonaker, CSP,CSM,CSPO, 7/16/2013 9:44:29 AM
In general, I think I understand your article and the point being conveyed. This principle, I don't disagree with. However, a couple of your statements didn't sit well with me.

For your vocabulary words, I didn't understand the section in the article referencing a correlation between artifacts and a decision point. Nor do I understand what you mean by a correlation being logically correct... a correlation is simply that - a correlation. It doesn't indicate causation and regardless of whether it appears logically correct, a correlation is still a correlation. That section, to me, didn't seem to fit very well.

Your definition of product backlog is not one that I agree with. My perspective of the product backlog is that it is emergent: it describes emerging requirements and work to do - in ordered format, which may (or may not) be in business priority (because it isn't always possible to do so exactly).

Regarding story points, I further disagree that "the lower the number given by the team to a story, the more the team is confident about the estimate in clock hours." In fact, "clock hours" shouldn't really come into play for a team using relative estimation. Whether it be uncertainty, research, or any other aspect of "effort", the only thing that matters are the relative size of the numbers. In fact, that's the beauty of it - as points increase, we can become MORE confident that the story is growing in effort!

A final comment on story points: I don't understand why you recommend that, if a story exceeds 8 points, it should be broken down. A team's scale for using relative estimation should be dictating by the team. For example, I have a team that is very comfortable with 13 and 20 point stories because that size simply makes sense to them. Over 20, to this team, is a sign that the story is epic and cannot fit in a sprint. I recommend that teams are given room to adapt and fit a point scale that makes sense to them, rather than enforce a rule that "over 8 is too large." I think you'll find that teams do a great job of making relative estimation work according to their perception... and as servant-leaders, we should always encourage the team to self-organize and adapt to their needs, before stepping in to lead & coach.
Rex Lester, CSM, 7/17/2013 10:13:14 AM
You propose and interesting approach but don’t let the business trying to create the illusion of control, distract you from delivering value.

Given that many projects start with an incomplete backlog and items are often added once the Product Owner sees the product and adapts the product, its still not always easy to guess the release date. And once the team have estimated the tasks for a Sprint they are still a guess or number of aggregated guesses. Does that make it more accurate?

I think there may be less value in guessing and more in discussing the product vision and whether its really necessary to have to wait so long before the product can be released? Why not discuss a release after three sprints based on what's been done by then. That gives the business certainty, and valuable user feedback early on?
Raj Kumar, CSM, 7/19/2013 5:29:06 AM
Hello Zach, I appreciate you comments. I would like to address each of your point step by step. In the mean time, think from the perspective of a new Agile team which struggles to understand the very concept of user story point in its real sense and hence struggles to provide estimates. But you got to start from somewhere with the team and coach and guide them along the way so that everyone's understand of Agile and estimation process is consistent. Also think from the project sponsor's perspective, they want to see some visibility on plan, effort required which means cost and release date for some feature regardless of which process or methodology is being used to delivery the project. Agile should not be counter productive in terms of visibility both for team and management.

You must Login or Signup to comment.