Grooming the Backlog

Grooming the backlog was a concept I first heard attending a Scrum Master training course and at first felt like an appeasement to those non-agilists who ridiculed the no-forward-planning approach espoused by the scrum practitioners. However, we’ve found it very useful to focus a small amount (5%) of time in each sprint to looking into the future to

1. Make sure we have enough well defined (Ready) work in the backlog for the next 2-3 sprints
2. Reprioritise the items in the backlog
3. Break down large PBIs into smaller ones
4. Remove any duplicates
5. Re-estimate any new or large PBIs

Each one of these activities are quite distinct and require different resources and skills and so we do them collectively with the entire scrum team, scrum master, and product owner present.

We normally have a grooming 2-3 hour meeting per sprint – usually in the middle of the sprint since all the other meetings occur at the sprint start or end and it’s good to spread these things out. In the meeting we review those PBIs marked as Ready and re-affirm that we’re happy with them, then assess whether we have enough Ready PBIs (2-3 sprints worth), if not we’ll ask the product owner to identify some other stories with high priorities and start fleshing out the conditions of acceptance until the team is happy that the detail is sufficient that we could start development. We’ll then review the point estimate – which may have gone up or down depending on the clarifications made.

Some of the PBIs selected by the product owner may have been epics in which case we’ll break these down into smaller components, usually leaving some in a more vague ‘not ready’ state and only focusing on the higher priority items. Over time this process can result in some PBIs expanding as they are refined which can often result in discovering a lower priority PBI sitting in the backlog which has actually been done as part of the expanded PBI, for this reason every couple of sprints the scrum master and product owner review the backlog to identify any duplicate PBIs which could be removed. The product owner may also remove any PBIs which he or she feels is simply no longer required.

Often I hear of agile teams who define the PBIs for a sprint at the start of each sprint. This probably works well for longish sprints for mature products with maintenance releases at the end of each sprint but if you’re working on a long term project and need some picture of the current scope maintaining and grooming a backlog is essential.