A few days ago, I had a great day where I did some ‘magic estimation’ with two teams. In 15 minutes they created an initial estimation of the entire product backlog. This was an exciting moment for the Product Owners. They already know they have a budget for 14 sprints. Is it possible to do everything they want in only 14 sprints, while the team already is in their fourth sprint?
Three Years
For one of the teams, the outcome of the magic estimation session was a real shock. With a budget of roughly seven months, their initial estimation combined with their velocity resulted in an estimated completion date somewhere three years from now!
After triple checking no human error was made, the Product Owner and Scrum Master were sitting silently staring at the screen which showed the release burn up chart. How do you explain this to the stakeholders? The Scrum Master said: But our velocity is now 15 story points but it could be a lot higher if those two big impediments are resolved.”
Impediments
The team was facing two impediments, the test environment was unavailable, and therefore a lot of stories couldn’t be finished. Second, the team was responsible for designing and testing the solution. Building was done by another team in a different project. So this means, for a backlog item to get done, it took at least three sprints!
As the Scrum Master described the impediments, the Product Owner said: “Why not give a rough estimate of 40 points? Then we would have a nicer picture!”
No lying!
You probably know the great animation made by Henrik Nyberg about Product Ownership in a Nutshell. One of the key phrases of the movie is: ‘No lying!’
Estimating on behalf of the team, who do the actual work, is very dangerous. Project managers have been doing this for years. I have been a project manager and I have certainly done it. It creates an unrealistic view of reality and a false sense of security. When you make things look nicer than they actually are, it decreases the urgency for stakeholders to help removing impediments. If we are on schedule, why should we change anything?
When you are a Product Owner and you determine that the velocity of the team could be 40, you create a point of reference for your stakeholders. The truth is, you have never reached a velocity of 40, the velocity is 15! So the only thing you know, is that the team can do 15 points. If the impediments are resolved, you can expect the velocity to increase. But how much it will increase? You just don’t know! Maybe you immediately run into new problems. And then you have some explaining to do to your stakeholders. Why isn’t the velocity of the team 40, like you said? This has become common practise in the last decades. We even have procedures for it with exception reports, escalation paths etcetera. But you don’t need this!
Transparency can help you getting things done!
One of the values of Scrum is transparency. Make transparent what you are doing, how you are doing and what is slowing you down. Every graph (burn down or burn up), backlog or increment has some story behind it. If you want your impediments to be resolved, creating a sense of urgency will help you. You can only do this by making the impact of the impediments transparent. So if it takes you three years and you have budget for 7 months, you have a real sense of urgency to remove the impediments. It may make you feel uncomfortable making this transparent, you, as product owner, should push through. Just like Kniberg said: No lying!
