backlog – Rajat Bhalla

That Nasty Word Called Backlog

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.

Agile

Prioritising Product Development

I want a big car (well, more than one), a large mansion, and definitely a yacht too…NOW! We have all had this dream (or maybe you have better sense than me). But we know we can’t get all of it at the same time. We may get some of it gradually. So what do we do? We prioritise. And we work with what we have. So instead of a big car, I am happy to have a car big enough for my family. I am okay with an apartment that can house my family comfortably for now. I will work towards getting a bigger house but that would come later. The yacht might never come. This is true of the physical universe we occupy.

Software dreams aren’t very different from regular dreams. We want a beautifully designed app and having all the features we can think of (including a hair trimmer and missile launcher). Now. And guess what. Software reality isn’t different from the physical reality too. So, we prioritise. And we iterate over things improving them continuously till we achieve the desired result.

An Agile Development Plan for a product starts with the strategy and vision at the highest level. The next level consists of feature releases in-line with the high level strategy. The next lower level breaks down releases into iterations that build the features planned in the release bit by bit incrementally. There are two ways to look at the schema of things. Vertical drilling would involve peeling layers of the strategy as above. Horizontal panning would involve prioritising features across the timeline of the project development schedule. The whole gamut is prioritised – what would be required when entering the market to attract early adopters, what all features to build thereafter to strengthen the hold and enhance the customer base, and finally, how to add value to the product iteratively and incrementally.

You start by creating a Minimum Viable Product (MVP in short). An MVP is not a low-quality, half-baked product. It is a subset of the whole product with main objectives of getting initial traction and generating feedback. That feedback provides input into the prioritisation process (and release strategy) on what features need to be included in the next release. Each release generates more feedback that is fed back into the system for improvement. Within each release plan are features that are improved iteration by iteration. Each iteration encompasses a list of user stories which are again prioritised for delivery within that iteration. So even if something doesn’t make it to the release, it is always the lowest priority item for that iteration.

The key points to remember are:

You do not plan everything in detail all at once. You plan in layers.
Not everything has the same priority. Features and releases are prioritised along the development cycle.
More emphasis is laid on the feedback in order to laser focus the product to the market rather than initial all-inclusive feature set of the product.

Agile

Detailing Backlog Appropriately

On one of the projects I am managing currently, I noticed that the product backlog was actually growing rather than shrinking as we were progressing through sprints. At one point, there were close to hundred and fifty stories in the backlog, all detailed and ready for planning. Some were even accompanied by ready UI-designs. The reason for the increasing backlog size was that everything under the sun was being thrown into it for future development. While this might sound fine (you would want to write down somewhere the features you might need in the future and what better place to write them down than the backlog), there was something definitely going wrong.

I realised that every time we would plan a new sprint, instead of picking previously written stories from the backlog, we were writing new stories as the client had come up with a new feature that had priority over rest of the backlog. This is completely understandable and even recommended. After all, you would like to use the feedback you are receiving from the market to add new features. If the window of opportunity for a new feature is now, no point putting it on a backlog for later. It requires attention now. But what about all the stories (and the effort invested in detailing them and designing the UI for them) in the backlog? Soon they would become obsolete. They would never see the light of the day. If at all their turn would come, they would require changes (in both the functionality and the UI expected) as the current functionality would have undergone a change by then. In terms of Lean thinking, this was clearly muda (“waste in Japanese). I could have done better things with the time I invested in detailing those stories and helping create their UI-design.

The other day, I was watching a show on some television channel (I think it was Comedy Central) and I noticed the way they presented their schedule:

Now (the show currently being telecast)
Later (the show after the current one)
Never (the show after the “later” one)

This was a fun way to provide a relative schedule, especially the “never” part. Considering that I am always in a “meta” state of mind looking at things above their current context and trying to correlate aspects from different contexts, the schedule format hit me as a solution to my backlog problem.

While the stories in the current and immediate next sprint (“Now” part of the backlog) would be detailed enough, the stories in the next two to three sprints (“Later” part of the backlog) would be relatively coarse grained. Stories even further down in the backlog (“Never” part of the backlog) would have no detail whatsoever. They could be as simple as a single line, five-word statement (similar to epics in Scrum parlance). This would help the backlog stay current and sharp, help me focus my time on more important tasks, and reduce waste. Of course, we would continue to add to the backlog any item we “might” need in the future but it would not be as detailed as before, it would simply be a reminder, like a to-do.