​Backlog Gone Wild? You Can Still Tame It

Managing the backlog is an important aspect of a functional team. It helps keeping a sustainable pace of relevant and good-quality deliveries.

But sometimes you realize your backlog just became the user story version of a big ball of mud. It might not be too late to get it back on track, so let's take a look at some ways in which you can achieve that.

Follow the Value

As Deep Throat (allegedly) says in All The President's Men: "follow the money". In software development we have a similar advice: the focus must be on the things that will add business value to the product.

So, if something might add value to the product, let's capture it as a user story in the backlog to play it later, right? Well, not so fast! 

Stacking stories in a one-dimensional backlog assuming that they will independently add value to the product is one of the main sources of scope creep. This is where INVEST goes awry and fails to work in the long run. Anything you include in your backlog must be tied to a clear (and measurable) goal.

Organizing the Backlog

On a recent project, we had only the high-level goal of the project as an Elevator Pitch and user stories were created within epics. As the project went on, the team lost the sense of purpose for the stories in the backlog. Epics only listed things to do instead of steering us into a planned direction.

Planning the iterations was becoming harder and we soon realized there were more user stories yet to be played than iterations to fit them.

To solve these problems, we planned a backlog-trimming workshop with four simple steps:

1. Identify and prioritize goals

In the first exercise of the workshop, the team mapped user journeys to identify what the users wanted to achieve when interacting with the application. We then grouped that information as goals for the product.

Picture 1 - The user journey we mapped

Based on what we learned from the exercise, it was easy to see the potential impact for each goal, which helped us to prioritize them accordingly.

2. Group stories by goals and users

Next we created a matrix where we arranged these goals in the x axis, sorted by priority, and users in the y axis, arranged from the most to the least impacted by the product. 

We ran through the backlog and, for each user story, identified the impacted user in the matrix and associated the story with a goal.

Picture 2 - Stories grouped by goals and users

Having completed this exercise, we got a clearer picture on what we wanted to achieve, for whom, and why. We could clearly let go the stories associated to the least priority goals for now because these goals were not crucial to the success of the product.

The second decision we had to take was on how we would impact our users. We could divide our work in vertical chunks (trying to meet a single goal at a time and reaching several users), or horizontal chunks (trying to give a single user the functionalities he/she needs to meet several goals that are relevant to him).

As this product worked with workflows, it made sense to focus on a single goal at a time, giving all the involved users the functionality they needed to do their part of the work.
 

3. Pick the important stuff

But again, this wasn't enough. The backlog still had more stories than we could handle in the time we had left.

So we divided the remaining stories in three levels: Basic Needs, Negotiable Needs, and Uncertain Needs.

Picture 3 - User stories being grouped in levels

In the Basic Needs level, we grouped the pieces of functionality that had be implemented to make sure that the basic mechanics of the workflow were met. These were small enough experiments that could be validated soon to tell us how close we were to reach the goal.

In the Uncertain Needs level, we grouped the stories that were clearly "nice-to-haves" in the sense that they were not required to allow the users to meet their goals. These stories covered possible improvements (or edge cases) for things we still had to learn more to determine their real value.

4. Negotiate and focus on the most valuable bits

At that moment we knew two things for sure: the stories we had to implement and the stories we could remove from the scope.

In the middle level (Negotiable Needs), we grouped all the remaining stories. For each story there, we asked the following questions: 

• Regarding the goal, how much value does this story represent?
• Can we isolate the basic mechanics into another story (extracting the most basic functionality out of it and leave the remaining parts as a "nice-to-have")?

By asking these questions, we moved a reasonable amount of work to the upper level so we didn't need to worry about them for now. The remaining items, the most valuable bits, were moved to the Basic Needs level.

What's Next? Your Turn!

With these simple steps we managed to have a much smaller subset of the original backlog to work on, which would allow us to experiment and learn much faster, while making sure that the most important objectives were targeted.

Instead of building everything that the backlog dictated, we focused on the user stories that would help us validate our assumptions, thus adding more value in the shortest time. The time left in the project could be used to revisit (or even create completely new) stories that then we knew were worth playing, as we drove development based on goals. 

If you happen to be in the same situation, why don't you give these simple steps a try? They helped us a lot and we're pretty sure changing your backlog to a goal-oriented one will bring you great results!