How Product Owners can stop developers from being a pain in the @## during refinement
How Product Owners can stop developers from being a pain in the @## during refinement
You reap what you sow
I’ve coached many Product Owners and Scrum Masters, and after attending their refinement meetings, I am often left with a feeling of immense frustration.
Every Product Backlog item gets discussed meticulously. No stone is left unturned. Every detail, no matter how small, must be described with painstaking accuracy and microscopic detail, or else somebody will utter the following dreaded words:
“We can’t estimate this backlog item, because it isn’t clear enough.”
For every Product Backlog Item we discuss, the conversation ends with this same sentence. Refinement seems to have turned into a game, where it’s the job of developers to poke holes in Product Backlog Items. Anything missing is unacceptable, and refinement is a mere shadow of the valuable activity it can be.
Why are developers such killjoys during refinement? What can you do to prevent refinement from turning into a form of pencil-pushing trench warfare?
1. Stop punishing developers for wrong estimates
Have you ever been in a situation where, no matter what you do, you can’t seem to do it right, and you always end up being punished?
That’s how developers feel when you berate them for wrong estimates.
Estimates will inevitably be off because, by definition, all estimates are handicapped. Estimates are limited by the knowledge you can have beforehand — what you can know before you start working on something. Beforehand knowledge is not good enough to make accurate estimates when doing complex work. So no matter how meticulously developers prepare and analyze, some of their estimates are bound to blow up right in their faces.
When developers are penalized for wrong estimates, abolishing any uncertainty and paying attention to every minute detail gives them back a sense of control. It’s a perfectly normal and human response. A response that introduces a lot of waste with little value to show for.
As a result of estimate punishment, the ultimate goal of refinement becomes to not miss any details and abolish all uncertainty. Refinement is no longer about delivering value, doing the right thing, or understanding the customer. The point of refinement is to dig yourself in as much as possible, so when things go wrong, you can point the finger at someone else.
Incorrect estimates should not be a source of concern. If a Scrum Team can consistently meet the Sprint Goal, then who cares if estimates are off? Accurate enough to meet the Sprint Goal means the estimates are good enough.
If the Scrum Team does not meet the Sprint Goal, then work together on trying to understand how that happened. And I can tell you already, failure to meet the Sprint Goal rarely happens because of wrong estimates. Stop dreaming about a world where it is possible to anticipate all unforeseen complexity. It ain’t gonna happen. It is better to focus your attention on things you can control.
So what should you do instead as a Product Owner? Make your developers feel safe. Show you understand the complexity of their work. Tell them you don’t really care about their estimates being right, as you realize that will never happen. Do not plan Sprints at 100% capacity and create a cushion to be able to deal with unforeseen complexity when it inevitably appears.
Work with your developers instead of punishing them for not being able to know things they can’t know. Developers will reward you with flexibility and by worrying less about details that don’t really matter for the final estimate.
2. Do not treat Product Backlog Items like a contract
Many Product Owners carry over their requirements mindset to the world of Scrum. Every Product Backlog Item is treated as a mini-contract, where changes are actively discouraged. Introducing a change means admitting your preparation failed.
When you limit changes to Product Backlog Items, you are missing out on a key benefit of Agile: being able to react to the understanding that emerges during the Sprint. As phrased in the Agile manifesto:
Customer collaboration over contract negotiation
Responding to change over following a plan
Product Backlog Items are not complete specifications, exhaustive requirements, or a contract. It is okay if they are incomplete. It is more important to reach your goals than to restrict yourself to the initial contract as described in the Product Backlog Item.
As your understanding grows and emerges during the Sprint, adapt your Sprint Backlog Items to reflect the latest understanding. Making changes as you learn more is something good and not something to be discouraged. By being flexible during the Sprint, your team will be flexible outside the Sprint in refinement.
3. Shift ownership of writing Product Backlog Items towards the Scrum Team
As a Product Owner, you are accountable for managing the Product Backlog. However, you must make writing Product Backlog Items a team effort.
When you collaborate and write a Product Backlog Item together, it increases understanding. It is now a product of the whole Scrum Team, instead of something they hear from the Product Owner and have to say “Amen” to. By writing Product Backlog Items together, it increases the sense of ownership and understanding in the whole Scrum Team.
Remember, you can never write things down perfectly. It’s not about what you write down, it’s about what the team understands. The best way to increase understanding is to collaborate as a whole team, so everyone is on the same page.
If you want to learn more about this approach, I’ve written about it in detail before in ‘Great Product Owners write awful Backlog Items.’
When developers are a pain in the @##, the Product Owner is often to blame
Long refinement sessions where nothing ever gets estimated are usually a symptom of poor Product Ownership or a troubled organization with a velocity obsession.
Estimates will always be off, and it is better to be cool about it. Otherwise, you are going to waste so much more time estimating, and the estimates will still be off just as much. No matter what, your estimates are limited to beforehand knowledge.
Scrum’s way of dealing with uncertainty is committing to a Sprint Goal each Sprint. Not to the Sprint Backlog. The Sprint Goal is what gives you flexibility on the scope of the Sprint Backlog when your estimates are off. Use Sprint Goals properly, and you don’t need to worry about estimates being wrong.
As you learn more during the Sprint, allow the Sprint Backlog to emerge and reflect that understanding. Treating each Sprint Backlog Item like a contract constricts your ability to learn and to respond to changes. Benefit from afterhand knowledge instead of just relying on what you can know beforehand.
Scrum is a process framework where the whole Scrum Team is responsible for delivering products of the highest possible value. Include your team in writing Product Backlog Items is a excellent first step to make delivering value a team effort.
If you follow these steps, then refinement will stop feeling like a bureaucratic interrogation. And best of all: no more throwing things back over the fence, because you are all sitting on the same side of the fence!
Special thanks to Taylor Hetherington for inspiring me to write this article!