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.

What’s the story?

For the next few days, it’s going to be head down writing user stories for a new feature. In order to get into the right mindset, i’ve been spending some time reading and re-reading some articles related to how to write a successful user story. there is a lot of information out there, but most of it boils down to the simple sentence of:

As a [user role], I want to [goal], so that I can [reason].

As such, the principle is very clear, however the output isn’t always as clear, unless of course you were the person writing the story. One thing that most articles and how-to’s stress is how important it is to discuss each user story with the entire scrum team. This conversation is the key to ensure understanding for all parties. The product owner can be sure that the stories are understood and also benefit from the feedback of the testers, developers and scrum master, to improve the story writing in future. The team of testers and developers can use the discussion time to ask any questions, clarify and start jotting down ideas on technical details and testing approach for the feature.

In my projects so far, unfortunately we haven’t spent that much time on discussing user stories, particularly for our last effort, as we actually handed over the user stories and all of our other output to another scrum team. Not having that discussion definitely caused some confusion and a certain amount of re-work for the scrum team taking over. As they were not involved in writing the stories and we didn’t have the dedicated time during sprint planning to discuss each of them, there is a level of uncertainty as to what each story actually means. Reading over the stories again myself, I was fairly sure that they were pretty clear, but then again, I wrote the majority of them, so obviously I would understand.

I think my take away after that exercise is that I need to be a lot clearer in my user stories; make a bigger point of specifying the who for each user story, whether there are multiple users or not, and most importantly really stress what the benefit or the why will be. It seems that as soon as people know the why of a story, they are much more likely to understand the what. And considering that we are working agile – whether their interpretation of the what matches my own doesn’t really matter, so long as it serves the purpose of the why for that particular who.

Having worked in waterfall for such a long time it still feels a little strange to not specify details upfront and even with all my good intentions to focus on the why, the output of my user stories was still firmly centered around the what.

I suppose, at least I notice my own mistake, so this next time, I can do better and truly focus on the who, the what and especially the why of the story.