1 — Do not bring solutions
The Product Backlog refinement aims to get the problems discussed with the Scrum Team, which means the solution is defined together. That is how it should be, but unfortunately, many Product Owners come with the answer already established. From the Development Team’s perspective, this is exceptionally demotivating because they don’t have a voice on the solution, and they don’t even know what problem they are solving.
I’ve done that couple of 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 makes total sense. That’s the reason we should always start with why, then we can go the 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 — Do not accept the word impossible
A great Product Owner should be as transparent as possible about the upcoming challenges with the Development Team. As Product Owners, we should aim to change the status quo and not live in a comfort zone. My opinion is: Product Owners should bring audacious challenges to the team, at first glance they may seem impossible to solve, but collaboration will always make it possible, we need to be relentless in cases like this.
Once the development team receives a challenge, which they don’t know how to solve it. The first reaction most probably will 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 sees that. There are many ways of exploring this; powerful questions will be the key to making the impossible possible. Some items I like asking are:
- What are the aspects that make it impossible?
- What can you do to make it possible?
- Which difficulties do you see here?
- Which options can you create?
- If you had a choice, what would you do?
The critical point is, keep exploring, help the team finding an alternative, but do not accept the word impossible as a final answer.
You can get a list of powerful questions here.
3 — Do not estimate in hours
The Scrum Guide does not restrict how Product Backlog Items should be estimated. However, my suggestion is to avoid estimating in hours. From my perspective, once we talk about hours, it limits the creativity of the Development Team, and they need to waste time thinking about the implementation upfront. I believe that during the backlog refinement, that is not the goal; therefore, estimating in hours can hold us instead of helping.
You see, the thing with points is… they don’t mean time! Nor days or hours. They are not a scientific unit used to compare one team’s performance to another.
— Devdone, Your Story Points are… ?
Although the Scrum Guide does not recommend how Product Backlog items should be estimated, the most used approach is the Story Point, which bases on the complexity, risk, and uncertainty. Story Points are simple in usage, though they are not so simple to explain. To better understand, I recommend taking a look at this article written by Maarten Dalmijn. He explains the Story Points in a useful and straightforward way.
Almost every team I start working suffer from Story Point confusion. I believe this is not because Story Points are so difficult to understand, but because they are difficult to explain.
This leads to each person having their own and different understanding of Story Points.
I have a strong opinion about estimating in hours. I believe that we should never estimate in hours or relate complexity to hours. This approach will not benefit the team, will not help to maximize the value and will generate waste. Because the team will invest time in thinking how long they need to do implement instead of defining the complexity.
My perspective is that time estimation doesn’t go with software development; that’s why I suggest not to apply the project management practices from civil engineering into the software world; it does not fit in my opinion.
I personally loathe time-tracking, though I do not reject it out of hand. Contracts may be time and material based, and thus require justification. Micro-level time-tracking is however a sure way to demotivate developers. It’s a discriminating practise. I am not sure why (especially in Software Development) we are so obsessed with practises like micro-estimations and time-tracking, but its toxic, control-freakish micro-management. I’m inclined to say that, if stakeholders want to inspect what developers actually do, they can inspect the work they actually did, rather than rely on timesheets and trendlines. Join the damn Review.
— Sjoerd Nijland, Estimation
Don’t forget; the team evaluates the Product Backlog items to have an idea of how complex it might be, that is not a commitment.
Estimation ≠ Commitment.
4 — Do not fall into endless technical discussions
There is a boundary in the Product Backlog refinement session, which we need to respect. The rule is, we discuss the why and what, but not the how. What do I mean by that? During this session, we should be able to understand the problem and evaluate possible approaches to addressing it. However, it is not the moment for the technical discussion.
It is incredibly hard to avoid technical discussions, but we should strive for that. The team may evaluate some possibilities, that is fine, but be careful not to end up discussing in a more in-depth detail that goes very far from the purpose of this moment, which is refining the Product Backlog and estimating the complexity of the items.
“Estimates are never wrong. They are an assessment on that point in time with what was known at the time. That reality proved to be different is another story. That doesn’t invalidate the estimates.” — Willem-Jan Ageling
If we realized that we are in the technical spiral discussion, there is a sign that uncertainty is too high. Maybe the Development Team is not ready to estimate, in this case, a way of moving forward is creating a Spike, then the team can invest some time during the Sprint researching more how to move forward. Spikes are time-boxed tasks, defined by the PO 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.
Sjoerd Nijland, Estimation
Spikes can bring a lot of benefits to the team, but be careful with the usage. Too many spikes sound like an issue, which means the team might be afraid of failing. Mike Cohn describes in more depth the usage of spikes.
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.
— Mike Cohn, Spikes
5 — Do not split User Stories into implementation tasks
Breaking User Stories into technical tasks is another problem, unfortunately, which is not understood by many teams. A lot of times, developers want to split the User Story according to the technical boundaries. This approach is a mistake because each User Story must deliver value to the end-user, if you divide it into technical boundaries, then 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, it’s wrong. The form is a compound of three parts:
- Story: which is the problem we want to solve? Who is interested in it? What is the motivation?
- Acceptance Criteria: how can we evaluate if we achieved the expected result?
- Conversation: that is the essential part, the talk with the team. Without that, the User Story is meaningless
Items on a Product Backlog are reminders for future conversations, based on the knowledge and the insights that have emerged by then.
6 — Do not force everything into User Stories
In the Agile world, most organizations use the Scrum Framework. However, the Scrum Guide doesn’t specify how we should describe the Product Backlog Items. Although nothing is saying that teams must use User Story with Scrum, that is what happens quite often, which is fine, but be careful. Not everything fits within the User Story format, and the Product Backlog should have all the items related to the Product.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
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”.
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, I would recommend not use the User Story; it does not fit. Take a look at some examples of what not to do:
- As a Developer, I want a faster server for the API so that the API’s response time is reduced
- As a Developer, I want to set up a backup for our databases so that we will ensure that we can recover in case of data loss
In cases like that, I suggest to be more direct, there’s no problem in doing so, 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
7 — Do not force what you don’t know
During the Product Backlog refinement, the Product Owner should not only challenge the team, but also the developers should challenge the Product Owner. Once the team engages in the session, they will ask as many questions as needed, so that they can understand the problems and motivations behind each Product Backlog item. That is how it should be; the Product Backlog refinement is precisely the right moment for that. However, sometimes wearing the hat of a Product Owner, we may not know the answer, what should we do in cases like that?
Once the team fired questions that can’t be immediately answered by the Product Owner, we need to be honest and transparent by saying, that’s a valid point that I need to take with me and get the answer for that. It is essential to do it, because otherwise, we may end up discussing something that the team is not comfortable with since they don’t have all answers.
Product Owners should remove all doubts from the development team, once that is not possible, it means that the Product Backlog items need better understanding from the Product Owner’s side and is not ready to be discussed with the team.
The Product Backlog refinement is crucial for the success of any Scrum Team; therefore, given my experience as a Product Owner, I suggest others to be sure to:
- Discuss problems instead of the solution;
- Help the team finding solutions for challenging issues;
- Leave the team without any doubts and open questions;
- Help the team reducing the uncertainty level;
- Do not split User Stories into technical boundaries
- Know when to use the relevant format for a product backlog item;
- Step back when you do not have the answer.