Why Most Refinement Sessions Leads to Nothing But Frustrations
Five common pitfalls you should avoid during the refinement sessions so that you can benefit from a meaningful outcome.
Five common pitfalls to avoid during the refinement sessions for a meaningful outcome.
Product Owner: Hey, everyone! It’s time to have our refinement session!
Developer: Oh, no! I forgot. Can we skip it? I have to focus on the Sprint.
Product Owner: I would prefer to have it. We already skipped last time.
Developer: Hum. I think focusing on the Sprint is more important. I feel like we don’t have time for the refinement.
As a Product Owner, I faced this type of conversation many times. Developers searched for excuses to skip the backlog refinement. Also, when we had the sessions, the team was disengaged. I wondered why that happened. Although the reasons can vary, most of the time, it is related to how the Product Owner conducts the refinement. A set of anti-patterns lead to pointless refinements.
If you have similar conversations, you probably fell into one of the traps I fell into. Let me share with you my learnings on how to avoid pointless refinement sessions.
What is the Product Backlog Refinement Session?
Before we discuss the pitfalls, it’s important to understand what the refinement session is. Let’s have a look at what the Scrum Guide says. In bold, you can read the most relevant part.
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
— Scrum Guide, November 2017
The outcome of this session should be a shared understanding with the Scrum Team. In other words, the team understands the problem and knows why it worths solving it.
After each refinement session, Product Backlog Items can be planed towards the next feasible Sprint. But don’t underestimate it, getting to this level is easier said than done. Unfortunately, many Product Backlog refinement sessions are very far from achieving this goal.
1 — Focus on solutions instead of problems
The Product Backlog refinement aims to get the problems discussed with the Scrum Team to define the solutions together. That is how it should be. But unfortunately, many Product Owners bring solutions to implement instead of problems to discuss.
Developers are not motivated to implement solutions. They are motivated to solve problems. The motivation comes from understanding precisely a problem and then crafting a potential solution for the problem. Product Owners should not bring answers to the team; we should bring questions instead.
As a Product Owner, I focused on the solution many times. Therefore, I learned the hard way what not to do. I heard sentences like, “We need to know the problem. Otherwise, how can we solve something we don’t know?” That’s the reason we should always start with why instead of what and how. If we invert this sequence, it will be counter-productive and disengaging.
“People don’t buy what you do; they buy why you do it. And what you do simply proves what you believe”
― Simon Sinek, Start with Why: How Great Leaders Inspire Everyone to Take Action
2 — The word impossible shuts down the conversation
When it comes to software development, impossible is a perception. We may say that something is impossible, but it’s better to rephrase as we don’t how to do it. Don’t let the word impossible shut down a conversation.
As Product Owners, we should aim to change the status quo and not live in a comfort zone. Product Owners should bring audacious challenges to the team. They may seem impossible to solve at first glance, but collaboration will always make it possible. We need to be relentless in cases like this.
If the Development Team doesn’t know how to solve a complex puzzle, the first reaction might be, “This is impossible!” However, Product Owners should not accept the word impossible as an answer. We need to go deeper and understand why the team has this perception. Powerful questions can bring clarity so that we can move from impossible to possible. Some questions I like asking are:
What are the aspects that make it so hard?
Which difficulties do you see here?
What can you do to make it possible?
Which options can you create?
If you had a choice, what would you do?
The critical point is to keep exploring, help the team finding alternatives. But do not accept the word impossible as a final state.
You can get a list of powerful questions here.
3 — Endless technical discussions
There is a limit in the Product Backlog refinement session, which we need to respect. The rule is, we discuss the why and what, but not the how. During this session, we should understand the problem and evaluate possible approaches to address it. However, it is not the moment for the technical discussion.
It is daunting to avoid technical discussions, but we should strive for that. Developers long for understanding on how to solve the problem. But we should keep the goal of the refinement in mind: build a shared understanding.
If we fall into technical discussions, we will go far from the refinement’s goal, and since we will not have enough time, frustration is inevitable. Technical discussions should happen at the right moment, which is the Sprint Planning instead of the refinement.
We don’t want to fall into the technical spiral discussion. Instead, we should perceive it as a high level of uncertainty. Maybe the Development Team doesn’t have enough information to estimate. In this case, a Spike is a way of moving forward. Then, the team can invest some time during the Sprint, researching how to move forward. Spikes are time-boxed tasks, defined by the Product Owner in agreement with the team.
Sometimes a team will argue it cannot estimate as too much is uncertain. Discovering complexities in order to reduce uncertainties is an exercise in itself. Some will set timeboxes and call them Spikes.
Spikes can bring a lot of benefits to the team. Mike Cohn describes in more depth:
Because spikes are time-boxed, the investment is fixed. After the pre-determined number of hours, a decision is made. But that decision may be to invest more hours in gaining more knowledge.
But be careful with the usage. Too many spikes sound like an issue, which means the team might be afraid of failing.
4 — Focus on breaking items into tech boundaries
If we realize we are discussing requirements to implement instead of goals to achieve, it’s a sign we are misusing the refinement session. Many teams struggle to skip how discussions. They want clarity on how to move forward. Refinement is the wrong moment for that.
Breaking User Stories into technical boundaries is a widespread misconception. Many times, developers want to split the User Story according to the technical aspects. This approach is a mistake because each User Story must deliver value to the end-user. If you divide it into technical boundaries, you are misusing it. You will not get the benefits of the User Stories.
Splitting along technical boundaries can lead to stories like:
As a user, I want a backend that does such-and-such
As a user, I want a frontend that does the same such-and-such
A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own. A frontend (say, a web interface) does users no good until it is paired with a backend (a middle tier and/or database).
— Mike Cohn, Five Story-Splitting Mistakes and How to Stop Making Them
Remember that User Stories are focused on delivering value to the end-user. If there’s no value produced, we are missing the point. The form is a compound of three Cs:
Card: which is the problem we want to solve? Who is interested in it? What is the motivation? The answers fit in a card.
Conversation: exchange with the team. The goal is to understand the story. Without a meaningful conversation, the User Story is meaningless.
Confirmation: how can we evaluate if we achieved the expected result?
Items on a Product Backlog are reminders for future conversations, based on the knowledge and the insights that have emerged by then.
— Christiaan Verwijs, Myth: In Scrum, the Product Backlog has to consist of User Stories
5 — Forcing everything into User Stories
In the Agile world, most organizations use the Scrum Framework. However, the Scrum Guide doesn’t determine how we should describe the Product Backlog Items.
Product Backlog Items are not restricted exclusively to User Stories, though User Stories is the most used format. Yet, we have to be careful. Not everything fits naturally within User Stories.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
— Scrum Guide, November 2017
The usage of User Story fits perfectly with new features, changes of behavior, and enhancements. But once you want to describe a bug or a technical requirement, User Story might be an odd choice because it doesn't fit naturally. Let’s have a look at some examples of what not to do:
As a Developer, I want a faster server for the API to reduce its response time.
As a Developer, I want to set up a backup for our databases to ensure that we can recover from data loss.
In cases like that, we can be direct. It’s more effective, for example:
Setup new server for the API
Set up the backup for the databases
If you find yourself forcing requirements into a ‘User Story’-template, consider what purpose the story serves. Is this the best way to make the Product Backlog understandable both to the Scrum Team and its stakeholders?
The template of ‘User Stories’ is only a guide. There’s nothing wrong with shorthands like ‘Visitors can register for newsletter’;
— Christiaan Verwijs, Myth: In Scrum, the Product Backlog has to consist of User Stories
Having meaningful refinement sessions
The Product Backlog refinement is vital for any Scrum Team. That’s why we should strive to:
Discuss problems instead of the solution.
Ensure the team is building a shared understanding.
Leave the team without any doubts and open questions.
Remove uncertainties from the Development Team.
Do not split User Stories into technical boundaries.
Know when to use the relevant format for a product backlog item.
Do you want to write for Serious Scrum or seriously discuss Scrum?