January 18, 2022


News for Agilists

What NOT to do during Product Backlog Refinement? – Serious Scrum

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.

Golden Circle

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

Photo by Austin Distel on Unsplash

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.

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.

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.

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.

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.

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.

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.

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

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

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?

Photo by Headway on Unsplash

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.

Wrap up

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.
Do you want to write for Serious Scrum or seriously discuss Scrum?

Source link