A new Definition of Ready
I’m a PO on a Scrum team so I’m keen to maintain the world’s best backlog; and as such, set the team up for success.
We’re a mature team, going on 4 years now, where we all have a good knowledge of the product, the users and the stakeholders, so by-and-large I can get away with most PBIs not becoming novella.
We had been going though a rough period where we’d been consistently missing our sprint goals with a large number of Product Backlog Items (PBIs) extending into the following sprints so we spent an extra long retro to examine the root cause.
The development team is very polite but it was obviously my fault. I had assumed too much in their knowledge or my ability to describe it in terms that can be understood and translated into product changes. We had incorporated a new major function that involved very detailed financial calculations and while the math was largely clear the intention and business purposes were not. This resulted in misinterpretations not so much in the code, but in the test conditions where a much wider view was necessary; they caught a huge number of edge cases.
There was also no adequate forum for us, as a team to explore those assumptions. Our refinement sessions had become mechanical.
Long story short (too late!) we decided to revisit our Definition of Ready.
Bad Habits
We had ramped up to an insane velocity and since we all knew everything (prior to the new major function) we had fallen into some bad habits:
- PBI descriptions were short and in many cases focused on the product change from a technical perspective and neglected the wider view.
- As a result the Acceptance Criteria were often a copy/paste from the description, perhaps changing the verbs.
- We have Feature level planning and our velocity success was largely due to the reduction in the size of the features but this meant we had many features that contained one or two PBIs and this led to the Feature description often left blank and the feature level Acceptance Criteria often left undefined.
- The development team were used to working fast and prior to this, small functional details that were generally easy to work out or clarify on our daily PO Drop-In call. So we didn’t spend as much time on PBI refinement with the whole team prior to marking it as approved.
- PBIs were authored by a number of people with simpler ones being created by the team as containers for the work.
The symptoms of the issue was an increase in the number of questions from the team that was sustained throughout the sprint; not just at the start. What about this? What about that? What if this happens?
Definition of Ready
I started to read up on the latest writing on the DoR and by golly does it invoke some emotions. It became clear that the root of these issues was that the DoR has been hamstrung by it’s more well-known big brother, the Definition of Done (DoD).
By necessity, the DoD needs to be absolute; either you’re done or you’re not. It also needs to be applied consistently in order to do its job. It is a definition, and it does it well.
DoR on the other hand most definitely cannot be applied consistently, nor should it. The requirements for one Story/PBI to be deemed ‘Ready’ may differ remarkably from another. It can’t be consistently defined in any great detail.
Paddy Corry’s commentary on the topic sums it up nicely:
My DoR is simple. It’s not a definition. It’s a question: do I have enough information to start working? That’s it.
So is it time to drop the definition in DoR?
The Minute List
We have and we now have what is more akin to a checklist of considerations that we call the Minute List since it should take less than a minute to go through during refinement for each PBI.
This would need to evolve based on your particular product.
The list below is our list and while some may seem common it relates to the Product we’re working on, the teams we’re working with and a view of the challenges we’ve had in the past.
Note that we’re using Azure DevOps Scrum Process Template and so there is specific reference here to system fields that need to be completed. We’re also using teams where English is not the first language and so there are a couple of items here where we’ve sought to clarify ‘copy’.
- Does the Title reflect the work?
- Do we have a Description and Acceptance Criteria?
- Do we need to provide a user interface mock-up or values for UI items such as fonts, colours, buttons, icons?
- If there is user-facing text then the exact text must be provided in the PBI
- If there are calculations then the PBI must contain a worked example
- Are there any dependencies and are they defined (and linked)?
- Is it small enough for the sprint?
- Does the size also reflect the level of effort to test (we had a lot of small changes that had a much larger testing effort)?
Refined Process
While this worked as a guide the main benefit was saw was in changing the process of how and when we moved the state of the work items. We enhanced the Scrum Process Template in Azure DevOps to add these states.
- NEW. New work items are in a New state until I, as he product owner, have enough details to start talking to the team about it. When I do, it is moved to the Refinement state.
- REFINEMENT. We have a regular refinement meeting with the entire team where we go through these PBIs and jog through the Minute List. During this state the team also provides the Effort estimate.
- APPROVED. Only when everyone is happy do we move it to Approved .
- READY. Only when all PBIs in a Feature are Approved do we move the parent Feature to Ready.
The act of having the entire team Approve a PBI was key. The team was empowered to veto that move if they weren’t comfortable and it was no longer a PO decision.
Feature vs Story/PBI level readiness
One of the practical issues was the modern technique of grouping Stories/PBIs into Features. Both of the most used agile frameworks (Scrum and SAFe) use this construct.
Many of the questions historically allocated to DoR, such as those in one of the original definitions or even more recent commentary, really apply better at the Feature level:
We do provide that detail where needed at the Feature level but it doesn’t need to be duplicated in each of the feature PBIs.
We start the refinement of a feature with a very in-depth explanation of the business value and business impact but most of the issues we’ve seen can be resolved through asking and answering the more practical questions on the PBI.
Split view
This Feature/PBI content focus also helps standardize our communication channels.
The Feature level content is very much focused upward to the business stakeholders and users. While we have full transparency and I do use them to frame a more detailed conversation, we don’t expect the business owners to dive into the Stories/PBIs.
Similarly while the development team should read the feature details, they spend most of their time at the PBI level.
Setting these expectations saved us from having to dumb down the PBIs to be understood by non-technical users or littering our Features with implementation details that are largely inconsequential to the business owners.
