Backlog (Lack of) Management

To be honest I've been very negligent in not properly managing our product's backlog.  I'd been able to get away with it because I'd not been under much scrutiny, I'd been able to manage it mostly from my head and an e-mailshot, and I'd had other things to do that had been more important (or at least I claimed they were more important and I had to be the one to do them).

Our product's backlog is enormous.  Over 500 lines in a spreadsheet.  Trying to prioritise that and ensure that there is no duplication was going to be a futile task.  So, I decided to adopt a principle from kanban and "start with what I have".  Given the reference to kanban it should not be so surprising to learn that what I had to start with included a kanban board which indicated exactly what was being worked on at what stage and what was to be worked on next.

The first step was to synchronise the kanban board and the backlog.  This may seem like duplication - because it is - but it allows anyone looking at the backlog to see the current context and how it fits into the rest of the backlog without looking at two different media (a board and a spreadsheet).  Anyone can now look at the backlog spreadsheet and see what's been delivered recently, what's being implemented, what's a prototype, and what's to be done next.

The next step was to look at the 400+ other backlog lines.  These had been gathered over the years from various sources - developers and salespeople's whims, prospective customers' whims, customer complaints, etc.  Fortunately we'd recorded the source for each of these requests.  Unfortunately the person writing down or transcribing the requests had not always done a good job of ensuring that the request was understandable to other readers.  Trying to prioritise all of these individual requests would be pointless, but I could at least group them into related areas.

Grouping the backlog of requests then allowed me to get a picture of what had been requested in different areas, irrespective of who had requested it and when.  I could now identify duplicate entries and remove them.  I could also identify related requests and combine them.  The lack of grouping previously had also made the categorisaton of requests rather haphazard, further contributing to the difficulty of managing the requests.  A series of painstaking reviews have now imposed some consistency on the categorisation.  The result is that the reader can now find information more easily, which is a fundamental (yet often overlooked) requirement of any document.

Anyone working on a particular area can now see if there was a minor requests in that area or a refactoring suggestions in that area of the product and choose to incorporate that minor request or refactoring into their current feature development.

I've still to bring the backlog fully up to date, but now it is at least manageable.