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.
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
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.
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.
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).
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.
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