The Scrum Team that I was coaching, during a time were repeatedly struggling to finish the items that they have taken up for a sprint.  They could not meet their sprint goal.  They repeatedly failed to create a product increment.  This was discussed in the retrospective, and team brought up various blocks and surprises which they encounter on their way, causing delay.  A few examples for the blocks that were brought up during the retrospective were access to environments, tools availability, integration interfaces, data for test etc.  The team said they are adhering to their ‘Definition of Ready’ (DoR) before picking up any backlog item.  In spite of that, they could not come out of this vicious circle.  Time and again they met with unexpected newer blocks, which prohibited them from meeting the sprint goal and creating the increment.

Suggested Solution

Definition of Ready (DoR) – is something that is ‘custom created’ by those Scrum practitioners who are fond of naming the processes, roles and artefacts.  There is nothing called Definition of Ready (DoR) in Scrum, but only Definition of Done (DoD).  There is a deep-rooted reason for this.  To simply state, an empirical development having a potential for requirement discovery, can never ascertain requirement readiness.  I observed that people have coined DoR to have an equivalent to a signed-off requirement, or for something that implies a well-defined requirement or a specification. 

I looked at the team’s so called DoR.  They had everything that is required to start a work, primarily from a “detailed” requirement perspective.  What the team was missing is that they never looked into their Definition of Done (DoD) to create their readiness list. 

For instance, if my DoD is to get the increment for production deployment, then my readiness list should have all the items that are required to get my feature till production, and not just a detailed requirement.  This include environment availability, version control, build and integration pipelines, test automations (both functional and non-functional), deployment pipelines and many more.  I found that the team was just looking at the requirement readiness, especially from an understanding perspective, to start the work and not the whole DoD, that was causing the problem.

I took sometime explaining the team, the Sprint Planning and its rationale.  During Sprint Planning, every product backlog item that is picked up is expanded to ‘work items’ keeping in view the Definition of Done.  Team who have production ready as their DoD, will normally end up having around 100 to 150 work items (tasks) for every Product Backlog Item.  This should be a well expanded list.  For those who are familiar with production planning in a discrete manufacturing, it is similar to the BoM (Bill of Materials) of a finished product. When teams complain of impediments and surprises, I always tell them to go back to their sprint backlog.  Team members often have the habit of keeping most of the work-items, (tasks) at the back of their mind during sprint planning, tagging them as ‘I know this’, its  ‘simple’ or ‘insignificant’ – to call out, like checking access to an Integration Pipeline, where granting access may have an organizational SLA of five working days, impacting their sprint goal.  Hence, experiment around Sprint Planning, keeping the DoD focus, to surface those – so far unseen impediments. This practice took some time for my team to adopt.  They failed again few times, since it was not as easy as it appears to be.  After supporting them continuously for few months, I was observing their sprint planning one day.  I could clearly see a deeper understanding that has emerged from their practice.