A Different Approach to the Agile Product Backlog

When we first headed down the route of implementing agile into our development practices, like most organizations, we hired a trainer to come in and walk us through the various best practices and ceremonies used to embrace the Agile Manifesto. As recommended, after each sprint we found ourselves tweaking these best practices during our retrospective to fit what worked and what didn’t work for our organization.

One of our first major decisions was to quickly abandon all forms of technology for our user stories, tracking our sprint progress, or maintaining our product backlog. We taped everything to the walls of our conference room. As with most product backlogs, our purpose was the same: to have a list of groomed stories in order of priority that could be selected during the next sprint planning session. These groomed stories were then taped to a sheet of paper in order of priority. At the end of each sprint we would select the next items on the product backlog, and off we went to coding. This worked for a while, but we ran into several problems using this method:

1. We had multiple product owners for our different projects, and getting an agreed-upon order of priority was a difficult task when everyone felt their request was number one.
2. The items not in the product backlog were randomly taped to the wall with no real order or priority for us to know what should be reviewed and groomed next.
3. There wasn’t transparency to everyone about the priorities and upcoming requests.

The Evolution

We knew there had to be a better way of managing our product backlog that would solve these problems, so we began tweaking. Our next attempt at a product backlog was a SharePoint list that captured at a high level the various requests being received from the different departments. We would pull items from this list and gather requirements, write user stories, and groom the stories for our product backlog. We still taped our groomed stories to the wall in sequential order based on what we thought the priorities were from the business. We thought we were able to solve some of our problems; we now had a method that provided more transparency into the incoming requests from the various product owners.

We had a better idea what items should be reviewed and groomed next, but we still found we had some issues. When sprint planning came around at the end of the two-week sprint, we were still being told that we groomed the wrong stories due to shifting priorities. There had to be a better method; we just had to take another stab at it.

The Solution

Today our product backlog is no longer called a product backlog (even though that is what it is, essentially). Our Unlike the sequential list we had previously, this top ten list actually contains more than sixty requests! Wait a minute, you say; how can you have a top ten list with more than sixty items on it?

Well, let’s start with how items make it to the top ten list. Because we have a large number of product owners, we have them submit their requests to the business owner, who adds the item to our SharePoint list. The product owners are grouped by five different segments in the department. Each of the five segments meets with the business owner to identify their list of top ten items. Instead of limiting the product owners to only ten requests, we allow them to submit and rank their entire request list into the top ten. Sometimes this means that for a segment, we have a number one priority for three different requests. For each request that is submitted, a title card is created with just the title of the request listed.

Our product backlog now contains ten columns, numbered from one to ten, and six rows—one for each business segment, plus a row for our software development team to prioritize their technical debt. The title cards are placed according to segment and priority, and if already groomed, they have the associated user stories and tasks attached to the title card. Title cards and user stories share the same space on an area that covers an entire wall. Title cards that do not have groomed stories are now clearly identified so that requirements can be gathered and groomed before the next sprint planning session with the business owner.

At any time during the sprint, the product owners and business owner are invited to come down and rearrange the order based on their shifting priorities and new requests. Now the shifting priorities are apparent to everyone.

During our sprint planning session with the business owner and product owners, they select the groomed user stories from the board in order of their identified priorities. They start at the first column and keep picking groomed stories until they have selected enough user stories to meet our sprint capacity. Everyone enjoys our sprint planning session as we watch groomed stories being pulled from the wall and added to the sprint.

We Are Still Evolving

To show even more transparency, during the most recent sprint, we began attaching stickers to our title cards and user stories. These stickers are used to indicate when a request or user story has hit a block—either because we are waiting on additional information from another department or for a technical reason. Either way, the business knows visually and immediately what is being blocked and where their assistance in unblocking is needed. We also have stickers to indicate to everyone which title cards are currently being worked to generate user stories for grooming before the next sprint.

We aren’t saying this is a better way of accomplishing the same thing as the product backlog; for our product and business owners, as well as our software development teams, it is just a better method for the way we do business. This method solves the problems we were faced with during the first iteration of our product backlog and evolves our original system into something that provides more transparency into our processes. Over our upcoming sprints and retrospectives, I’m sure we will be tweaking it even more. For now, it’s what works for our organization, and we are sharing because it might just work for yours as well.