Welcome back and apologies for the delay but life has been especially hectic with the final, frantic flurry of activity trying to make sure that the 3rd Scrum Australia Regional Gathering went according to plan.
Anyway, in this next installment we are going to be sticking with the Sprint Backlog to tackle possibly the most common operational dysfunction that we see out there, namely poor (or non-existent) Product Backlog Refinement (previously known as ‘grooming’). The manifestation of this dysfunction is multi-pronged including long, tedious Sprint Planning sessions and iterations that seriously go off the tracks, via frequent chopping and changing.
Poor Product Backlog Refinement can lead to long and tedious Sprint Plannings sessions.
One of the core reasons for this is the myth that because we have cross-functional teams working together it follows that we need to swarm on a requirement end-to-end in a Sprint, which further implies we have to perform all of the relevant activities to complete the requirement all in the same Sprint. In other words for any given Product Backlog Item we need to do the functional design, technical design, test design, development and testing all in the one (and same) Sprint.
So here’s the rub; functional design is often very subjective requiring socialization with external stakeholders and this can lead to a certain amount of unpredictability.
Trying to include this level of ambiguity within the Sprint that you are actually trying to implement the solution will often lead to delays, waste and confusion. The trick here is to ensure that the Product Owner in conjunction with any other supporting designers (within the team) and stakeholders (outside of the team) needs to be forging a little bit ahead via the activity known as Product Backlog Refinement to ensure that Sprint-Ready items are being fed into Sprint Planning for implementation consumption.
What does Sprint-Ready look like? Well that is where a well-formed Definition-of-Ready (DoR) comes in which acts as the entry-criteria for any Product Backlog Item wishing to make it into the next Sprint Planning session. Some key high-level points to include in any team’s DoR include:
- Technically feasible
- Specific and clearly understood by the Developers
- Can fit into the Sprint
- No external dependencies
Now we certainly don’t want Product Owner’s to be too far ahead with Sprint-Ready PBIs as this can lead to other issues of waste and rework, but being one or two Sprints ahead is very healthy and reduces the potential ambiguity. This doesn’t mean that they work in a separate team, or in a ‘different’ Sprint but it does mean that their focus is split in any given iteration between supporting the programmers and testers in their efforts to complete the next validatable increment while also focusing on preparing Sprint-Ready requirement items for technical delivery in the upcoming Sprint.
Product Owner’s are scouting ahead, focusing on preparing Sprint-Ready requirement items for technical delivery in the upcoming Sprint.
Bottom line is that we want the requirements to be fit and healthy before consuming them in Sprint Planning. Thinking a bit ahead is not just common sense but frankly it is mandatory to avoid the dysfunctions of the ‘all-in-one’ approach when your team has to work with external groups.
Onto the next one!
Once again, I thank you my fellow mythbusters for joining me on the eleventh leg of our truth-revealing journey. See you next time!