Getting Started with Product Delivery

Backlog Refinement & Definition of Ready (Part 5 of 10)

Unfortunately, PBR doesn’t mean a tasty alcoholic beverage

Vincent Carter

Published in

Straight Scrum

7 min readJul 15, 2021

Assuming you followed the earlier parts of this series and you have a Product Vision, a Product Strategy, a Product Roadmap, you have selected or “activated” your first Product Goal, and you know what a healthy Product Backlog looks like; the next step is to actually create the initial Items for the Product Backlog. Before the first Sprint, you will need enough Items in your Product Backlog for the Scrum Team to plan their first Sprint. The goal at this point is to get just enough Items in the Product Backlog so the Scrum Team can start Sprinting as soon as possible. Seriously, you can probably start a lot sooner than you think. So how do you get started Sprinting with the least amount of wasted time?

PBR

To get your Product Backlog to the point that you can start Sprinting, you will need to do something called PBR. Nope, PBR in this context is not a tasty alcoholic beverage nor is it the Professional Bull Riders association. PBR stands for Product Backlog Refinement and it is the activity of preparing Items in your Product Backlog, so they are clear enough that the Scrum Team understands what is being asked for and small enough to get done within a Sprint. The Scrum Team will need to do PBR every Sprint and all the activity that is done in the PBR is for a future Sprint, not the current Sprint. Because PBR is about future work and not the work for the current Sprint, I’ve seen a lot of teams cancel or not do any PBRs because they claim that they do not have enough time to think about future Sprints. What these teams do not realize is that by spending less time doing PBR, they are actually creating a reinforcing loop that compounds the issue of not having enough time. Less time that the team spends on PBR, leads to less refined work that gets pulled into the Sprint, leads to less time for the team to think about future work, which leads right back to less time that the team spends on PBR. Because of this, PBR is one of the first things that I look to see if a team is not doing when they say that they are finding it difficult to complete work within a Sprint. If your Scrum Team does not have enough time each Sprint to spend on Product Backlog Refinement, then your team is over committing and you need to address this impediment as soon as possible.

iPBR

If you are just getting started with Product Delivery, you probably have a Product Backlog that is empty and you will need to do something that is called the “Initial” PBR (iPBR) in order to get things moving. The iPBR is the activity of generating some big ideas that align with your activated Product Goal. After generating several big ideas, you then order them in your Product Backlog, select the highest big idea, and break this one big idea down into smaller ideas/Items so that they are small enough to get done within a Sprint. The main goal of the iPBR is to generate and refine enough Items that align with your activated Product Goal so the Scrum Team can deliver a potentially valuable and working Increment in the first Sprint.

For the iPBR, you will need the right people as well as enough detailed information that can be “brought to the room” to sufficiently come up with and refine several Items. The “right” people usually include the Scrum Team, Stakeholders, your users, domain experts, supporting managers, and a skilled facilitator. The detailed information includes the items mentioned early, Product Vision, Product Strategy, Product Roadmap, the activated Product Goal, and any additional supporting documents. Also, be prepared for the possibility of conflicts cropping up because it is difficult to get a new group to learn how to solve problems in a participatory way. That’s why having a skilled facilitator is recommended in order to help with running your iPBR in a collaborative and constructive way.

There are several great techniques that you or a facilitator can use to get people actively involved in the iPBR session. Gamestorming and Impact Mapping are two great places to start. Gamestorming is a book by Dave Gray that contains a set of games designed to help people break out of their thinking and produce better results. Impact Mapping is a book by Gojko Adzic that provides a great technique for collaborative strategic planning.

DoR

The next question is, how do you know when an Item in your Product Backlog is refined enough so that it is clear and small enough to get done within a Sprint. That’s where the idea of something called the Definition of Ready (DoR) comes in. The DoR is a document that enables the Developers to specify certain pre-conditions that must be fulfilled before an Item is allowed into the Sprint. The goal of the DoR is to prevent problems before they have a chance to start. The DoR is not part of the Scrum Guide and instead, it is considered to be a complementary practice. I like to think of the DoR as a “commitment” to Product Backlog Refinement similar to how the Definition of Done is the “commitment” to the Increment.

WARNING: If you are not careful with the DoR, it can actually cause more problems than it is worth. Too many times, I’ve seen the DoR used during the Sprint Planning event as a stage-gate where only Items that meet the entire checklist will be selected for the Sprint Backlog. The DoR is not supposed to be used as a contract between the Developers and the Product Owner. It is simply a guideline and should be written as such. One thing to avoid is having absolutes in your DoR. When a DoR includes a rule that something must be done before the next thing can start, it moves the team dangerously close to a stage-gate process and that will impede the team’s ability to be Agile.

Example: Instead of having an absolute statement in your DoR that says, “No Outstanding Questions that prevent the team from working on the Item.” Change it to read, “The Item is ready enough that the team is confident that they can successfully deliver.”

If you are a new Scrum Team, you might find using the DoR to be useful with getting started but my recommendation is to look for a way to abandon the Definition of Ready as soon as possible. I also purposefully aligned the Definition of Ready with Product Backlog Refinement instead of the Sprint Planning event to help avoid this negative stage-gate behavior.

Often the acronym “INVEST” is used as a checklist for creating the Definition of Ready. An item is deemed ready for a Sprint when it is:

Independent (of all other items. Can this piece of work deliver value by itself and can I potentially release it when it is done)
Negotiable (not a specific contract. Are the “What” I need to do and “Why” I am doing this clear, but is the “How” still open for discussion)
Valuable or Vertical (Is the Value to be delivered to the Stakeholders clear? Vertical Slicing refers to a cross-sectional slice through the layers that form the structure of the software code base.)
Estimable (do we have any idea of the complexity, risk, and effort of the work)
Small (is it possible to plan the work with a decent level of certainty and can it fit within a Sprint. I prefer ⅓ of a Sprint)
Testable (Can we test if the delivered work fulfills the acceptance criteria set with the goal?)

Final thoughts

There’s a balance between spending too much time thinking about what to do and not spending enough time getting something done. The more time you spend thinking about what to do, the longer you are postponing getting feedback that you are delivering true value and headed in the right direction. At the same time, if you do not spend enough time thinking about what to do, the situation can quickly “snowball” where the teams are not able to get work done within a Sprint. Be prepared at first to have a few failures as the team works to find the right balance.