Many Agile techniques rely on a backlog of items to work upon. Ideally everyone would know all the items that are in the backlog, but practically this is not always possible. A typically process is to have a handful of team members groom the backlog to prioritise the order the items. The very real danger is that when a team starts working on an item they do not have a holistic picture of the backlog. Without acknowledging (rather than needing to fully understand) the future requirements the team risk making choices that will need to be redone.

The Tour Bus Example

One of my favourite Agile examples is the Band Tour Bus. A band has struck it big overnight and they need to go on tour quickly, so they need a tour bus. A waterfall model would dictate that all the requirements for the bus are fully specified, costed, prototyped, etc. When the bus is ready everyone’s forgotten about the band and many new groups have replaced them. There is no money to pay for the bus – sad times. Enter Agile, a backlog of all the features for the bus are created and it’s deemed that a basic bus will be delivered first. Hurray the band make it to their first gig, granted not in style, but they get there. Now, let’s say that part of the bands master plan requires a long tour and they need to take their families. The occupancy requirement goes from 4 to 12. Upon grooming the backlog it is decided that feature will be done 6 sprints into the development. However, the development team haven’t been told and create a lovely in-bus bathroom. Sprint 6 arrives and there is no real-estate to create the additional living quarters, disaster. How can we avoid this problem?

How to clear the blinkers

As with most things in Agile the simple solutions are often the best;

a) Grooming team review the start of the work. The grooming team have the facts, they should review the start of work to ensure there are no obvious clashes or dependencies on items in the backlog

b) Items are categorised to allow all team members to quickly search for potential dependencies. When a new item is examined the team run a quick search over the backlog.

Whilst (b) is a useful mechanism, especially for longer running projects (e.g. products) where the grooming team changes, I would always recommend at least (a). If your team only considers the narrow view of the next Sprint or the next set of work items then the project will be at a real risk of expensive re-writes.