Reading about backlog grooming on other blogs and talking to other Product Owners, it seems that backlog grooming takes place primarily within a certain release or even just from sprint to sprint. What I am noticing in our project is that backlog grooming further into the future is proving a little tricky. Especially for all those requirements that we gathered when we were still planning to continue developing in waterfall as opposed to agile.
Those requirements were typically written in a different format and are a lot more specific, as is required in a waterfall project. Now that we have switched to agile, integrating the “old” requirements into our current backlog is not quite as simple as turning them into appropriate user stories. Most of them have to be rewritten rather than just be updated into user story format, some are better off grouped into one agile epic and some really are just too specific technically, which would stifle the iterative process of agile. Not to mention the huge effort of sifting through the backlog of hundreds of “waterfall” requirements trying to identify those that were either implemented or made redundant by some of our more recent development.
At the moment, since we have switched over to agile earlier this year, I am not sure we have found the most effective way to manage our backlog for the future. Rather than having one source of epics and features that we would like to see implemented at some point, it seems there are various versions of spreadsheets, requirements documents and vision presentations. For the most part, these requirements and features are organised and categorized to make it easy to prioritize them, however that is largely true for the new additions, not necessarily for any of the older “waterfall” items.
I am not personally the keeper of this backlog, so I can’t speak to how easy it is to manage on a daily basis, what I can say is that as an outsider it is difficult to get the big picture. Perhaps compiling all of these into one centralized backlog is the obvious thing to do, but admittedly that may not be as easy as it sounds. While we have implemented and are using online software to manage our sprint and release backlogs, our product backlog still is very much an off-line beast.
Now that we have a couple of agile releases under our belt, perhaps it is time to develop a more transparent backlog process for the future – otherwise we may end up having to spend a lot more time grooming.