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 tasks. Give these tasks, 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 task. 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
tasks have a point value.
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
5 comments:
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?
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
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.
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.
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.
Post a Comment