Connecting to Backlogs

Work comes into the backlog from several sources. The main source should be from the idea increments or feedback from customers. In Chapter 16, the concept of decomposition and the practice of story mapping are shared. When you start a story mapping session, its unclear what the result may be until you cut the first increment. You connect the dots by listening to everyone in a divergent mode and converging to an increment of work.

There is a lot of storytelling going on during story mapping, where you consider what story the customers are telling as they experience the idea. In making storytelling a collaborative session, we effectively ask participants to listen to multiple options and connect the dots to a meaningful end-to-end slice.

The challenge in connecting the dots between idea and user story is that you start with an idea that can have multiple options and directions. In the middle of a story mapping session, it can be quite nebulous as to how it may end, and it is important to be comfortable with this uncertainty. The end result is a collection of epics and user stories that are added to a backlog(s).

The key is to connect the ideas in the enterprise idea pipeline to their children (that is, epics and user stories) in the backlog and vice versa, as illustrated in Figure 17-1. Connecting ideas helps ensure a smooth flow of customer-value work from the portfolio level to the team level, and it ensures there is traceability from the idea down to user stories and tasks.

Figure 17-1. Connecting the enterprise idea pipeline to user stories that support the idea

The penultimate backlog is one that virtually supports all levels of requirements elements across your requirements tree. Through the use of filters and tags, you can instantiate any level of requirements you’d like to visualize such as a portfolio view of all ideas (or at least the highest-value ideas), an idea or product view, or a team view. What you really want to highlight is what parts of the idea are actually being worked on. It would be great to be able to click an active idea and instantly see what user stories are actually being worked on that support that idea.

Working with the Backlog

A backlog is effectively a list of prioritized work. Teams in Agile operate from a backlog typically called a product backlog, but may be referred to by other terms. Backlogs can be stand-alone, although I recommend that they be connected to the enterprise idea pipeline of work on the higher end and even a maintenance backlog of work on the lower end.

Product Owners own a backlog. It is their primary tool for collecting and managing requirements. It should be the single source of requirements for both transparency and efficiency reasons. The PO typically adds work items to the backlog and prioritizes them according to the value-based prioritization method he or she chooses to use.

The team should have continuous access to the backlog. In the spirit of self-organizing, anyone may contribute work in the form of epics, user stories, and tasks to the backlog. However, only the PO can prioritize the work. The team should have edit rights to add details to each work element whether epic, user story, or task.

When you look at a backlog, what do you see and how deep do you look? If a backlog is prioritized, you see the requirements elements that are deemed the most important at the top, as illustrated in Figure 17-2. This work is typically the current work the team is focusing on, either in a sprint or recently pulled from the backlog. The next set of priority requirements elements are possible upcoming work. The reason I say “possible” is that when you apply an Agile mindset, requirements are not locked in and they can change. From there, you have possible future work followed by may-never-get-done work.

Figure 17-2. Product backlog iceberg

Types of Backlogs

There are many forms of backlogs. They can be in the form of a Kanban board or Scrum board. Traditionally, backlogs are aligned with teams and called product backlogs or team backlogs. These backlogs are usually filled with epics, users stories, and tasks. Agile teams use backlogs to help drive their work. All backlogs in Agile are meant to be prioritized. The following are examples of several backlogs.

An enterprise idea pipeline is form of a backlog. The difference is that the enterprise idea pipeline focuses on the portfolio of ideas as they come into the enterprise, and it tracks progress from the Record stage to the Reflect stage. Stakeholders of value (product owners and chief product owners as well as business, marketing, and senior managers) use this backlog to prioritize by value and drive investment decisions.

A product backlog is a backlog of work that revolves around a product, service, or idea. The PO owns it. While anyone can add work on the product backlog, only the PO can prioritize it. Work that comes from decomposing the idea is placed in this backlog if it is product-centric. From there, it is often groomed to add detail and better understand the work. Those user stories that are at the top of the product backlog are of high priority and are ready to be pulled and worked on.

The sprint backlog is a backlog of work that fits into a sprint. It represents a subset of user stories that are prioritized high enough to get pulled into the sprint. Those stories that are highest priority and fit the team velocity or amount of work a team can complete within a sprint become the sprint backlog. There is a unique sprint backlog for each sprint. The items in the sprint backlog get pulled from the product backlog during sprint planning. The sprint backlog forms the backbone of the work within a sprint.

The team backlog is a backlog of work that is meant for a team. It is beneficial when you have multiple Scrum teams building a product together or if the team is non-product specific. The team backlog represents a view of the work that is geared toward a particular team. During grooming and sprint planning, the team hones the work in their prioritized backlog. From that, the team can establish a sprint backlog of those high-priority stories they will work on within a sprint.

While technically a story map described in Chapter 16 is not a backlog, it does provide a view of the current and future work much like a backlog. More importantly, a story map provides a third dimension to the backlog by providing the customer experience view of the work ahead. It is important when story mapping is being used to connect the idea to the story map to the backlog. The story map used for an idea should continue to live as additional increments are considered and additional options in the form of epics and user stories are generated to populate the backlog.

Attributes of Backlogs

The beauty of a backlog, whether an enterprise idea pipeline or a product backlog is that you can enhance it with attributes that can help you sort and understand the requirements within. Attributes are characteristics that can help you find distinctions among requirements. An example of an attribute is priority. By including an attribute that helps you consider the importance of requirements, you are able to sort the requirements by order of importance, allowing you to focus on the high-priority requirements.

Figure 17-3 illustrates a simple version of a backlog. It includes the identification number, user story, size, priority, source, an indication of progress, and owner of the work. Some people use a paper-based backlog that is laid out on a wall, while most people use an online backlog management tool that often includes a variety of features.

Figure 17-3. Example of a backlog

There are many types of attributes that can be included on your backlog to help you manage the work. These attributes include the following:

• Requirements Types : a way to differentiate among requirements types such as ideas, increments, epics, themes, user stories, tasks, and defects.

• ID : a way to provide a unique identifier for each requirement.

• User Story: a requirement that includes who wants it (personas), what they want, and why they want it.

• Details: information learned during grooming and planning including decisions.

• Acceptance Criteria: the conditions that satisfy a requirement typically at the user-story level.

• Source : the origin of the requirement, such as customer, stakeholder, or strategy.

• Priority: a way to differentiate the importance of the requirement, often written as high/medium/low or must have/should have/could have/won’t have.

• Sizing: a way to indicate the amount of work involved in a requirement often specified in story points (for example, 1/2/3/5/8/13/20).

• Complexity: the factors and risks involved in completing the work written as high/medium/low. Can impact the size of the work.

• Dependencies: a way to indicate when a requirement is dependent on other requirements or external items.

• Progress: the current status of the work. May also include the history of the item.

• Owners: the team members who have volunteered to do the work.

Considering Dependencies

Managing dependencies is a big part of running an enterprise. Similarly, managing requirements is often an activity of managing dependencies. Some work is required in order for other work to complete. Other work may be needed to complete an end-to-end view of the work.

Be aware of lower-value work that may be dependencies. If a high-customer-value user story is the next requirement to get pulled for work, you may learn upon grooming it that it depends on lower-value work getting done first. In this case, either the lower-value work inherits the higher value or you continue to keep it as lower value and create the dependency link.

Importance of Grooming

Grooming or refining is the process of honing user stories to gain a level of detail and get them ready for sprint planning. In relation to customer value, while technical details will be discussed, the key focus in grooming should be the business details on why an epic or user story is needed. When there is a strong understanding of why something is needed and in what business context, the team is able to make more context-specific technical decisions to support the customer need. The business context and reason may be inherited from the story map or idea itself if properly explained.

There are a number of benefits for grooming sessions. Since grooming typically occurs prior to working on the requirement, it allows time for the new work to “sink in” and to mitigate risks, and it gives the PO time to address unanswered questions. It also provides a short window of where the work is headed.

During grooming, the focus should be on the higher-priority work for the simple reason that it is better to put effort in the highest-value work and not waste time focusing on lower-value work since you may never get to it.

The PO is primarily responsible for the grooming event. The PO should invite the full team and include others such as marketing and business leaders who may have business context. Most importantly, the team can ask the PO tough questions regarding specific information and acceptance criteria to gain relevant details about the story.

What does a grooming event look like? It may last a couple of hours when the user stories are reviewed in a priority order. Each story may be focused on for about five to ten minutes with the goal of gaining a better understanding of the work, starting with understanding the business reason for the work. The better you groom the higher-priority items within the backlog, the easier and shorter the sprint planning event will be.

While grooming, you may focus on breaking epics into user stories, ensuring user stories are in canonical form (or a defined form), adding business and technical detail, identifying dependencies, understanding acceptance criteria, identifying unknowns and risks, capturing what is out of scope, and optionally considering sizing (T-shirt sizing of S/M/L or even story points). Finally, you may mark stories ready for sprint planning or ready for work.

How Well Connected Are You to Your Work?

A big part of helping employees see the full picture of customer-value work is the ability to connect the dots from when ideas come in all the way down to the user stories and tasks. This may not be as easy as it seems since enterprises are rarely one transparent, end-to-end requirements canvas where you can see the full requirements tree in one space.

Do you have people, processes, and technologies that can help you “connect the dots” across your requirements landscape? Can you be sure that the ideas of highest customer value are being worked on? Can you see the user stories that help build the increment of an idea? Connecting the ideas to your user stories provide transparency to your work, a view of what work is getting attention, and the assurance that the user stories connected to the highest-value ideas are indeed being worked on.