On zero refinement in Scrum

My friend Steve Porter recently twitted on Product Backlog refinement: “Refinement isn’t an event in Scrum. It’s a concept. It’s not mandatory and there are no hard and fast rules for when and how much. Zero refinement is acceptable, as is spending a majority of your Sprint on it. Figure out what works for you.” My first reaction was a feeling of doubt, but Steve is one of few people who really understand what Scrum is (he is a Professional Scrum Trainer and a team member at Scrum.org — a home of Scrum). So I decided to think that through and try to figure out what I think of that.

We need to clearly define what we are talking about, so I would like to start from a quote from Scrum Guide, that defines what Product Backlog refinement is:

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.

Then I wanted to figure out the things we agree upon. The Scrum Guide does not define Product Backlog refinement as an event. Rather it is an ongoing process. So we are in agreement on that. The same thing with the acceptability of “spending a majority of your Sprint on it”; refinement “usually consumes no more than 10% of the capacity of the Development Team” and that does not mean that it should consume exactly or no more than 10%. So it looks to me as if we are in agreement on “there are no hard and fast rules for when and how much”

But when it comes to “zero refinement is acceptable”, I have a different opinion. Yes, Scrum is a framework that is used in complex environments, and complexity implies that everything is extremely context-dependent, and nothing is “one-size-fits-all”. One should approach things with curiosity and an open mind, and try to help the team figure out what works best in their particular situation (and don’t forget to review the decisions, because things are changing, and solutions should adapt respectively). And yes, the Scrum Guide does not explicitly require that a Scrum team should do Product Backlog refinement. What makes me disagree here is the very definition of refinement as “the act of adding detail, estimates, and order to items in the Product Backlog”.

If we define refinement in such a way, then “zero refinement” will mean that our Product backlog is set once and for all. We do not add any detail, nor estimates, nor change its order. And that contradicts the very idea of a Product Backlog as a dynamic entity that “evolves as the product and the environment in which it will be used evolves”. Moreover, they idea that a Product Backlog can be fixed once and for all violates the definition of Product Backlog. Let we quote the Scrum Guide once again:

The Product Backlog is an ordered list of everything that is known to be needed in the product.

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.

Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

So if one’s Product Backlog is not changing, then it is not a Scrum Product Backlog and therefore one does not do Scrum because “Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”

I can imagine environments where such a backlog is possible, and that is probably something in a simple domain, and in that domain one probably doesn’t need Scrum (because one doesn’t need to inspect and adapt). Or it’s possible that a team just ignores changes or does not get feedback that could allow them to see that changes. Rephrasing an old joke. “If you don’t see any changes, you are right: you don’t see the changes.”

As Steve pointed out in our later discussion, there are (at least) two options to consider:

Some people suggest that refinement is specifically the act of the Product Owner and the Development Team working together on the Product Backlog. If a Product Owner updates Product Backlog items on their own, that’s not technically refinement.
There may be cases where a Product Backlog is very small and very loosely defined. It’s just a list of goals or experiments to run. In this case, the only work needed on the Product Backlog is adding new items or discarding unneeded items.

Regarding Option A Steve is not sure if he agrees with that view of refinement, but, as he says, “just because I don’t agree with it doesn’t make it wrong”. I would agree with him, taking into account the definition of refinement in the Scrum Guide: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog”. I would also say that this notion of refinement, when mixed with the “zero refinement” idea, may add a lot of complexity. If a Product Owner updates the Product Backlog on his or her own, and the Product Owner and the Development Team are not working together on the Product Backlog, this could mean that the only way the Product Owner and the Development Team communicate about Backlog items is through the Product Backlog itself. This might lead to all sorts of misunderstandings. I can imagine how that might work well, but such a way of communication lead to so many troubles that it is now among the Principles behind the Agile Manifesto (The most efficient and effective method of conveying information to and within a development team is face-to-face conversation).

Option B might potentially work, but may also bring a bunch of product troubles (miscommunication due to too vague Product Backlog items is just one of them, another possibility is a problem with fitting Product Backlog items into a Sprint to have a potentially releasable Increment done by the end of each Sprint).

To summarize all of the above in three takeaways:

if your team does zero refinement, I would suggest reviewing your team’s definition of refinement and the team’s feedback mechanisms (including communications within Scrum Team) — there is a reasonable probability that one of those is not functioning the way it should be
if a team’s feedback mechanisms are functional and the team has zero “ScrumGuide-ish” refinement (i.e. not adding detail, estimates, and order to items in the Product Backlog) — and it works well for that particular team — all good to them! As Steve says, “it’s possible and I don’t want people not trying it because of something they read in the Scrum Guide.”
before changing Scrum make sure that you are not changing it to hide the problems, but to solve them.