Friday, March 15, 2013

Know the Scrum Basics: Get Your Velocity Right


This month, Scrum Inc.’s monthly webinar focuses on fundamentals and correcting bad Scrum habits. While a majority of us feel like we get the basics right, Scrum Inc. surveys and independent polls find that while most Teams understand the basics, many skip at least one key practice.

Most commonly, respondents indicate that their teams don’t calculate Velocity. Without Velocity, there is no way to measure improvement, have transparency and visibility into your process or properly plan a Sprint or a release.

How it Works

Break work into small Product Backlog Items. Give these PBIs, often called User Stories, a point value by estimating their relative sizes. (Relative size is important because studies show that humans are incredibly poor at estimating jobs in hours.)


During Sprint Planning, the Scrum Master plays dealer in a game of planning poker. The Scrum Master starts the game by taking a User Story and having all members of Team chose a card with a number they believe relates the relative size of the work to be done. The Scrum Master counts to three and all Team members reveal their cards simultaneously. The Team members with the lowest and highest cards debate the reasons for their choices and then the team plays another round. The process repeats until a consensus is reached. Continue the game until the all User Stories have a point value.  

During the Sprint, as each story is moved to done, the Scrum Master can plot the points over the length of the Sprint. At the end of the Sprint, add the point values of all the User Stories together to calculate your Velocity.

As the Team completes more and more Sprints, the Scrum Master can compare how much the Team has improved. Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint.

Remember, just because the team has gotten better at implementing any given story, the point value you should remain the same. If the Team starts to estimate stories at lower values because they have incurred substantially more experience and the stories seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work. 

Teams shouldn’t obsess about how many points something is worth. Estimating points is just an exercise to help quickly evaluate relative effort. The important thing is that you are consistent and that the entire team has a common understanding of their system for sizing.

Whether you are new to Scrum or a long time practitioner, getting the basics right will definitely improve your Velocity. On Tuesday, March 26th we will be exploring Velocity, Retrospectives, Backlog Grooming and the rest of the Scrum Fundamentals. Please join us.

-- Joel Riddle & Christine Hegarty

8 comments:

azinczuk said...

Great post. You cannot improve if your basics fail.
I've got a question, how to ensure that Team, after several sprint when feels much more comfortable with product, won't estimate tasks lower than few sprint before? What techniques do you use? I use estimates for already done stories during every story workshop/ estimation and ask teams to how new stories compare to already done.
What else I can do?

World as seen by Axvia said...

In this blog you start with user story and then switch to task. User Stories are estimated using points. Once user story is broken down in to tasks, the task can be estimated in hours. Usually tasks are fine grained activities required to reach the definition of done for a user story. Keeping tasks small, for example max 12 hours, simplifies progress tracking and impediments spoting. Good blog. Anurag

Jeff Sutherland said...

This was an error to mention task and it has been corrected. We never estmate anything in hours. See http://scrum.jeffsutherland.com/search?q=better+than+hours - points are stable over time when reference stories are kept stable. This causes velocity to increase. With hours it is impossible to accurately measure velocity and evaluate process improvement.

Jeff Sutherland said...

The Scrum Master is responsible for improving the performance of the team. This is acceleration, not velocity. The Product Owner is responsible for improving revenue per point. If either falls down on the job, the Scrum is not working. If you don't know velocity you can't tell what is not working and noone is accountable.

Jeff Sutherland said...

Ilja Preuß left this comment:

Wow, suggesting that Velocity should be your primary measure of improvement is so wrong on so many levels:

- velocity is not a metric of how much value is produced. Creating more crap faster really is not much of an improvement, is it?

- it's easy to imagine an improvement that would significantly decrease velocity - such as making the Definition of Done more complete.

- using Velocity as a motivating metric opens it up for misuse and gaming - and threatens its value as a prediction and project management tool.

Velocity is a great metric if you want to predict the future. It can be of good help in analyzing the effects of changes. Using it as the main indicator for improvement, and setting expectations on how it should "improve" might sound appealing on the surface, but really looks quite harmful to me.

Vikas Kakkar said...

I completely agree with this article. Great Article

Vikas Kakkar said...

I want to check! Does Jeff Sutherland agree with what Ilja Preuß has said? This seems opposite to what he himself has posted in post below

"This was an error to mention task and it has been corrected. We never estmate anything in hours. See http://scrum.jeffsutherland.com/search?q=better+than+hours - points are stable over time when reference stories are kept stable. This causes velocity to increase......"

Jeff Sutherland said...

I posted Ilya comment to generate discussion, not because I agree with all that he said. First, go to ScrumLab.scruminc.com and look at the Metrics webinars. It shows how we measure company performance using improvement in velocity, the happiness metric, and the revenue per point.

I hear so many slow teams complaining that going faster will just generate more crap. This is because Product Owners are not held accountable for doubling revenue per point.

If you double velocity and double revenue per point the company will generate four times more money. This will make everyone happy. That is why you need the three metrics.