Nokia Test: Know your velocity (7)

Background: There are far too many teams doing “Scrum, but…[eg, we don’t have a ScrumMaster]”.  This is not “full-out” Scrum, and almost always means that the team is not getting impressive results.

My original blog post is here.  And I have other blog posts on this subject.  Just use the search function above. And see this blog post from Jeff Sutherland.  He also has others.

***

So, the seventh line of the Nokia Test says: “The team generates burndown charts and knows their velocity.”

What is a burndown chart? Let’s start with its purpose.  The purpose of a Sprint burndown chart is to enable the whole team to see, on a daily basis, how much more work the team has to do to fulfill their commitment to deliver 8 stories in a 2-week Sprint (or x PBIs in a y-week Sprint, if you prefer).  Well, the purpose is more than just to see.  The purpose is to enable them all to have the summary information that might galvanize action. “OMG, we gotta do something, because right now it looks like we won’t get it all done!”

The idea behind this is just like Hans Christian Anderson said.  Anybody can call out that the emperor has no clothes, ie, that we’re in trouble and must act.  Now.  And anyone can volunteer some ideas on how to fix it (whatever the key problem or problems might be).  Scrum does not presume to define how the team will decide what to do (eg, should there be conflicting solutions proposed).  Rather, Scrum assumes that there are myriad possible team “configurations”, so the team must self-organize to decide how to decide.  And the team members probably have already done this, at least mostly, by the time this crisis has arrived.

So, the Sprint burndown chart (or any similar device) tells the team how much effort is remaining today to complete all the stories originally promised. So that the purposes described earlier can be pursued.  For beginning teams, effort remaining is usually expressed in ideal hours.  And it is effort remaining re-estimated with any new knowledge we have now.

A release burndown chart has a similar purpose.  Again, anyone in the team can contribute. But the final decisions are typically more with the product owner.

So, the release burndown chart shows how many story points of work are remaining to get done all the stories ‘promised’ for the next release. 

This Nokia item also focuses on the known velocity.  The team knows their own velocity, and rather than get too proud or too humble, they immediately start the process of improving it.

Again, why is it useful to know the team’s velocity?  A few of the reasons…

• the velocity can be used to plan with. (“It will take 10 more sprints at 20 story points to complete those 200 story points in the product backlog.”)
• to justify spending time working on improvements (“Why did you spend so much time going to retrospectives?” “Well, we increased our velocity that way by 70%.”)
• to push back on the magical thinking managers (“Well, just because you stamped your foot we can’t double our trend velocity number.  Want to help us remove some impediments?  Maybe then we can improve significantly.”)
• to make the business case (“If we increase velocity by 10%, that means about $300K in net profit. We can definitely afford this change!”)
• to measure success (“So, not that we implemented that fix, how much was the improvement really?”)

Do these ideas indicate some places where you can get more from this set of things we call Scrum?