Sunday, August 23, 2009

How many Backlogs do you need?

Hmm... there used to be two backlogs in scrum IIRC:
the product backlog, owned by the Product Owner and the sprint backlog owned by the team.

Nowadays, scanning through contemporary tweets and blog entries, there are at least (in various amounts)

  • Product Backlog
  • Sprint Backlog
  • Impediment Backlog
  • Technical Debt Backlog

So I wondered: Do we really need them?
Right now my answer would be "Yes" and actually I think most of us use them already - albeit more or less secluded.

Of course the Product Backlog and the Sprint Backlog are completely visible all the time.

The Impediment Backlog and the Technical Debt Backlog OTOH are not quite as popular - mostly because we "should not have them" in the first place. If all "impediments are resolved within 24 hours" and "technical debt is paid back before a task is completed (aka Done)" and we "leave everything cleaner than we found it" both "Backlogs" are more like personal lists with a lifespan of less than a day.

Unfortunately reality is slightly different in lots of places and so we should recognize this fact and install corresponding backlogs with a fitting set of attributes.

So, what could these attributes be?

For the Impediment Backlog I'll try:

The usual stuff:

  • ID (Yes, I need an ID - but YMMV )
  • Synopsis (An understandable but very short description of the impediment that can be scribbled during the standup meeting )
  • Description (A longer description, that explains the impediment to the non-initiated)
  • Date created (well...)

The specific stuff for the impediment backlog:
(All of these should be considered optional and used as growing lists - just to make sure the impediment gets the attention it deserves)

  • Number of Mentions (A counter - implemented e.g. as a tally chart on index cards - to determine if the impediment is really such an impediment as it first seemed)
  • People affected
  • Tasks affected
  • Stories affected
  • area(s) affected (e.g. Specs, Tests, Coding, Deployment, Design etc.)

For the Technical Debt Backlog I'll go with…

The usual stuff (what did you expect?):

  • ID (Yes, I still need an ID - but YMMV still )
  • Synopsis (An understandable but very short description of the dept imposed than can be scribbled during coding or the standup meeting without much of an interruption)
  • Description (A longer description, that explains the debt and its effects to the non-initiated, probably written later)
  • Date created (well...)

The specific stuff for the technical debt backlog:

  • Area affected (e.g. Architecture, Design, Delivery, Deployment, Stability etc.)

Hmm.. that's not so much - I wonder if the list will grow over time.
I'd expect some of the TDB (technical debt backlog) to turn into tasks eventually, but they might also vanish simply because of DoD (definition of done), "no broken windows", "leave everything cleaner than we found it" and other related practices.
I wonder if it would be possible to derive the interest rate of technical debt... but that's quite another story.

No comments: