Before Agile, I always considered the word Backlog to have a negative connotation. It always signified that I was lazy and that I had work pending. It always hinted at my inefficiency. Google’s synonyms for backlog (logjam, pileup) aren’t very promising either.
However, Agile rescued me from the dark side (ok, maybe I am exaggerating but you get the idea). In Agile, backlog is not a nasty word. It actually signifies that you have a roadmap of what shape your project is going to take in the future. A backlog is a repository, in fact, a nursery of future features where they evolve over time. It is a hopper that contains user stories that would form the product in the future.
Every feature that you would like to have in your project is present in the backlog in the form of a user story (or maybe an epic). A backlog, ideally, should be DEEP (credit for this acronym goes to Roman Pichler, author of Agile Product Management with Scrum): Detailed appropriately, Estimated, Emergent, and Prioritised. Let’s see what each of these fancy words means.
- Detailed Appropriately: High priority backlog items (at the top of the backlog) are defined in detail and are ready to be discussed in the next iteration. Lower priority backlog items (towards the bottom) are more coarse grained. The items in the middle are, well, somewhere in the middle with respect to detail too.
- Estimated: Each item in the backlog is detailed. Coarse grained items have coarse estimates while fine grained items have a relatively accurate estimate (if there is a term like that).
- Emergent: The product backlog continues to evolve over time with items being added to it, removed from it, modified, split into smaller stories, and so on.
- Prioritised: Each item in the backlog has its own priority vis-a-vis other items in the backlog. The priority of stories, like the stories themselves, can change. Overall, the items at the top of the backlog have a higher priority and the ones at the bottom have a lower priority.
In order to have a smooth Sprint (and Sprint Planning), a groomed backlog is imperative. Failure to groom the backlog can take the project on the wrong track and leave the developers confused.
If you are aware of the acronym GIGO (Garbage In, Garbage Out), you would know that wrong input can create wrong (sometimes, even worse) output. Same is true of backlog.
Do not fear having a backlog. Instead, fear having a backlog that doesn’t evolve, a backlog that doesn’t reflect the upcoming features, a backlog that doesn’t show you at a glance the higher priority vs lower priority features.