During Sprint Planning many teams resist breaking down Product Backlog items selected into tasks, preferring to rely on gut feel and yesterday’s weather to give them confidence in their forecast. This approach works for some teams and if yours is one of those then great, keep doing that. However, many teams take that approach because they do not know how, or don’t want to, or don’t think they should spend time getting into the detail. For these teams, it is important to surface the reasons for resistance and support them in overcoming them.
This article is about tackling the first point:
How can you break down Product Backlog items into useful tasks?
The most powerful techniques I used while a developer to break-down Backlog items, and still use with teams today, is to think about constructing a sequence diagram for the feature. What messages are passed between sub-systems and in what order? The answer to these questions means we can then map a task to each message that doesn’t already exist and identify new sub-systems.
Breaking down Backlog items proves an effective way to achieve a few key things in the Sprint Planning event:
- You have a design – with a sequence diagram you have a UML design on the board; ideally, take a photo and use this as your documentation. It at least captures the conversation and intent for later, more “formal” documentation. Also, if you have people with more architectural concerns in the team they can be involved in laying out the sequencing, in collaboration with the rest of the team, and they are capable of relaying that intent back into the relevant governance body – be that community, chapter or department.
- Everyone knows what he or she is building – the design, and tasks to complete the design, are laid out in the planning. Updating the model during the Sprint can be as simple as updating the whiteboard as new information (and tasks) arise.
- You uncover issues – nowhere in the system to service a message? Maybe it is not a trivial change anymore. Can’t find anyone who knows if the sub-system does what you think it does? You have time to find them before committing to delivering the feature.
- Everyone can agree the work is possible in the timeframe – if not, talk with the Product Owner some more. This detail will give you the confidence to enter the Sprint with the Backlog item or allow you to explain to the Product Owner why you are not comfortable taking it in. Have a further conversation about what you could deliver instead – maybe a subset of the feature, maybe something entirely different.
- You can plan team development – see a task you would like to learn how to do? Shout out, agree to pair with someone more experienced and build your skill-set. This way the team can move itself to higher levels of cross-functionality while still delivering value to the Product.
There is no silver bullet
Obviously, this does not cover all cases for software development; indeed, for some, it may cover very few. However, opening conversations about breaking down work into more manageable chunks has been consistently useful. This approach has uncovered areas that nobody had previously considered in many situations.
If you have used similar techniques, or something else entirely, then let everyone know in the comments below.