After several sprints of FAILURE, the team decides to cut in half the stories it takes into the sprint.
I have worked with enough teams that are beginning with Scrum to estimate their beginning velocity fairly accurately. Most believe I am full of IT when I suggest this. So instead of taking my advice, they plan to fail.
Start with Velocity/2 RECURSIVELY
How would you define success and failure at the sprint level for a brand new (to Scrum) team/group. I try to make it very simple - we are successful if we achieve the sprint goal. Typically with new teams, the only goal is to accomplish the stories we've put into the sprint. So it's easy to define success - 6 stories put into the sprint, 6 stories done at the end of the sprint, and we have a success!
Invariably the team does NOT finish all 6 stories and so the result is NOT success or failure. That's so simple. Now if we keep track of this for a few sprints, and the product owner starts to care about team success - then the team will pick up upon the new trend and adjust behaviors. One significant behavioral change is when the team starts to reject "roll-over" stories and learns to slice stories into tiny valuable pieces. The result of this behavior is that story sizes get smaller, and along with that is pressure to become successful at the planning game - so they accept fewer and fewer stories and smaller and more manageable stories into the sprint. There attempted sprint velocity goes down - but their predictability goes way up. They turn failure into success. And success breeds more success!
So if you are wondering what your target velocity should be... have the team decide upon a number and take in HALF of that value for sprint 2. If you are successful - great you have a known predictable velocity - if not - divide by 2 AGAIN, and iterate.
See Also:
What is an Agile Transition Guide?
I have worked with enough teams that are beginning with Scrum to estimate their beginning velocity fairly accurately. Most believe I am full of IT when I suggest this. So instead of taking my advice, they plan to fail.
Start with Velocity/2 RECURSIVELY
How would you define success and failure at the sprint level for a brand new (to Scrum) team/group. I try to make it very simple - we are successful if we achieve the sprint goal. Typically with new teams, the only goal is to accomplish the stories we've put into the sprint. So it's easy to define success - 6 stories put into the sprint, 6 stories done at the end of the sprint, and we have a success!
Invariably the team does NOT finish all 6 stories and so the result is NOT success or failure. That's so simple. Now if we keep track of this for a few sprints, and the product owner starts to care about team success - then the team will pick up upon the new trend and adjust behaviors. One significant behavioral change is when the team starts to reject "roll-over" stories and learns to slice stories into tiny valuable pieces. The result of this behavior is that story sizes get smaller, and along with that is pressure to become successful at the planning game - so they accept fewer and fewer stories and smaller and more manageable stories into the sprint. There attempted sprint velocity goes down - but their predictability goes way up. They turn failure into success. And success breeds more success!
So if you are wondering what your target velocity should be... have the team decide upon a number and take in HALF of that value for sprint 2. If you are successful - great you have a known predictable velocity - if not - divide by 2 AGAIN, and iterate.
See Also:
What is an Agile Transition Guide?
Comments