Month: April 2013

Agile

Detailing Backlog Appropriately

 

Backlog

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.

Agile, Automobiles

If Scrum was a Motorbike

Scrum Motorbike

Scrum and motorbikes, two things that I am very passionate about. Subconsciously, I could sense a parallel between them. When I actively thought about it, the picture became clearer.

Consider the Team (developers, UI designers, testers) in Scrum. Its mandate is to deliver a working increment each iteration. It is what powers the product / project. It is similar to the engine of a motorbike. It converts stored up energy (in the form of fuel) into motion that drives the whole. Akin to a Scrum team, it delivers usable power each cycle of the n-stroke engine. Similar to a Scrum team that iterates over the backlog, the engine iterates over the strokes in each cycle. The way an engine gobbles up fuel to deliver power, the team completes stories from the backlog to deliver a working software.

Now you don’t need to be a gear-head to know the importance of keeping the engine well oiled. That is where the ScrumMaster fits in. He is the engine oil. The oil keeps the engine running smoothly, lubricating it, ensuring that there is no grinding against the metal. Similarly, the ScumMaster keeps the team protected of outside interference, ensures that there are no impediments in the progress, that the team is not overloaded, that there is no grinding between the team members. He keeps the team running smoothly. A good engine oil keeps the parts well lubricated even when the engine is running at a high RPM, the temperature is high, the stress is high. Similarly, a good ScrumMaster ensure that the practices are followed even when the team is under stress (the scenario of the team being under stress is infrequent but possible when the team commits to deliver more than they can complete so as to meet the aggressive goal).

Where does the Product Owner fit in? I believe he is like the handlebar of the motorcycle. The product owner provides direction to the team. It leads the team to the intended goal. If the team deviates, it provides correction (during Sprint Reviews) so that the overall destination can be reached. The way a handlebar can be used to avoid obstacles along the path, the product owner can clarify the doubts of the team to keep them focussed on the right goal.

Of course, there are a lot of other parts in a motorcycle, and many more and varied parallels can be drawn, but this is what struck me. If you keep the above in prime condition, you can assure yourself of a smooth journey. Ride hard, ride well.