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 cannot demonstrate improvement in team performance sprint over sprint. While the Scrum Guide avoids mentioning tooling to give teams flexibility, some practices are so useful they are almost universally applied. One of them is User Stories and the other is Velocity.
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
English 
French 
Spanish 
English