Have you ever been confused about the best way to write a product backlog item? Have you found that stories may not always be enough, and just grouping stories into epics does not really help the flow? You’re not alone! Many agilists find it challenging to know how to structure backlogs in a way that will help their teams succeed. In this write-up, I will show the necessity for having different levels of any backlog, discuss the different ways to write those product backlog items, and explain how each can be used to improve your team’s productivity. So don’t wait any longer — let’s get started!

The Product Backlog Basics

The product backlog is “… an emergent, ordered list of what is needed to improve the product. It is the single source of work …” according to the Scrum Guide (1).

The backlog should be ordered mainly from prioritization based on business value and other factors and from sequencing due to technical or commercial reasons. So how should we describe the changes that are needed? What Scrum calls Product Backlog Items, PBI, what is that?

Product Backlog Items and Stories

Many teams use stories, or user stories, originating from Extreme Programming, XP (2). And this is a good approach. But being agile means we need to know more details about what we are doing in the near future and less about what is further down in the backlog. Stories are typically refined just in time for a future iteration or sprint, so we do not know very much of the future if we solely use stories. How can we learn more about the future? How can we make a forecast with relatively high predictability? When is this customer feature that needs several stories possible to deliver? What will be delivered in the coming quarter or half a year?

The solution is not to revert to a waterfall approach with strict deadlines and pre-studies of requirements. The answer is to work with backlogs on different levels and use forecasts for these backlogs. Because stakeholders tend to prefer predictability. Stakeholders tend to prefer visibility and transparency. It is not enough to say, "it is on place 45 in our backlog"; it is better to say, "In our forecast, for what we know today, that customer feature can be released in the second quarter.”

Epics as a bunch of stories

Many teams use epics as a grouping. Epics are often just a bunch of stories related in some way. But nothing strict. We know nothing more of an epic created this way than of the individual stories. And since the stories are created and refined just in time for a Sprint, we actually do not know anything about the future.

Three levels of backlog – the proposal

This is where the three levels of any product backlog come in. Three levels that are close to mandatory when you need to work with more than one team with the same product. Three levels that can be very beneficial if you are only one single team. To focus the team. To manage your stakeholders. To achieve flow. To achieve predictability. To be able to forecast. To be transparent.

So, let's start with the most significant things in the backlog, what I like to call Initiatives. These are called epics in Dean Leffingwell’s book Agile Requirement (3) and obviously also in Scaled Agile Framework (SAFe®) (4); however, that word is confusing since so many teams already use that word for grouping a bunch of stories. Initiatives are definitely not just a bunch of stories. Therefore, I am using the word initiatives in this write-up, however, do not focus on how to name things but instead focus on the concepts.

What are Initiatives?

Initiatives are high-level, strategic items. They typically emerge from a business opportunity or problem that the customers or users face. But Initiatives can also be internal, an internal need to change something to provide business or customer value later.

I do not recommend strict rules for how big an initiative should be. But we also want flow so they cannot be too big. A rule of thumb is three to nine months of lead time. Any bigger than that, and you should consider a split.

As these initiatives are pretty significant investments, they will need a lean business case so that we can make a knowledgeable decision about the investment in this initiative. The business case must be thin and lean, not a pre-study taking a lot of resources, just enough so that we can make an informed decision to start the initiative.

Hypothesis And Business Outcome

For an Initiative, we also need to state a hypothesis. Design Thinking, an excellent method, helps us define the problem and select a solution, but this solution needs to be viewed as a hypothesis. If a solution does not reach the business goals or does not solve the customer's problem, we need to rethink it. We need to be able to pivot and create another solution. And do this based on facts we can measure in the best of worlds. Thus, pivot without mercy or guilt.

The business outcome should be defined. What is it we want to achieve in the end? Is it more customers and more revenue? Or higher quality? We need to define these lagging indicators.

Furthermore, we need to define some leading indicators that help us understand if we are on the right track with this initiative. Since the lagging indicators can take years to measure, we need to get feedback faster. An example of a leading indicator could be the number of customers downloading the new version of our software or some positive rating in reviews.

Initiatives Are Not Projects

Some organizations fall into the trap of transferring current projects into initiatives. Even if that is, of course, doable and an approach I sometimes have used, there are some distinct differences that we need to understand and account for.

Projects have a temporary organization, a distinct goal, a budget, and often several different phases in a waterfall manner. An Initiative is assigned to one or several teams that is a permanent organization. We are moving work to the people instead of moving people to the work. The Initiative has no distinct goal but has the leading and lagging indicators I mentioned above. And it is executed in a very iterative way where we try to deliver value as early as possible to get feedback and learnings from our customers and users, measuring our leading indicators.

Keep Initiatives Small

You want flow - even for initiatives. The key is to keep the batch sizes, the size of the initiatives, as small as possible. And to keep the Work in Progress (WIP) low, to minimize the number of concurrent initiatives. And, of course, remove waste and reduce handovers and queues. Stop starting and start finalizing – this is a good food for thought to maximize the flow of value. And finally, minimize the gold-plating of the initiatives! Deliver just what is enough to prove the hypothesis or solve the need. You can always define a second initiative targeting those extra features when the first one is ready. A common mistake is building the best possible solution – when we should think about building the minimal viable solution, which of course needs to be feasible to build, viable from an economic perspective, and desirable from the customer perspective.

We break down Initiatives into features that deliver the value to the customers and users.

What are Features?

Think about a smartwatch. It has several features. One obvious is "showing the time"; another could be "showing the current pulse.” The features are usually used to sell the product, so they are long-lived. Features describe the problem, not the solution, and absolutely not how the problem should be solved. They can be small or huge. But since we prefer smaller batch sizes, we try to keep them as small as possible. I recommend that they be finalized in "a couple of sprints.”

Danger Ahead

There is a trap in setting a time limit. SAFe (4), and Leffingwell (3) states that a feature must fit in one Program Increment – a period of about ten weeks. This causes massive confusion for many organizations trying to adopt SAFe.

Of course, delivering a feature in ten weeks is good, but if we cannot, we need to look into why. Often, the root cause is within our delivery capabilities, where we need to find the bottlenecks and start improving. The cycle time for any feature is longer than ten weeks. And that is an entirely different problem than merely the size of the features. We need to keep our batch sizes down, but if the problem lies in our delivery capability, maybe we just release our software or cyber-physical system once per year; it is no meaning to enforce minimizing the size of features. Instead, we should work with the release schedule. Suppose we enforce a maximum ten-week size of features when the problem lies within the capabilities to deliver in the organization. In that case, we will see the behavior when we start waterfalling our features. Strange “animals” like "Investigation features," "test features," "development part 1," and "delivery features" will be created to fool the system and be able to finalize within ten weeks. It looks very much like waterfall to me! And I am afraid I have seen this - more than once! Be very careful! Batch sizes are not equal to calendar time or cycle time!

Keep Batch Sizes Down

For sure, we need to keep the features' sizes down, batch sizes down, and increase flow. Instead of focusing on a lead-time limit, we should think about the minimum we can deliver, what I would like to call the Minimal Viable Feature. And then, we can add on or improve that feature at a later stage. That is why the initiative thinking is so good! What is the minimum we need to do now to prove or disprove the initiative's hypothesis? And we continue to ask ourselves that question until proven right or wrong.

Different Types Of Features

Features can be of different types. They can be business-facing, or they can be development-facing. A feature that is development-facing is often called an Enabler. In the case of "showing the pulse" above, an enabler could be to have the pulse measurement hardware in the watch. But still, we need to define the value of the feature. An enabler is not a carte blanche to do anything.

Some features change behavior or add on to existing features, features that are already in production. You can, of course, call this a Feature Enhancement or similar, but for me, it really does not matter what we call it, so I just call all of them Features. Remember that features are long-lived and how we describe them in a product document does not necessarily reflect how we have developed them.

What are stories?

We break down Features into Stories. A Story describes a business or technical problem that needs to be solved for us to deliver the feature.

Stories are a powerful way to communicate problems and solutions to others and within the team, and they can be especially useful when explaining complex software and cyber-physical systems. The stories focus on the value we give to an actor or persona in the system. Some organizations and frameworks call them user stories, but I find that way too narrow since it implies the actor is always being a user. The actor can, in my opinion, and experience, be anyone, the customer, the maintainer, different user categories of the system, another system, or even the team developing the system.

User Voice

An excellent way to describe a story is through something often called user’s voice.

Stories are usually small enough that you can describe them on a tiny piece of paper and be able to finalize them within a couple of days or maybe weeks.

Stories are short-lived. They cease to exist after they have been delivered. This is in sharp contrast to the features that we discussed above. The stories' most significant purpose is for the team to understand what value they should provide and be a container for that job.

Common Pitfalls Around Stories

• Stories are pieces of value, not activities. It is very easy to fall into the trap of describing the story from the activities we want to do. Instead, we should define the value we need, that the actor needs.

• Stories do not necessarily have to be delivered to the end-user or the customer. However, we should be able to get feedback. In a software world, the story might be completed when integrated and tested successfully in the complete system. Not necessarily when the story has been delivered in a release available to the users and customers. If we can get feedback from the users during a demo of working software - of course, that is the best.

• We do not release stories; we release features. Stories build-up features.

What about tasks?

Some teams do break down stories into tasks; some don't. It depends, and nothing is right or wrong here.

Tasks are the work and activities that need to be done to complete a story. Tasks can be of different types but are usually related to development, testing, or documentation.

A task should not take more than a day or two to complete. It is probably too big and should be split up into smaller tasks if it does. Tasks are short-lived, like stories, and they cease to exist after completion. Often tasks are performed by one person – while the team can hoard around a story to complete it. The most significant difference between a story and a task is that a task is an activity, while a story describes the value.

Do not fall into the trap of estimating your tasks. Tasks are there to help the team understand what needs to be done. Some tools want you to estimate tasks in hours, calculate the sum of remaining work in hours, and create a nice burn-down chart. Although nice to look at for a manager, this is precisely what we do not want in an agile team. Instead, use burn-up charts for your stories, measure velocity (number of stories or story points per sprint), and keep it simple.

Conclusion

All teams developing products need a good backlog. It doesn't matter if you have a one-team setup using Scrum or Kanban, if you have twenty-five teams working together using SAFe, or if you have Tribes, Guilds, and Chapters in your own flavor of the Spotify Model - you need to have a transparent strategy for your backlog, understood by everyone and visible to everyone. Above I have outlined one strategy. Use it, change it, improve it and adapt it to your needs. What is the first improvement you want to make?

References

1. Sutherland, Jeff and Schwaber, Ken. The 2020 Scrum Guide. https://scrumguides.org/index.html. 2020.

2. Beck, Kent. Extreme Programming Explained: Embrace Change. 1999.

3. Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. 2010.

4. Scaled Agile Framework. Scaled Agile Inc. https://www.scaledagileframework.com/.

This article was originally published at Medium Sep 2022.

Last updated Sep 18, 2024