[QUESTION] The Product Owner Says #NoEstimates From the Team. Now what?

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?

Kerrin Asmundson | Free Estimates | Flickr

Kerrin Asmundson | Free Estimates | Flickr

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?


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.

Question: 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? You can leave a comment by clicking here.

[QUESTION] Can a Scrum Master Force an Increase in Velocity?

The Scrum Master is demanding a higher velocity during the next sprint. Does the scrum development team have to listen or has the scrum master overstepped?

Beat Kung | Emc2 | Flickr.com

Beat Kung | Emc2 | Flickr.com

No, the scrum master has overstepped.  The scrum master is a member of the scrum team – not its manager. The Scrum Master can ask the development team to increase velocity, but cannot force it.

The Scrum Master can only ask because increasing velocity means adding more work to the sprint backlog. The development team owns the estimates and they also decide how much work they can take on during a sprint. Any increase in work – even to increase velocity – must be approved by the scrum development team.

Yes, the development team could deflate their estimates to achieve the same thing. But let’s assume that the scrum master would catch on to that scheme pretty quickly. Let’s also eliminate the possibility of increasing the length of the sprint to increase velocity. The math works, but it’s also an easy gimmick to spot.

Scrum teams are self-managing and self-organizing. The concept of force does not play well in this context.

Let’s pretend for a moment that a scrum master could demand a higher velocity from the development team. Here are possible outcomes:

  1. Decrease in quality:  A team that has an imposed metric is forced to cut corners to meet the new demands. Quality is the first thing to go in these types of situations. It becomes very easy for a team to decide that in order to meet an unrealistic date they must stop writing unit test. Or even worse, that they should stop testing all together.
  2. Increased technical debt:  A scrum team that is under the gun is not likely to make the right decisions. Over time, a series of compromises in quality and architecture will lead to increased technical debt. Ironically, additional technical debt will reduce velocity in the future as the system becomes too fragile and complex to change easily.
  3. Demoralized Team:  Scrum is a developer play. At its core is the empowerment of the development team. Self-organization and self-management remove the traditional command and control levers from software development. Add those back in by forcing an arbitrary velocity and you’ve taken away the scrum development team’s ability to own their work. And along with that their morale.

The scrum master in this example was not acting as a servant leader. Remnants of a command and control structure are still present in this situation. More likely, this is a case where the development cannot do their best work due to impediments that still exist in their organization.

If the scrum master believes that a higher velocity is possible, he/she should ask the team: What can I do to help you be faster?

Question: Have you worked on a scrum team with a “command and control” scrum master? How did that impact you? You can leave a comment by clicking here.