Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning Event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done.

TL;DR

If you get to the Sprint Planning event and your Product Backlog Items for the next Sprint are not already of a size that can fit into the Sprint and fully understood by the Development Team, then you are doing it wrong. You are heading for the rocks from the start, and you have no map of the shallows to prevent it.

Although the Scrum Guide does not define Refinement as an Event, you should be doing it. You can come up with your Refinement event(s), or refine ad-hoc. Whatever you chose there is a simple measure of success. If your Development Team looks at something within the next 2 Sprints on the backlog and they don’t understand it, then you have work to do.

If you find that you can’t quite get things to fit and have to stagger iterations, or you are just not able to deliver at all, then a lack of refinement is usually at fault.

What does ready mean for a Product Backlog?

If the Development Team does not understand the things that they are being asked to do how could they possibly agree that the items can fit in a Sprint? You will often find teams that don’t do refinement confused as to why they cant get everything done in a Sprint. While we accept that in an empirical process like Scrum that we, know less up front than we discover as we go, merely taking a guess and hoping for the best is decidedly unprofessional.

“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”

-ScrumGuides.org

While we don’t need a definition of ready, we do need a working agreement between the Product Owner and the Development Team. If you are following Scrum, then the Development Team are the ones selecting for the Sprint, and they are the only ones that can decide what they can do. The Development Team should be empowered to refuse to take items from the backlog that either they do not understand, or are too big to be completed in a single sprint. In general, I would expect that a team take at least ten items into their Sprint, so they need to be sized appropriately.

Ready Backlog just means that the Development Team can select it with confidence.

How do you refine your backlog?

Refinement is not an explicit event in the Scrum Guide because it is something that can be different depending on the Product, Domain, or Technology. If you were to ask how much refinement you should do then the answer is “as much as you need and no more”. Too much Refinement is waste, as it too little.

“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

In the Scrum Guide there is the guide that it usually takes not more than 10% of a Development Teams time, and for a two-week sprint, this is reflective of a whole day per Development Team member. 10% may seem like a lot, but not only is it necessary it is a maximum guide and not a minimum. I have found that many teams that were not doing refinement in the past may need considerably more time to get their backlog into some semblance of order. Once it is in order, you are only maintaining a rolling two Sprint projection of what you might achieve.

I usually run at least the first refinement as a guided workshop. Run one before a Sprint Planning and most teams will see the value by the end of the next Sprint. For the Workshop, I get the Scrum Team (Product Owner, Development Team, & Scrum Master) into a room with any necessary subject matter experts and we merely open the existing backlog. Start at the top and ask the Product Owner if this is the next most important thing? If not, find something that is. Then have the Product Owner read and explain it.

Any time the PO deviates from the text that is in the Backlog Item, or adds more information, stop and have someone add that info to the Backlog Item. Ask the Development Team to estimate the item (will or will not fit is fine too as in #noestimates), “Does this look like it can fit with nine other friends into a single Sprint?”. If the answer is no, then you get to work breaking it down, reordering in the Product Backlog, and start refining again. You continue this process until the Development Team agrees that there is enough backlog refined for the next 2 Sprints.

This enables yourProduct Owner to be able to plan future releases and your Development Team to create an execution plan for the current one.

How do you monitor your refinement effectiveness?

During the Sprint Planning event, your Development Team should be able to quickly select a least 10 Product Backlog Items that go towards the chosen Sprint Goal and agree that they fit. If you can do this, and most of the time you get most (not all) of the Items delivered, then you are probably doing enough refinement. If you can’t, then you need to focus a little more on Refinement and making your Product Backlog Ready.

If ar your Sprint Review the Product Owner is always wanting to reject that Backlog Items are complete then there is unlikely to be enough refinement for the Development Team to understand what they are expected to do.

The post If your backlog is not refined then you are doing it wrong appeared first on Martin Hinshelwood - naked Agility Ltd.