What would you do if your Scrum Product Owner decided that customer value should be the sole focus of the scrum team and therefore wants to eliminate estimation (#NoEstimates) from the scrum development team’s process?
[featured-image single_newwindow=”false” alt=”Kerrin Asmundson | Free Estimates | Flickr” title=”Kerrin Asmundson | Free Estimates | Flickr”]Kerrin Asmundson | Free Estimates | Flickr[/featured-image]
Perhaps the scrum product owner read the exchange between Neil Killick and me and decided that #NoEstimates is the way to go. Is it possible that I failed to express the benefits that estimates can bring?
Possibly.
But in this case, the answer is pretty simple. As a scrum master I would remind the scrum product owner that he/she does not have control over the team’s practices or their estimates. There is a misconception in some organizations that a product owner is a “manager”.
This simply isn’t true.
The scrum product owner is responsible for optimizing the value of the scrum development team does. This is primarily achieved by providing a well refined and prioritized product backlog.
Scrum teams are self-managing and own their processes. The team is responsible for continually inspecting their practices and results – usually in a sprint retrospective – looking for continuous improvement.
Following that explanation, I would then ask the team what they think about the scrum product owner’s request.
Scrum is a “developer play” after all. So it only makes sense to ask the team what value they see in estimating (or not estimating) their work.
If after such a discussion, the team decided to go the #NoEstimates route, I would fully support them.
There are some topics that the team would need to speak to with capacity being one of them. Forecasting for the product owner would be another. As long as the team as figures out how to meet these business expectations, then why not give #NoEstimates a shot? Scrum is based on empiricism. Inspect and adapt!
In this example, the scrum product owner decided that estimates are overhead. This sentiment is hard to disagree with. Estimates are pretty worthless. They expire quickly. When requirements change they expire even faster. Worse of all, estimates are almost always wrong.
But that is why scrum teams estimate often. We are not trying to hit a date or measure the accuracy of our estimates. Rather, scrum teams uses estimates to guide them on how much work they can complete in a sprint.
The estimates can also be used by the team to discover their sustainable pace and to forecast a few sprints out to see where stories (features) could be delivered. These activities have value to a scrum team and to the product owner during release planning activities.
But these benefits diminish if the estimates are not continually updated. During these multiple planning poker (estimation) sessions, the team learns quite a lot about the story in question and about each other. These interactions can lead to a much better team and product.
As a scrum master you should be looking for opportunities to empower your team to make their own decisions. In this case, the scrum product owner wanted to dictate how the team estimates (or doesn’t estimate) their work. Instead, the better approach is ask the team to discuss the idea and decide for themselves whether or not to give it a try.
[reminder]Have you ever taken an idea to the team that you may not have agreed with? What did the team decide? Did you support the decision?[/reminder]