Backlog grooming.

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.

Advertisements

3 thoughts on “Backlog grooming.

  1. I think most scrum aficionados would recommend one backlog. Having multiple backlogs often just hides the fact that teams aren’t working on the top items.

    Personally I prefer 2 backlogs, or specifically 2 parts of the backlog. One for items that you might conceivably do in the next year (or a timeline that makes sense to you), and another slush pile for the rest. That way you can focus on sorting the items that are higher in priority, which is a more manageable feat. If you review the slush pile occasionally you can pull out items that are now more likely to get done, or delete things that are no longer relevant or have been done.

  2. Hi Cindy,
    Thank you for your input!
    Sounds like you have a backlog strategy that could actually work well within our organisation and release cycles…
    I really like your blog too – will definitely be re-visiting for some more inspiration.
    Lina

  3. Pingback: Backlog grooming – by Lina Pullinger

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s