Ask a Product Owner #1: Refinement

On LinkedIn, I gave my connections and followers the opportunity to ask any burning question they might have related to refinement.

I’ve bundled all the questions anonymously here together with my answers. I also sometimes bundled together variations on the same question (or because my answer to them is related).

What is the purpose of refinement?

“What is the true purpose of Refinement? What do we really need to get out of it?”

The purpose of refinement is twofold:

1. Reach a common understanding as a team about something you want to have in your product.
2. Establish reasonable confidence that you can start working on it and complete it within a Sprint.

What this definition intentionally leaves out is establishing a perfect contract with pristine acceptance criteria. I’ve also intentionally left out discovery or spike work. Estimation is also not necessary.

The purpose is not to get all the detail right up-front, nor guarantee that there won’t be any changes or that you are sure it will fit in a Sprint. In the doing of the work, you will discover the work you must do, as Woody Zuill says. That’s why it’s more important that you can start working on it, than have every little detail figured out.

What’s more important is that there is a common understanding of the following:

• What are we trying to achieve?
• Why does it matter?
• What’s the relevant context we need to be aware of?

How it will work from a technological perspective and what it should do functionally also matters. But having clear answers to the questions above will help in answering these questions too.

What are the most common barriers to a good refinement session?

The most common barriers to good refinement are:

• Punishment for wrong estimates
• Treat Product Backlog Items as a contract
• Throwing tickets over the fence to the team

For many companies, the purpose of refinement is to produce estimates. And then when the estimate is off, or the velocity is lower than expected, the team gets punished. When you do this, you can guarantee endless hours in refinement discussing every tiny little detail, wasting even more time, and then you’ll bump in exactly the same problems as you always do — you’re limited to what you can know before starting the work.

For this same reason, if you see a Product Backlog Item as a contract you need to meet, instead of something that is allowed to emerge as you do the work, then you’ll run into a lot of problems and frustrations when you discover what you didn’t know or missed.

When you do complex work, it is expected that some of the details will emerge as you do the work. Trying to produce a perfect contract is wasteful and not important if you can fill in the details as you go along.

Product Owners, especially if they work together with a Business Analyst, spend a lot of time refining everything and breaking everything down, and then throwing it over the fence to the team. Then it’s no longer a working product of the team, but a contract to meet. When you break it down together, what’s written down becomes less important because it’s a working product of the whole team.

The only exception to this is when you have a team that lacks experience, then it may make sense to spoonfeed and break down the work up-front, as they may struggle to come up with this on the fly during refinement.

Who should attend the refinement?

“Who should attend the refinement? (Team, three amigo, stakeholders, architect, others)?”

It depends.

I believe everybody on the Scrum Team should attend. As there should be a common understanding in the whole team.

When you do discovery or spike work, it may not be necessary to involve the whole team. Then something like three amigos will be good, and then if you do start working based on the conclusions you can involve the whole team.

I sometimes invite stakeholders to refinement, if they can explain the problem or what we’re trying to achieve much better than I can. I once was delivering features for a finance department, so I had them explaining the financial intricacies directly to the team with me present.

Another example is when we walk through a new design, I let the person who made it present it, as they know best how it works and it’s their work. Otherwise, I’m just positioning myself as a middle-man. And that’s a waste of my time. Of course, I know how it works when it gets presented to the team.

When is refinement enough?

“When is refinement of a PBL ‘enough’? E.g. do you prefer any standardization to deem an issue or goal sprint ready?”

Are we reasonably confident that we can start working on it and complete it within a Sprint? I want to stress, start working on it. Details are allowed to emerge as we do the work.

If it takes longer than a Sprint, and we discover something we hadn’t anticipated yet, that doesn’t mean we did a poor job at refinement. This is the nature of complex work.

I’m not a fan of standardization, because it depends.If I create a ticket ‘Login not working’ and I immediately show a developer what’s happening, then they can start working on it. We can add details and error information as we discover and learn more.

When should refinement take place?

Many different variations on essentially the same question:

“Should refinement be treated as “event” or a habit or something else?
Why or why not?”

“To what degree backlog refinement can be a formal event (meeting) everytime Vs an ongoing activity in which relevant stakeholders can take part regularly and make sure the backlog has relevant initiatives.”

“Do you do them in a constant cadence or you do them ‘as your discovery goes’?”

All of this depends on your context. I don’t think there is a universal answer to all these questions.

I schedule it as an event, half an hour per week. I try to keep the meeting short and effective, and usually, we don’t need more time than this.

If we have around 2–3 Sprints refined, I usually cancel refinement. There’s no point to refine further.

Sometimes we have new information or want to work on something big, then I schedule an additional refinement.

Long story short: plan a short meeting with a regular frequency. Make sure it is planned at a moment that is convenient for the developers so it doesn’t disrupt their workflow. Cancel it when you have sufficient work refined ahead of time. If you need more refinement, plan an additional meeting.

The fact it is already planned, means you don’t need to waste time worrying about when it is planned. Make sure you diligently cancel it if you have sufficient work refined ahead of time.

If a backlog consists solely of User Stories, what else should occur (and when) for refinement to be effective?

I don’t think how you write Product Backlog Items should matter for the refinement process. The main thing I’d do differently is when you start splitting up a User Story into smaller chunks of work. Don’t feel forced to use User Stories to break the work down, as it may only lead to confusion or make things unclearer.

What questions could participants ask in the refinement to better understand value and priority?

• What are we trying to achieve?
• Why does it matter? How is it valuable to our customers and the business?

For the rest, it depends on the nature of the work so difficult to give generic answers. To be clear, don’t ask these questions exactly like this as it can come across in an aggressive way.

How much preparation is necessary as a Product Owner?

“What is needed for the participants in terms of preparation for the refinement?”

“What do you bring to a refinement, in what level of detail do you prepare what you bring?”

“To what extent you think you should ‘prepare’ a refinement (ie with help from a business analist)? In order to make the meeting as effective as possible.”

I believe it depends on the work and the experience of the Product Owner.

When you have less experience, you will spend a lot of time on the mechanics of refinement. Figuring everything out, writing everything down in tickets, maybe together with a Business Analyst.

As you have more experience, as long as you’re extremely clear on what you’re trying to achieve and why it matters, the rest can be filled in as you go along. If you’re presenting something for which UX/UI work is done, you can have the person who made the design present it and you set the stage with the context and what we’re trying to achieve.

And then you ask the team: how can we break this down into vertical slices of value?

If you have an inexperienced team, then you will have to do more preparation as asking this question will lead to stress and fear in their eyes.

Should you give the opportunity to ‘thinking slow’ time?

Do you think it would be wise to allow for ‘thinking slow’ time before AND after refining an item? This might allow different perspectives to emerge BUT might also slow down the whole flow. So… do you think we need ‘before’ and ‘after’ time

Yes, I believe you should do this. I often don’t do this enough. However, I also notice that if I send a list of things we’ll discuss before a meeting then often people come in unprepared.

I also think it’s important to read the room. When you discuss something and you see a puzzled look in everyone’s eyes when you start discussing, that might be a good cue to say let’s skip this one for now and maybe appoint someone to do a deep dive and do some preparation work for next time.

How do you run refinement meetings with multiple teams?

“I am curious how do you run refinement meetings with multiple teams.”

I usually followed a tiered approach, where I involve a select group of delegates to decide how we break down the work in bigger chunks and who will be responsible for what. Then those chunks enter refinement sessions as any other epic.

The main difference is, that we’d start a refinement session by explaining the big picture of the whole project we’re undertaking, and then discussing how our pieces fit in. This way, the team knows where we will need to collaborate with each other and reach an agreement.

Do you estimate production problems?

“Do you refine and estimate prod problems? (if they are not urgent of course) If so, what is your approach?”

When it’s urgent and important, we don’t estimate and just pick up.

If it’s a production problem, it’s a bug, and it can be estimated. However, bugs can be more difficult to estimate as you have no clue what’s going on and how difficult it is to fix. Then you just guess, and if your guess is wrong, it’s wrong.

If you don’t want to fix the bug if it takes too much work or is too risky, then I usually tell developers to spend some time investigating, and if it’s too risky or too difficult, we can also decide to close it. It all depends on the context of course.

What to do when a Product Owner is too busy?

“In a team, product owner says he is too busy and doesn’t have time for refinement. What is the best way to handle this situation?”

Ask for clear Product Goals on an Epic level. Then do refinement based on goals without the Product Owner to the best of your ability. It takes far less time to ask the Product Owner what they are trying to achieve and why it matters than to describe exactly how it’s supposed to work.

How do you obtain the effort needed for RICE prioritization without asking them to estimate?

“I have encountered the RICE (Reach/Impact/Confidence/Effort) prioritization technique.

It looks quite interesting in helping the PO to evaluate different stories with a rational and methodic approach.

What should be well defined is, IMHO, is #Effort parameter which could, if misinterpreted, become a sort of estimate requested to the Team ( definitely to be avoided).
What I also dislike is the use of Story Point for this paramenter, for at least 2 reasons:
● Prioritization is up to the PO and must be performed independently (without someone’s else opinion which, ultimately may get part of the responsibility and ownership) while Story Point scoring (if adopted) is up to the Developers. It’s not wise to mix & mess responsibilities.
● The effort may also be consist in something beyond the Team’s scope. For instance, a new feature (e.g. I18N) may require also extra expenses in HW, translations, packaging which impact the effort but not necessarily the Team’s commitment.

Your opinion and advice? Thank you!”

When you prioritize based on effort and value (based on a hypothetical business case not rooted in experiments or evidence), then you’re prioritizing based on noise. For precisely the same reasons you’re saying in your question. You don’t know the exact effort, unless you know the exact solution. Unless you do experiments and gather more evidence, you have little clue how much value it will bring. Therefore, you will be prioritizing based on invented information that is not rooted in the real world.

I prefer prioritizing on a higher, more tactical level, based on what you want to achieve.

When should you do Spikes?

Does your team(s) get (or need) extra investigation tasks besides refinement sessions? If not, how do they handle the highly complex and obscure items when it is not possible to try a way-observe the consequence and adapt?

Spikes should be rare. Spikes have their roots in rock climbing, it literally means driving a Spike in the mountain when you have no path to climb further.

You should use Spikes when you lack information to proceed. And I’m not talking about little details you can figure out as you go along, but really big things.

Sometimes we don’t even use a Spike, imagine there are some big unanswered questions we need to have answered before we can estimate, I just assign the PBI to someone and we discuss it next week in the subsequent refinement session.

How can you make refinement more fun?

“How can we gamify the refinement meetings in the best way to make them more interesting and participative. Any ideas. Thanks a lot for your time.”

I believe refinement is more fun when you do it together, e.g. using a Liberating Structure. When you think about what we are trying to achieve and how can we best achieve that?

When it focuses on producing estimates and breaking-down work in User Stories. That’s a boring grind we’re all too familiar with.

Do teams decide which PBIs to refine during refinement meetings that you have facilitated?

“Do teams decide which PBIs to refine during refinement meetings that you have facilitated?”

No, I usually take the lead in this, so they don’t need to worry about what we will be refining. However, I often receive input on what we should be refining prior to a refinement meeting.

Long refinements, short Sprint planning, where is the balance?

You should aim to have all of them to be as short as necessary. I usually have around 1 hour of refinement and 1 hour of Sprint Planning per 2-week Sprints.

When you have clear goals and there is psychological safety to figure out things as you go along, then this is often sufficient. But it also depends on what you’re doing and your context. If you’re building medical equipment or rockets, I’d probably do way more refinement and way more planning.

Those were all the questions, I hope the answers are of value! :)