Listen to the audio version of this article:

1. Choose a Product Goal

A product goal describes a specific and measurable outcome a product should create during the next two to three months.[1] Sample goals are acquiring users, increasing conversion, generating revenue, or future-proofing the product by reducing technical debt.

Product goals offer the following four benefits: They describe the specific value a product will create in the coming months; they align stakeholders and development team; they focus the product backlog thereby making it easier to manage and update it, and they provide the context for choosing the right sprint goals, as I discuss in more detail in my article Product Goals in Scrum.

If you follow my product management approach and use a goal-oriented roadmap like my GO product roadmap, then you can simply choose the next goal on the plan as your product goal. If that’s not the case, then determine the outcome the product should achieve in the next few months, preferably together with the key stakeholders and development team members.

Ask yourself why it is worthwhile to progress the product and spend time, money, and energy on it. What is the specific problem you want to address or the particular benefit you want to achieve in the next few months? If you have a validated product strategy in place, you can use its value proposition and business goals to find the right product goal. Alternatively, use your key performance indicators (KPIs) to identify improvement opportunities. Then choose the most important one as the product goal, as I describe in more detail in my book Strategize.

2. Clear out the Product Backlog

Next add the product goal to the product backlog. Then remove all items that are not required to meet the goal. Delete or archive them. This might result in an empty product backlog that contains only the product goal. But that’s OK.

While this advice may sound drastic, it ensures that your product backlog is focused and concise. I have come across many huge product backlogs in my work, some of which contained several thousand items. All these backlogs had a common issue: They were not focused, and it was not clear, which specific value the backlog should help create.

Focussing your product backlog on a single goal makes it comparatively easy to prioritise and update. This is especially important for products that experience a significant amount of uncertainty, risk, and change—like new and young offerings—as their backlogs tend to be volatile and frequently change, as I explain in more detail in the article How Detailed should the Product Backlog be?

3. Determine the Items Necessary to Meet the Product Goal

After clearing out the product backlog, consider which product capabilities have to be created or enhanced to achieve the product goal. Say that your goal is to increase conversion by 5-10% over the next three months. Then ask yourself how you will achieve this outcome. How will the product have to change to meet the goal?

If you work with my GO product roadmap, then start by copying the features that are associated with the goal into the backlog. Additionally, answer the following four questions to discover the right backlog items:

• Does the user experience have to be adapted?
• Do you have to add or change any functionality?
• Do you have to meet new or enhanced non-functional requirements including compliance standards?
• Are bug fixes and architecture refactoring work required to address the product goal?

Keep the backlog items you’ve identified coarse-grained and sketchy, at least for now. For example, use epics to capture them but not detailed user stories. What’s more, the product backlog does not have to be complete at this stage, and I would argue that it should not be at this point in time. Remember that the backlog will evolve based on the feedback and data you gather by demoing and releasing early product increments to users and stakeholders. You’ll add new items, and you’ll remove or change existing ones.

4. Get the Product Backlog Ready

Once you’ve captured the work required to meet the product goal, prioritise the backlog. I recommend using risk as the main prioritisation factor at this stage. This will allow you to quickly address assumptions, and rapidly acquire the relevant knowledge. Risks may be related to the users, technology, business model, and compliance requirements. Here are four sample risks: First, users might not be willing to register before using the app. Second, the machine learning framework might not scale. Third, the price you want to charge might be too high. Fourth, a standard like GDPR, SOX, or HIPPA might not be fully met.

After prioritising the backlog, refine the high-priority items so that they are ready to start the development effort. The items should be clear, feasible, and testable. This involves breaking out smaller items from the larger ones, for example, deriving user stories from epics and adding acceptance criteria to the stories. You should now have a prioritised backlog with just-enough high-priority detailed items that can be worked on in the upcoming sprint.

When carrying out the work above, avoid two common mistakes. First, do not derive too many detailed items. Only create as many as the development team is likely to consume in the next sprint. This will result in an appropriately detailed and concise backlog that can be easily changed as you learn more about how to best address the user needs. Second, ensure that there are enough ready high-priority items to drive the work of the team in the upcoming sprint. Otherwise, it will be difficult, if not impossible, for the team to make a realistic forecast or commitment.

5. Make Stocking the Product Backlog a Team Effort

When you stock the product backlog, don’t do the work on your own as the person in charge of the product. Instead, involve the key stakeholders and development team members in setting the product goal. Additionally, ask the development team to help you discover, prioritise, and refine the backlog items—preferably in the form of a collaborative workshop. This approach offers you the following three benefits:

1. You’ll leverage the collective knowledge of the group. This maximises the chances of choosing the right product goal and identifying the right product backlog items.
2. You’ll create clarity. Stakeholders and team members have a clear and shared understanding of the goal. Additionally, the development team understands the product backlog items, despite them being sketchy and coarse grained, as the members have helped identify and capture them.
3. You’ll secure strong buy-in. Inviting people to help set the product goal and determine the right backlog items increases the chances that the individuals are aligned, support the goal, and together move towards it.

If you follow my advice and employ a collaborative workshop, ask the Scrum Master to run it. This frees you from having to facilitate the session, and it allows you to actively shape the product goal and product backlog. At the same time, it ensures that everybody is heard, and nobody dominates. For more advice, please see my article Making Effective Product Decisions: Tips for Deciding with Stakeholders and Dev Teams.

[1] The product goal also features in the Scrum Guide released in November 2020. It states that “the product goal describes a future state of the product … [It] is the long-term objective for the Scrum team.” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal.”

The Product Backlog is Too Big

A few years ago, I was asked to help a healthcare company with their agile transition and its impact on product management. One of the challenges the agile transition team was concerned about was the choice of the right product backlog tool, which at first seemed odd to me. But when I was told that the backlog in question had over 40,000 items, I could see that there was an issue.

Admittedly, that’s by far the largest product backlog I have come across to date. But I find it not uncommon to encounter backlogs that range from several hundred to a few thousand items. But such a product backlog is difficult to comprehend, let alone prioritise and update. This is problematic especially for young products and those that experience a bigger change, like a life cycle extension, as their backlogs tend to be volatile and require frequent and sometimes bigger adjustments.

You should therefore strive to keep your product backlog as concise as possible whenever your product faces uncertainty and change—be it market, business, or technology related. The following three techniques will help you with this: First, group related items into themes. Second, keep lower-priority items coarse grained. Third and most importantly, focus the backlog on a specific product goal. Then decline and remove items that do not serve this goal, as I discuss below.

The Product Backlog is Too Detailed

Another time, I was asked to help a team of a major charity in the UK whose task was to create a new website for their fund-raising campaigns. The product owner told me that she’d refined the product backlog as well as she could but that the development team were still not happy with it. Looking at the backlog, I noticed that it contained only detailed user stories—no epics or other coarse-grained items.

But an overly detailed product backlog makes it hard to see the wood for the trees: There is simply too much information. This, in turn, makes it difficult to prioritise and update the artefact. What’s more, it is likely to contain speculative and ultimately wrong items, especially when the development effort is characterised by uncertainty and change.

I therefore recommend that you start with an initial product backlog that is intentionally sketchy and incomplete, especially when your product is young or experiences a bigger change. Then let the backlog evolve based on the feedback received from users, customers, and stakeholders. This allows you to minimise the effort to stock the product backlog and to base your product decisions on empirical evidence, rather than gut-feeling.

The Product Backlog is Not Appropriately Refined

A while back, I was working with a company that connects consumers in the UK with a tradesperson like a plumber or gardener. Back then, the company was still a startup, and the product owner had asked me to help them address a planning issue: The development team routinely overcommitted and never managed complete all the work in a sprint.

When I was shown around the office, I saw some paper cards on the wall with big, sketchy epics on them, and I asked the product owner if these were part of the product backlog. The individual replied, “No, this is the product backlog.” Given that the backlog did not contain any sufficiently refined, ready items I was no longer surprised that the development team struggled to get sprint planning right.

While you don’t want to make your product backlog any more detailed than necessary, you should ensure that its high-priority items are ready. This requires them to fulfil the following three criteria: First, they are sufficiently clear and understood by the development team. Second, they can be completed in a sprint according to the Definition of Done. Third, they can be tested. Getting the high-priority items ready is best done together with (some of) the development team members, as I discuss below.

The Product Backlog is a Wish List

Some product backlogs—like the one with 40,000 items mentioned above—resemble a wish list, a catalogue that contains anything and everything that you might ever need. The trouble with such a backlog is not only that it is usually too big. It also results in a “feature soup,” a product that resembles a loose collection of unrelated features. This leads to a weak value proposition and a poor user experience, which are hardly hallmarks of a great product.

But if these backlogs are so bad, why do they exist? There are two main reasons: First, a lack of strategic alignment and focus, and second, a lack of empowerment. The former means that there is no product goal that guides the decision if an item should be added to the product backlog or not. You might, for example, brainstorm user stories and decide to add all of them. Who knows, they might come in handy at some point in time!

A lack of empowerment causes you, the product owner, to have a hard time declining stakeholders requests and to feel obliged to accommodate them. But if you are not able to say no, your product backlog is in danger of serving individual stakeholders and their personal goals—rather than maximise the value the product creates for the users and the business.

To prevent your product backlog from becoming a wish list, follow these two tips: First, select a product goal and align your product with a strategic plan like a product roadmap (as I discuss below). Second, have the courage to say no. Decline any ideas and requests that are not aligned with the product goal. (See my article Boost Your Product Leadership Power for advice on increasing your authority.)

The Product Backlog is Not Effectively Prioritised

Some time ago, I was working with the product manager of a new healthcare product when I suggested to prioritise its features. The individual looked at me surprised and replied, “I can’t. They are all high-priority.” Prioritisation, of course, requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction.

If you struggle to prioritise your product backlog, try the following two measures: First, ensure that the product backlog items serve a specific product goal, as mentioned before. Second, select a small set of practical prioritisation factors. The three factors I like to recommend are risk, cost-benefit, and dependencies.

Here is how you can apply them: Initially prioritise the product backlog by risk and consider user, technology, and business-related risks. Assess all backlog items together with the development team and move those to the top that carry the highest risk. This approach accelerates learning, and it avoids failing late when changing course is more costly. Once you’ve addressed the key risks, order the product backlog by cost-benefit, and move those items to the top that give you the biggest bang for the buck, as the saying goes. Finally, don’t forget to consider dependencies whilst using the other two factors. These include dependencies on individual team members and on other teams, as these can influence the backlog prioritisation.

The Product Backlog is Not Shared

A few years ago, I was working with a group of product owners based in the Netherlands who wanted their development teams to get better at delivering what they asked for. It turned out that the product owners refined the product backlogs and wrote user stories on their own and then handed off the high-priority items to the dev teams who were based in Romania. The teams did their best to correctly interpret the user stories. But more often than not, they got it wrong, as they had little knowledge about the end users and their needs.

While a lack of collaboration in the situation described might be obvious to an outsider, I find it not uncommon that development teams aren’t properly involved in the product backlog work. But refining, prioritising, and updating the backlog should be teamwork, as shown in the picture below. As the product owner, invite the development team members to work with you on the backlog, and expect that they will support you. If that’s not the case, then discuss the issue in the next sprint retrospective.

Collaboratively working on the product backlog and co-creating its items offers the following two benefits: First, it leverages the collective knowledge and creativity of the development team, which usually leads to better backlog items—items that are just as detailed as they have to be. At the same time, it allows you as the person in charge of the product to transfer knowledge about the users and their needs to the dev team.

Second, it makes the team members feel valued and respected. It empowers the individuals and increases their motivation to work on the product. People are no longer handed requirements to be worked on. They now contribute to the product decisions and help shape the solution.

If you don’t regularly work on the product backlog together with at least some of the dev team members, then give it a go. Set up a collaborative workshop, be it onsite or online, and ask your Scrum Master to facilitate. Initially, this might require you to spend more time working on the product backlog. But in the longer run, it should reduce your workload. It might even result in the development team being happy to do some of the refinement work on their own.

The Product Backlog Lacks Strategic Alignment

A common product backlog mistake and a root cause of several mistakes discussed above is a lack of strategic alignment: The backlog is not systematically connected to a strategic plan like a product roadmap. But without strategic guidance and a clear product goal that governs it, the backlog can easily grow too be, become hard to prioritise, and turn into a wish list. This was also the case for the huge product backlog I mentioned earlier: The strategic objective of the product was unclear, and this made it hard to determine which items should be added to the backlog.

I therefore strongly recommend that you connect your product backlog to an actionable product roadmap that states the value the product should create in form of product goals for the next nine to twelve months, as the picture below illustrates. Sample product goals might be acquiring users, increasing conversation, removing technical debt to future-proof the product, and reducing cost.

In the picture above, a goal-oriented, outcome-based product roadmap directs the product backlog. This is done by copying the next product goal from the roadmap into the backlog. The goal then helps determine the items that should be included in the product backlog, that is, only those that help meet it. (You can find out more how to the product roadmap and backlog can complement each other in my article The Product Roadmap and the Product Backlog.)

Listen to this article:

Product Goals Defined

The Scrum Guide released in November 2020 states that “the product goal describes a future state of the product … [It] is the long-term objective for the Scrum team.” It also suggests that “the product goal is in the product backlog. The rest of the product backlog emerges to define ‘what’ will fulfill the product goal.” The product owner is accountable for “developing and explicitly communicating the product goal.” The entire Scrum team is “focused on one … product goal” at a time.

If this definition leaves you scratching your head, don’t worry. Scrum is a simple framework designed to facilitate the development of complex products. It does not intend to prescribe how the practices it offers should be applied. As a consequence, different people have suggested different ways to apply the product goal. Some view it as the product vision, others equate it to the product’s value proposition.

I find, however, that a product goal is best used to describe a specific and measurable benefit or outcome a product should create in the course of the next two to six months. A sample goal might be to acquire users, increase conversion, generate revenue, or reduce technical debt. Such a goal aligns the stakeholders and development teams, and it directs their work.

What’s more, I like to ensure that product goals are connected to the product strategy and its user and business goals. This helps me choose the right product goals and it ensures that meeting a product goal is a step towards creating the desired value for the users and the business, as figure 1 shows.

In figure 1, the vision is the basis for choosing the user and business goals, and the latter create the context for determining the right product goal. At the same token, each product goal acts as the foundation for identifying helpful sprint goals. In other words, the goals are connected and form a cascading set of product-related goals.

Please see my article “Leading Through Shared Goals” and my book How to Lead in Product Management for more information how to effectively use the goals in figure 1, which includes securing the necessary buy-in from the stakeholders and development teams.

Background Story: Readers familiar with the history of Scrum—sometimes lovingly referred to as Scrumtorians—will undoubtedly know that it has contained sprint goals at least since 2002 and a (product) vision since 2004, even though the latter is not mentioned in the Scrum Guide. When I started to work with Scrum in 2004, I could not get my head around the question of how to systematically connect a big, inspiring vision to a tactical, short-term sprint goal. It took me years to come up with the set of goals in figure 1. In hindsight, the set looks disappointingly simple 😉

You can also access the contents of this article on my YouTube Channel:

Sample Goals

To better understand how the goals in figure 1 can be applied, let’s take a look at an example.

In figure 2, I first captured the vision “Help people eat healthily” and then used it to choose the user and business goals “Reduce the risk of developing type-two diabetes; create new revenue source.” In order to determine the right product goal, I asked myself, “What would be a first good step to meet the from the user and business goal?” I consequently chose the product goal “Help the users understand their eating habits and acquire an initial user base.” I then used this goal to determine the right sprint goal. I figured that finding out if users are willing to share personal information when activating the app would be the most important risk to address and hence should be the goal of the first sprint.

Note that I chose to use a compound product goal in figure 2 that has a user part—help the users understand their eating habits and business—and a business one—acquire an initial user base. Both parts are closely connected: In order to acquire a user base, the product must offer tangible value to the users, and a first step to help people eat more healthily is to help them become aware of their current eating habits. You don’t have to work with compound product goals of course, if you prefer to focus your objectives on either the user or the business benefits.

Product Goals and the Product Roadmap

Setting a single product goal is great. But unless you can’t see further than the next few months, I recommend determining the next three to four product goals and capturing them on your product roadmap, as figure 3 below shows.

Figure 3 shows a sample roadmap based on my GO product roadmap template, which contains three product goals. Each goal builds on the previous one thereby nicely progressing the product: The first goal helps the users become aware of their eating habits and creates and initial user base. The second one helps people improve their eating habits and acquires additional users. The third product goal, finally, helps the users improve their overall fitness and generates revenue.

While the Scrum Guide does not mention identifying future product goals and adding them to the product roadmap, I find this practice very helpful: Stakeholders and dev teams usually benefit from understanding how to product is likely to evolve beyond the next two to three months. This helps the individuals create an effective sales and marketing strategy, for example, and to make the right architecture and technology decisions.

Product Goals and the Product Backlog

With a product roadmap in place, I like to select the product goal to be worked on and copy it from the roadmap to the product backlog together with any coarse-grained features that are associated with the goal. This approach is illustrated by figure 4.

The beauty of using a product goal in the backlog is that it focuses the latter, as I describe in my article “The Product Roadmap and the Product Backlog.” This addresses a common issue: Many product backlogs I have seen over the years were too big and too detailed. This made them hard to prioritise and difficult to update, which is bad news as long as your product is young or experiences more than small, incremental changes. In most cases, the product backlogs grew so big because they lacked a measure to decide which items should be added to the backlog and which should not. The product goal is this measure: Only add an item to the product backlog if it helps meet the product goal.

Let’s briefly explore how a product goal might be used on the product backlog. Say I was to start the development of my healthy eating product, I would copy the product goal “Help the users understand their eating habits and acquire an initial user base” into the product backlog together with the features “healthy eating dashboard” and “integration with smart watches and fitness devices.” I’d ask myself which additional features are required to meet the product goal and add these to the backlog. I would the start breaking some of the features into epics and prioritise the product backlog. Finally, I’d refine the high-priority items to be ready to start the first sprint.

As you can tell, I like product goals and find them very helpful, and I would encourage you to try them out if you haven’t used them.

Listen to this article:

Step 1: Ensure that you know who the product is for and why people will want to use it

I’ll never forget the day when I suggested to the product manager of a brand-new healthcare product to prioritise its features. The individual looked at me slightly bewildered and replied, “I can’t. They are all high-priority.”

Prioritisation requires deciding how important an item is. If everything is high priority, everything is equally important. This means in effect that nothing is a priority. But without clear priorities, the development team lacks direction, and there is only a slim chance of creating a successful product.

A common root cause of not being able to prioritise a product backlog is a lack of understanding of who the users of the product are and what specific value it should create for them. I find it not uncommon that features are added to the product backlog because a senior stakeholder demands it (HIPPO syndrome) or someone thinks it is a good idea (“let’s brainstorm some user stories”). But a product exists to generate value for the users and for the company providing it. If it is not clear who the users are and why they would want to interact with the product, it will be hard to decide which items should be in the product backlog and how important they are.

To mitigate the risk of adding the wrong items to the product backlog, ensure that you have a validated product strategy in place, no matter if you look after a brand-new or as an existing product. Such a strategy should clearly state the following:

• The users and customers of the product so that it is clear who will benefit from it and who won’t;
• The main problem the product should address or the primary benefit it should offer, or the main goal users will want to achieve with it;
• The three to five features that will make it stand out from the crowd;
• The specific benefits it should create for the business.

Let’s look at a brief example and say that I want to create a product that helps people eat healthily. Then I could choose to address middle aged men who suffer from unhealthy eating habits and who don’t exercise enough. The benefit might be to reduce the risk of developing type-2 diabetes. The standout features might be to measure food sugar levels, analyse the user’s eating habits, and integrate with leading smart scales. The business goals, finally, might be to diversify my company and open up a new revenue stream.

Additionally, you should be confident that your strategy is correct, and you should have data to support your view. In other words, you should have addressed the key assumptions and risks in the product strategy, and you should have carried out the necessary validation work. A tool like my product vision board helps you capture and validate your product strategy.

Step 2: Describe the outcome or benefit the product should create in the next few months

Having a product strategy in place is great, but it is not enough to effectively prioritise a product backlog. What’s required is a specific product goal that is connected to the strategy and creates the right context to decide which backlog items are more important and which ones are less.

To create such a goal, ask yourself which outcome or benefit your product should achieve in the next, say, three to six months. What are the desired user and business benefits you want to create? Make sure that this goal is in line with the product strategy and that it helps create the desired user and business benefits. An example based on the sample strategy above would be “help the users understand their eating habits and acquire an initial user base.” (Note that I have chosen a compound goal that captures the desired user and business benefits.)

I like to take this idea further, derive several product goals from the product strategy for the next 12 months, and capture them on a product roadmap. This puts the goal chosen in context and communicates how the product is likely to evolve over a longer period. If you have a product roadmap, then ensure that it implements the overall product strategy. Consider reworking it so that it clearly states the desired outcomes your product should achieve.

Step 3: Remove all items from the product backlog that do not support the desired outcome

Next, use the product goal you have chosen to delete all items from the product backlog that do not serve it. While this approach might sound radical, it ensures that your backlog becomes concise and focused. It avoids having items on the backlog that are speculative and may not create value, and maybe even more importantly, it facilitates prioritisation.

If you believe that removing the product backlog items is going to be very difficult, if not impossible, then this may indicate that you lack the necessary empowerment and/or that the stakeholders do not buy into the overall product strategy and the specific product goal you have chosen. Involving the individuals in the decision-making process can help address both issues. This allows the stakeholders to voice their ideas and concerns, and it makes it more likely that they understand and support important product decisions.

If you plan to decide together with the stakeholders, then invite them to a meeting. Carefully prepare the session and choose a decision rule, for instance, consent. Additionally, ask your Scrum Master or another skilled facilitator to help run the meeting so that everyone is heard, and nobody dominates. (I offer more advice on securing stakeholder buy-in and decision-making in my book How to Lead in Product Management.)

Step 4: Prioritise the remaining product backlog items

Now prioritise the remaining product backlog items. I recommend that you prioritise a new or significantly changed product backlog initially by risk, taking into account the user, technology, and business-related risks. Assess all backlog items together with the development team and move those to the top that carry the highest risk. This approach accelerates learning and it avoids failing late when there are less options to change course.

Finally, ensure that the high-priority items are “ready“, that the development team and you have a shared understanding of them, that the team can implement them in the next sprint, and that they are testable.

The Moral of the Story

You might be wondering what was up with the healthcare product I mentioned earlier. The prioritisation difficulties were indeed rooted in the lack of a clear and agreed product strategy and the absence of a clear, focused goal for the initial version. Consequently, the offering launched was more like a maximum viable product than a minimum one. Unsurprisingly, it pretty much bombed, which resulted in the company losing significant market share and people leaving the enterprise.

As this story shows, it is crucial to have an overall product strategy in place before you decide which functionality your product should offer and in which order it should be implemented. In other words, make sure that you create an effective product strategy first before you worry about the product details and that you systematically connect the product backlog to the strategy.

Split the Product Backlog

Faced with an overly long and detailed product backlog, investigate if it does describe one cohesive product. Over time, products can serve an increasingly heterogeneous market and provide a large number of different features, some of which may not be used by all users.

If that’s the case for your product, then you can unbundle one or more features and release them as products in their own right, like Facebook did with Messenger in 2014. The company unbundled the messaging functionality originally included in its Facebook mobile app and made it available as a stand-alone product.

Move the unbundled features to a separate backlog for the new product, and enjoy working with the original product backlog, which is now smaller.

Limit the Product Backlog Scope

Your second option is to limit the scope of your backlog. To do so, choose a clear, specific, and measurable product goal for the next two to six months, for example, acquire x number of new users or increase engagement by y%. Then use the goal to direct and focus your product backlog: Remove all backlog items that do not help meet this goal.

While this approach may sound radical, it ensures that your product backlog is concise and focused. It avoids looking too far into the future, having speculative items on the backlog, and turning the product backlog into a wish list.

To capture additional ideas of how to progress your product, use a goal-oriented or outcome-based product roadmap and focus the product backlog on the next goal or outcome on the roadmap. This way, the product roadmap complements the product backlog: The former is a longer term, strategic plan; the latter contains the product details and facilitates execution.

Hide the Details

Your third option is to structure the product backlog in order to make it more manageable thereby hiding detailed items. A simple way to do this is to group epics into themes, which represent coarse-grained features or user journey steps like registration or search and navigation.

This allows you to work with the following structure: theme → epic → user story. While such a product backlog contains the same number of items, you can now access its contents more easily by using themes and epics to navigate to the corresponding user stories.

Aggregate the Details

Another option to reduce the product backlog size is to combine detailed items. This is achieved by replacing lower-priority, fine-grained items with a coarse-grained one, for example, substituting a number of user stories with a newly created epic. This can be particularly helpful when you inherit an overly long and detailed product backlog.

In addition to reducing the product backlog size, aggregating the details creates an appropriately detailed product backlog. Such as backlog is easier to update and change, which is particularly helpful for young products and those experiencing a major change like a life cycle extension.

Eliminate Zombie Items

Most of us have probably done it: Adding items to the product backlog to please an important stakeholder even though we knew that we would not be able to implement them any time soon. Over time, they’ve turned into zombie items at the bottom of the product backlog, which aren’t dead or alive.

If you’ve followed my earlier advice, you will have already removed those items. But if that’s not the case, then either make them high priority or delete them now. Your product backlog should only contain items that help create value for the users or business—not to appease individuals.

In the future, make sure to decline items that are not helpful to execute the product strategy and meet specific product goals. Attentively listen to and empathise with a stakeholder who requests a feature. But be not afraid to say no once you’ve understood the person’s underlying needs and interests.

Users

As its name suggests, a user story describes how a user or customer uses the product–a digital product is captured from the perspective of the users. This avoids a solution-centric view where we worry more about how to provide and implement the product features than why and how people will use them.

Understanding who the users are and how the product will benefit them is central to discovering and creating the right stories. In other words, if you do not know who your users are and what problem they want to see addressed or which benefit they would like to experience, then you should not create stories! Otherwise, you are in danger of speculating about the product features rather than deriving them from the user needs.

I’d like to take this further and suggest that you should meet the users. This is not to say that the users will be able to correctly tell you what the product should do—it’s your job to figure this out. I know that product managers and product owners don’t always have access to the users and are sometimes shielded from them by the sales team or management. I also understand that development team members tend to see users even less frequently. But if you want to leverage user stories to develop a successful product, then you should do try to observe and talk to the people who will use it. How else can you truly understand their needs and empathise with them?

Conversation

When I first came across user stories over 15 years ago, I was surprised by their lack of detail. I was used to working with use cases, and it took me a while to get my head around their sketchiness. They seemed less like requirements and more like notes. And that’s exactly what stories are meant to be—notes that capture the essence of a conversation.

On its own, a user story is pretty useless. It needs to be complemented with a conversation between the person in charge of the product, the product manager or product owner, and a cross-functional development team.

Maybe it’s helpful to take a quick look at the context in which user stories emerged. Stories were first used in Extreme Programming in combination with the role of an onsite customer. The onsite customer is a member of the user community who is collocated with the development team. The individual would discuss with the team what should be built in the next iteration, and captured the conversation as stories to remind everyone of what was discussed.

Agile approaches happily accept tacit knowledge, knowledge that is not explicitly expressed and written down, and they prefer face-to-face conversation over documentation. Why? To speed things up, to allow the team to quickly implement some functionality and to validate it by exposing it to the users.

I find it even better to co-create user stories by inviting the development team members to help discover new stories and amendments to existing ones—based on the feedback and data gathered from the users. This leverages the team’s collective knowledge and creativity and tends to result in better, clearer stories. To do so, make collaborative story work part of your product backlog grooming or refinement process.

But if you cannot have at least a meaningful conversation, if product owner and team cannot discuss new stories together so that the team understands the stories and can make suggestions for improving or splitting them, then you should not use user stories. The conversation is not optional; it is an essential part of user stories. Without it, the story is not usable or it becomes bloated with details. If you find that you need to capture more details or hand-off requirements, then use a different approach like use cases instead.

Use cases tend to be more effort to create and update but they offer more structure. They come with pre- and post-conditions, triggers, a main success scenario, alternative success scenarios, and exception scenarios. This allows you to describe the product functionality in more detail, which may be necessary when working with remote teams.

Simplicity

User stories are a very simple tool—we simply tell stories about how users are likely to interact with the product and capture their essence. That’s it. Unfortunately, I have seen a fair amount of stories that were far from simple and straightforward.

I find it helpful to remember that in the early days of agile, people didn’t talk so much about user stories. Instead, they used the term story cards. The reason for this is simple: stories were captured on paper cards. These have two advantages: they facilitate collaboration and visualisation. Everybody can write on a piece of paper, and the cards can be easily arranged on the table or office wall. Electronic tools are less conducive to teamwork in my experience; one person is usually in control of the keyboard and tool. What’s more, it’s much harder to display the stories and prevent them from being hidden away. I would therefore encourage you to experiment with paper cards to capture your stories—at least when you create new stories. You can key them into your favourite electronic tool afterwards if you wish. But be warned: I’ve seen teams who decided after some experimentation to switch from electronic to paper-based stories.

Another area that can benefit from simplification are the acceptance criteria. As their name says, the criteria want to communicate what needs to be in place so that the story can be considered as done and the corresponding functionality can be exposed to a user or customer. Acceptance criteria should be no big deal but follow naturally from the narrative by asking, “how can we tell the story is done?” If you make the criteria more complicated, the stories become harder to understand and start to slow you down.

Limits

User stories are great at capturing product functionality, things people can do with a digital product like searching, evaluating, and purchasing products online. You can also use stories to capture non-functional aspects of a product, such as performance, robustness, and interoperability.

But when it comes to the user interface and user interaction, user stories are less suitable. Sketches and mock-ups are better at describing the UI design. And scenarios, workflow diagrams, storyboards, and story maps are better suited to capture user interactions that comprise several steps.

Additionally, writing user stories is worthwhile when you develop software that’s likely to be reused. But if you want to quickly create a throwaway prototype or mock-up to validate an idea, then writing stories may not be necessary. Remember: User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible—not to impose any overhead.

User stories should therefore be one of the tools in your product tool box, not the only one.

Option 1: In the Sprint Review Meeting

Your first option is to work on the product backlog in the sprint review meeting. Assuming that the development has developed a “done” product increment and the right people are present, you can use the attendee’s feedback to make the relevant product decisions and update the product backlog, as the Scrum Guide suggests and the following picture shows.

This approach ensures that the backlog is updated before the next sprint starts. This allows you to immediately action any new insights thereby mitigating the risk of taking the product in the wrong direction. Additionally, the backlog is collaboratively worked on. This creates strong buy-in from the people participating in the sprint review meeting.

But it only works if the attendees are able to provide relevant feedback, are willing to collaborate and can quickly agree on the necessary backlog changes. What’s more, the feedback must not require further analysis or give rise to bigger product backlog changes. Don’t use this option if a significant amount of uncertainty and change is present in your product backlog, for example, if you work on a new product or extend your product’s life cycle.

Option 2: In a Separate Workshop Prior to Sprint Planning

Your second option is to have a separate product backlog workshop prior to the next sprint planning meeting. The workshop should include you as the Scrum product owner, the development team, and the Scrum Master. Collaboratively analysing the data and working on the backlog, mitigates the risk of drawing the wrong conclusions due to cognitive biases like confirmation bias; it leverages the creativity and knowledge of the team, increases understanding and buy-in, and leads to better requirements.

As the picture above illustrates, my preference is to hold the workshop right at the beginning of the next sprint. This violates the Scrum rule that the sprint planning meeting must be the first event in every sprint. But it allows you to respond to the feedback in the subsequent sprint without rushing or dropping the sprint retrospective or working late or at the weekend.

What’s more, it provides the benefit of separating the data collection from the analysis: It enables you to review the feedback without the people present who provided it. It also give you more time to assess the feedback, derive the right insights, make the right product decisions, and change the product backlog accordingly. This makes it easier to deal with difficult feedback and requests, and to carry out bigger product backlog changes.

Note that this approach still assumes that you can collect the relevant feedback in the sprint review meeting, for instance, by carrying out a product demo, usability test, or solution interview. If you decide to release the product increment to (selected) users, then this option is unlikely to be appropriate for you, as it often takes several days to collect the relevant data in my experience.

Option 3: In a Separate Workshop After Sprint Planning

If you validate your product decisions by releasing software to (selected) users, then this option may suit you. It suggests that you hold a product backlog workshop involving the development team and Scrum Master after the next sprint planning has taken place, as the picture below shows.

This approach assumes that you require several days to gather the relevant user data before you can analyse it and make the appropriate backlog changes. It also assumes that you don’t have to wait for the data to arrive to decide on the next sprint goal. Instead, you can continue with the next sprint while collecting the data.

While option three allows you to validate your product quantitatively, it too has a drawback: As sprints are protected, the earliest point in time you can respond to the backlog changes is sprint+2. It is therefore advisable to start with option one and two, and use option three once the crucial risks in the backlog have been addressed. Additionally, you should focus on different features in sprint n+1 compared to sprint n in order to avoid the danger of continuing to move your product in the wrong direction.

Option 4: Continuously

If you don’t need to wait until the end of the sprint before you release a new or improved piece of functionality, then you will benefit from continuously collecting data, analysing it, and changing the product backlog accordingly. You may want to set a side 30 minutes every morning to look at the latest data and draw the right conclusion from it, preferably with the help of the development team or some of its members.

Note that option 4 assumes that you either make small incremental improvements to a product or that you run multiple overlapping experiments to test ideas for new or improved features, for example, by releasing feature fakes or MVFs.

Strictly speaking, Scrum is not well suited to support this approach. The model assumes that a cross-functional development team works together for several weeks to achieve a shared sprint goal and deliver a product increment. A sprint is intended to run one experiment or implement related product functionality. It’s not particularly well suited to execute multiple tests and to continuously release smaller enhancements and bug fixes. You might therefore consider changing from Scrum to a Kanban-based process, as I discuss in more detail in my article “Is Scrum Right for Your Product?“

1 Complement your Product Backlog with a Product Roadmap

I find that the product backlog is best used to capture the product details. In this sense, it is a tactical tool that facilitates product delivery. If that’s the case, then you will benefit from completing your product backlog with a product roadmap. A product roadmap sketches the overall journey you want to take your product on.

I like to work with goal-oriented product roadmaps, which contain product goals that describe the benefits or outcomes your product should create in the course of the next six to twelve months. This picture below illustrates this setup.

2 Focus your Backlog with a Product Goal

Use a product goal like acquiring users, increasing conversion, or future proofing the product by reducing technical debt to direct and focus your product backlog. Any items in the product backlog should help meet this goal. If that’s not the case, you should remove them. While this approach may sound radical, it will result in a concise product backlog that is comparatively easy to update and change

If you complement your product backlog with a product roadmap that contains the product goals your product should meet, as I recommended in tip #1, you can use the next goal on the roadmap and copy it into your product backlog. This nicely connects your product backlog and product roadmap.

3 Start with a Short and Sketchy Product Backlog

Starting with an incomplete product backlog with largely coarse-grained items is particularly beneficial when you create a new product or add new features. Collect the user and customer feedback on early product increments to decide which functionality should be implemented, to evolve the product backlog, and to refine its items. Note that is alright to have a longer, more detailed backlog when your product is mature and your focus is on incremental changes and bug fixes.

4 Collaborate with the Development Team

Involve the development team members in the product backlog work, for example, by running collaborative product backlog workshops. This allows you to benefit from their knowledge and creativity and discover technical risks and dependencies. It also increases the understanding and buy-in of the team members and results in better, clearer requirements. Ask your Scrum Master to facilitate the sessions to help you focus on offering product leadership while ensuring that everyone is heard and nobody dominates.

5 Prioritise the Backlog

Use uncertainty and risk to decide how soon an item should be implemented. Addressing uncertain items early on allows you to test your ideas, to fail fast, and to learn how to continue. Complement risk with cost-benefit and take into account dependencies when necessary. If you struggle to prioritise your product backlog, see my article “Prioritising a Product Backlog When Everything is Important.”

6 Get the Backlog Ready

A key purpose of the product backlog is to direct the work of the development team: High-priority items are pulled into the sprint transformed into a product increment. To ensure that this can happen, you have to break larger items into smaller ones until they are ready for sprint planning: the items should be clear, feasible, and testable. This facilitates choosing a realistic sprint goal, and it helps the development team members do their work without having to constantly ask you for clarification during the sprint.

7 Regularly Update the Product Backlog

The product backlog is not a static, fixed plan. Instead, it evolves based on the insights you gain from collecting user feedback and building the product. You should therefore regularly update and refine it together with the development team.

Analyse the feedback and data collected from exposing the latest product increment to the users and apply the new insights to the product backlog: remove and add new items, and update existing ones. This maximises the chances of building a product that users want, and it keeps the product backlog up concise and usable.

8 Say No

Have the courage to say no and decline ideas and requirements that do not help you meet the product goal and move you closer to realising the product vision. This ensures that your product has a clear value-proposition, and it prevents your product from getting bloated. If the idea or requirement is important but cannot be realised in the next months, then consider adding it to the product roadmap.

9 Look beyond User Stories

While user stories, and functional requirements in general, are important, they are usually not enough. Also consider the user interaction, the nonfunctional qualities of your product, and the user interface and capture them in your product backlog.

10 Make your Product Backlog Visible and Easily Accessible

As the product backlog describes the outstanding work required to progress the product, it is important that everyone involved in the development effort has access to it. I therefore recommend using a product backlog tool that is easy to use and that facilitates collaboration.

One option is to use a paper-based product backlog that’s on the office wall—assuming that people are collocated. A tool like my Product Canvas can help you structure and visualise your product backlog.

1 Users Come First

As its name suggests, a user story describes how a customer or user employs the product; it is told from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific functionality, such as searching for a product or making a booking. The following picture illustrates the relationship between the user, the story, and the product functionality, symbolised by the circle.

If you don’t know who the users and customers are and why they would want to use the product, then you should not write any user stories. Carry out the necessary user research first, for example, by observing and interviewing users. Otherwise, you take the risk of writing speculative stories that are based on beliefs and ideas—but not on data and empirical evidence.

2 Use Personas to Discover the Right Stories

A great technique to capture your insights about the users and customers is working with personas. Personas are fictional characters that are based on first-hand knowledge of the target group. They usually consist of a name and a picture; relevant characteristics, behaviours, and attitudes; and a goal. The goal is the benefit the persona wants to achieve, or the problem the character wants to see solved by using the product.

But there is more to it: The persona goals help you discover the right stories: Ask yourself what functionality the product should provide to meet the goals of the personas, as I explain in my post From Personas to User Stories. You can download a handy template to describe your personas from romanpichler.com/tools/persona-template.

3 Create Stories Collaboratively

User stories are intended as a lightweight technique that allows you to move fast. They are not a specification, but a collaboration tool. Stories should never be handed off to a development team. Instead, they should be embedded in a conversation: The product owner and the team should discuss the stories together. This allows you to capture only the minimum amount of information, reduce overhead, and accelerate delivery.

You can take this approach further and write stories collaboratively as part of your product backlog refinement process. This leverages the creativity and knowledge of the team and results in better user stories.

If you can’t involve the development team in the user story work, then you should  consider using another, more formal technique to capture the product functionality, for example, use cases.

4 Keep your Stories Simple and Concise

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out the rest. The template below puts the user or customer modelled as a persona into the story and makes its benefit explicit. It is based on by Rachel Davies’ popular template, but I have replaced user role with persona name to connect the story with the relevant persona.

As <persona> ,
I want <what?>
so that <why?>.

Use the template when it is helpful, but don’t feel obliged to always apply it. Experiment with different ways to write your stories to understand what works best for you and your team.

5 Start with Epics

An epic is a big, sketchy, coarse-grained story. It is typically broken into several user stories over time—leveraging the user feedback on early prototypes and product increments. You can think of it as a headline and a placeholder for more detailed stories.

Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for describing new products and features: It allows you to capture the rough scope, and it buys you time to learn more about how to best address the needs of the users.

It also reduces the time and effort required to integrate new insights. If you have many detailed stories in the product backlog, then it’s often tricky and time-consuming to relate feedback to the appropriate items and it carries the risk of introducing inconsistencies.

6 Refine the Stories until They are Ready

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. All development team members should have a shared understanding of the story’s meaning; the story should not be too big and comfortably fit into a sprint; and there has to be an effective way to determine if the story is done.

7 Add Acceptance Criteria

As you break epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, make it testable, and ensure that the story can be demoed or released to the users and other stakeholders. As a rule of thumb, I like to use three to five acceptance criteria for detailed stories.

8 Use Cards

User stories emerged in Extreme Programming (XP), and the early XP literature talks about story cards rather than user stories. There is a simple reason: User stories used to be captured on paper cards. This approach provides three benefits: First, paper cards are cheap and easy to use. Second, they facilitate collaboration: Every one can take a card and jot down an idea. Third, cards can be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. If using paper cards is not an option for you, then choose a tool that allows you to create virtual cards, as Trello does, for example.

9 Keep your Stories Visible and Accessible

Stories want to communicate information. Therefore don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible, for instance, by putting them up on the wall. This fosters collaboration, creates transparency, and makes it obvious when you add too many stories too quickly, as you will start  running out of wall space. A handy tool to discover, visualise, and manage your stories is my product canvas shown below.

10 Don’t Solely Rely on User Stories

Creating a great user experience (UX) requires more than user stories. User stories are helpful to capture product functionality, but they are not well suited to describe the user journeys and the visual design. Therefore complement user stories with other techniques, such as, story maps, workflow diagrams, storyboards, sketches, and mockups.

Additionally, user stories are not good for capturing technical requirements. If you need to describe what an architectural element like a component or service should do, then write technical stories or—which is my preference—use a modelling language like UML.

Finally, writing user stories is worthwhile when you develop software that’s likely to be used. But if you want to quickly create a throwaway prototype or mockup to validate an idea, then writing stories may not be necessary. Instead, it might be better to cocreate the prototype. Remember: User stories are not about documenting requirements. They want to enable you to move fast and develop software as quickly as possible—not to impose any overhead.

More User Story Tips

Wrong Context

As their name suggests, user stories tell a story: They describe in plain language how a customer or user employs the product. Instead of specifying every little detail, user stories offer an informal way to capture the requirements. This works, if the stories are complemented with a conversation that takes place between the product manager/product owner and the development team. In this conversation, the product person tells the story to the team; the team members ask questions and suggest adjustments. Ideally, the conversation takes place face-to-face with everyone being in the same room. The benefits of this informal and collaborative approach are twofold: It leads to better requirements and it saves time by shifting from written requirements to tacit knowledge.

Unfortunately, I see organisations apply user stories even if an effective conversation is very hard to achieve. Instead of discussing and refining the stories together, they are handed off to the development team. Often, the team is remote and has limited knowledge about the market and the product. To account for the missing conversation, the product manager or owner tries to write elaborate, detail-rich, and precise stories. This turns user stories into something they were not designed to be: formal requirements.

If you find yourself in a similar situation, then you have two choices: Make sure that an effective conversation does take place, for instance, by having regular onsite workshops or using videoconferences to discuss and adjust the stories with the development team. Alternatively use a different requirements description technique, such as use cases. Use cases offer more structure and make it easier to precisely describe a requirement, for instance, by using pre conditions and exception scenarios.

Wrong Job

User stories describe end user requirements. They were not designed to capture technical requirements. You can, of course, tell stories about how a product is built and use technical stories. But I find that natural language is not well suited to capture technical requirements and I prefer to work with a modelling language like UML (Unified Modeling Language). Why bother describing an interface or API in natural language when you can model and visualise it using a UML artefact?

If you find that your teams heavily rely on technical requirements, then this may indicate that you work with component teams – teams that are organised around architecture building blocks, such as components, services, and layers. An effective way to reduce the need for technical requirements is to reorganise the teams by forming feature teams – teams that implement user stories end-to-end in form of a vertical slice.

But it’s not only technical requirements that should not be captured as user stories. Complex user interactions, such as workflows and scenarios, and user interface requirements are also difficult to describe as a user story. Take, for instance, an online shop that requires the users to discover a product, select it and place it in the basket, and to pay for it. If you attempted to describe these steps with one story, you would either end up either with a big compound story or you would use the acceptance criteria to describe the workflow. Neither is desirable in my mind. A better solution is to use stories to describe discrete functional requirements and to complement them with other techniques, such as story maps, scenarios, workflow diagrams, and storyboards. I discuss this approach in more detail in my post User Stories are Not Enough to Create a Great User Experience.