4

Team Backlog Management

As we have learned, our Product Owner (PO) is responsible for managing and prioritizing the Team Backlog on a continuous basis; however, there’s more to it than that. In this chapter, we are going to take a look at the following:

• What is the Team Backlog
• User Stories
• Estimation, Story Sizing, and Splitting
• Flow, Kanban, and Backlog preparation for PI Planning

Let’s get started!

The Team Backlog

The Team Backlog is an ordered list of all the possible work that an Agile Team can undertake to enhance or deliver the solution. It comprises User Stories, Enabler Stories, Improvement Stories, and all other work items. Unlike the Iteration Backlog, the Team Backlog represents a list of wants, allowing for flexibility and ownership by the team in determining the order and timelines for delivery. Although the PO is primarily responsible for the Team Backlog, any team member can contribute an item, help refine it, and prioritize it.

Three primary inputs contribute to the Team Backlog: the ART Backlog, team contributions, and requests from Stakeholders as depicted in Figure 4.1.

Figure 4.1 – Input sources for a Team Backlog (© Scaled Agile Inc.)

The ART Backlog serves as a crucial contributor as its Features are decomposed into User Stories and Enablers Stories for the Team Backlog.

The team also contributes to the Team Backlog by capturing stories related to refactoring, maintenance, or technical debt reduction.

On the other hand, Stakeholders may request work from the team, posing significant challenges to the PO, which can include dependencies, commitments supporting the ART and its PI Objectives, feedback from System Demos, or Spikes and future research.

Additionally, Non-Functional Requirements (NFRs), depicted at the bottom of the Team Backlog icon, are constraints or restrictions that the team must consider for each item. To ensure that they are not overlooked, teams may automate testing of NFRs and include the requirements in their Definition of Done (DoD).

The Iteration Backlog serves as a subset of the Team Backlog and captures the committed work that the team has agreed to for the current iteration. Throughout the iteration, the team works systematically to complete and deliver the committed stories.

Pro tip

Too often, POs have a backlog that is a single long list that they are constantly reordering, which is the Team Backlog. Help your POs by creating a Kanban Board that emulates the Portfolio Kanban Board to track the maturity of the User Stories.

What is a User Story?

We define a User Story as “a short description of a small piece of desired functionality written from the user’s perspective, implemented by Agile Teams as small, vertical slices that can be completed in a few days or less” [2]. But what does any of that really mean?

User Stories evolved from Extreme Programming (XP) [8] as a response to shortcomings in traditional software development methodologies. XP emphasizes the importance of collaboration between developers and customers with frequent feedback and an iterative approach to development. XP identified User Stories to capture customer requirements. The idea was to write brief informal descriptions of the user’s need, focusing on what the user wanted to achieve rather than how the software would accomplish it. The User Stories were typically written on index cards. The practice has evolved and was adopted by other Agile methodologies.

On the front of the index card, we typically see the description written in what we refer to as User Story format:

Figure 4.2 – Example User Story Card

This format helps us understand who the request came from and what they want to accomplish. The why or the reason is the most important part of the User Story as it gives us the context for the request, how they intend to use it, or the expected benefit.

Pro tip

Sometimes, you may find it difficult to phrase the story from a user or customer’s perspective. I find it helpful to think about the human performing the action. For example, if you need to change a database to capture a requirement to track hours spent doing volunteer work in the time tracking database, you could write the following story:

As an employee, I want to be able to submit a request for volunteer hours and get it approved by my Manager quickly so that I get time off to support my charitable foundation.

The conversation is probably the most important part of writing a User Story so that the team can have a sufficient understanding of the work to be done. The conversation between the team, the PO, and Stakeholders ensures alignment on customer needs, definition of scope, and any potential roadblocks or challenges.

On the back of the index card, we capture the Acceptance Criteria. The confirmation comes from the set of Acceptance Criteria, sometimes referred to as AC, that need to be met for the User Story to be considered complete and to be accepted by PO or customer.

When writing Acceptance Criteria, we look for the following elements:

• Condition: A specific requirement or condition that must be met
• Action: A description of the action that will be taken to test the condition
• Expected Result: A description of the expected outcome or result of the action

Here’s an example User Story and Acceptance Criteria:

Figure 4.3 - Example User Story and Acceptance Criteria

In summary, the index card, the conversation, and the Acceptance Criteria (aka confirmation) are collectively referred to as the 3Cs of User Stories:

• the Card
• the Conversation
• the Confirmation

Story from the real world

I was working with a team that didn’t have “so that” as part of their User Stories. Let’s take a look at one of their User Stories:

User Story: As an administrator, I want to be able to remove users from the system.

Acceptance Criteria:

• When I navigate to the User Management section of the application, I should be able to see a list of all users.
• Each user in the list should include the user’s name, email address, and user role.
• When I select a user from the list and click Delete, a confirmation dialog should be displayed.
• If I confirm the deletion, the user should be removed from the system, and the user list should be updated to reflect the change.
• If I cancel the deletion, the user should not be removed from the system, and the user list should remain unchanged.

Based on the information they had, the team completed the User Story by adding a field to the database indicating that the user access had been removed. The team thought this was an elegant solution as it would be easy to restore access if needed without restoring the database from backups.

What the team didn’t know is that the user database was getting unwieldy, and this User Story was intended to provide a way to clean up old records that needed to be purged. The work they did on this story ended up as waste simply because they didn’t understand the reason for the request.

They skipped two crucial pieces of the User Story; the “so that” and the Conversation.

Now that we understand the construct of a User Story, let’s see what it takes to write a good User Story.

We can see that to write a good User Story, we need to consider it from multiple perspectives and it’s important to involve the entire team. We can also INVEST in our User Stories.

INVEST is an acronym coined by Bill Wake [4] to describe the attributes of a good story:

I - Independent (among other stories)

N - Negotiable (a flexible statement of intent, not a contract)

V - Valuable (providing a valuable vertical slice to the customer)

E - Estimable (small and negotiable)

S - Small (fits within an iteration)

T - Testable (understood enough to know how to test it)

You will want to spend time with the teams and the POs to work on writing User Stories. Include it as part of the Team Retrospectives to discuss stories that were particularly well written compared to those that weren’t and then challenge the team as an improvement to write better User Stories in the next iteration.

Pro tip

There are a lot of resources and User Story writing workshops available on the internet. Depending on the specific needs and challenges your team is experiencing, don’t hesitate to use them to help your team improve. Mike Cohn (Mountain Goat Software) has a great workshop titled Better User Stories: https://www.mountaingoatsoftware.com/training/courses/better-user-stories.

Types of Stories

Within the SAFe® Framework, we differentiate types of stories:

• User Stories are our primary means of expressing needed functionality
• Enablers Stories are stories that capture the architecture and infrastructure needed to implement User Stories

You may also see additional types of Enabler stories such as the following:

• Refactoring Stories capture activity necessary to improve code or a component’s internal structure or operation without changing its external behavior
• Spike Stories capture activities such as exploration, architecture, infrastructure, research, design, and prototyping with the purpose of gaining the necessary knowledge to reduce risk, better understand a requirement, or increase the reliability of an estimate
• Technical Debt Stories capture the work necessary to maintain and fix code that was developed quickly that needs to be reoptimized for the long term

The last type of story we will call out is Improvement Stories. These are stories or items that we want to ensure we work on in our drive for relentless improvement. Some teams keep these items in their Team and Iteration Backlogs; others create a separate backlog. Regardless of where you keep the items, make sure you are tracking them.

Pro tip

It often doesn’t make sense to write Enabler Stories in User Story format. It can be clearer to specify just the what and why. For example, if we need to upgrade a piece of software on a server, it can be simpler and clearer to state “Upgrade xCode from version 1.2 to 1.3 to fix known security loophole” than “As a server administrator, I want to upgrade xCode from version 1.2 to 1.3 so that hackers can’t access our database.”

Bottom line: don’t get overly hung up that every story must be written in User Story format, particularly if the user is another system or the focus of the story is improving underlying technology rather than adding new functionality or Features for end users.

Why do we have different types of Stories?

We often get asked this question, or “why do I care if it is an Enabler Story, a User Story, or Technical Debt?” This simple answer is Capacity Allocation. Capacity Allocation is the allocation of work by the type of work. While we typically begin to think about Capacity Allocation for the ART Backlog, we want to understand how it impacts the Team Backlog as well.

By looking at the different types of stories in our Team Backlog (or Iteration Backlogs), we can ensure that we maintain a balance between delivering customer value and improving the system architecture.

If we are only focused on new functionality, then we might not be considering the long-term sustainability of the solution, which can lead to decreased velocity over time. Whereas if we are focused on delivering infrastructure, our customers may go elsewhere if they don’t get new Features and functionality.

Pro tip

As a Coach, when I first launch an ART, I tend to not worry about what types (Enabler vs. User) of stories the teams are working on as my primary focus is to have them begin to work together as teams and in the new Agile ways of working with incremental delivery. I will work with Product Management, the RTE, and System Architect to review the stories and capture the type during the PI.

In the next PI, we work with the POs and Scrum Master/Team Coach to review the stories that we added a type to and then let them work with their teams to begin to add the types for the stories we will be planning in the third PI event.

Incrementally introducing this practice allows real examples and a better overall understanding of why it’s important and creates an additional opportunity to improve story-writing practices.

Estimating User Stories

Estimating stories is an important activity that allows us to forecast the work to be completed. The goal of estimating User Stories is to understand the complexity and size of each story while also accounting for the knowledge and uncertainty the team may have.

It is important to point out that estimation should be done by the team who is doing the work, not a Manager, an architect, or even an individual as it negates the benefits of the team having a shared understanding of the work and improved accuracy of the estimate by inclusion of all perspectives.

There are different techniques and approaches to estimating User Stories. The most common are as follows:

• Story Points: This technique is based on the relative scale of complexity and effort required to complete a User Story compared to other User Stories. The team assigns a numerical value (e.g., 1, 2, 3, 5, 8, or 13) to each story based on its complexity, effort, and risk.
• T-shirt sizes: This technique uses t-shirt sizes (e.g., XS, S, M, L, XL) to estimate User Stories. The team assigns a size based on the level of effort and complexity required to complete a story compared to other stories in the Team Backlog.
• Planning Poker: This technique involves a team discussion and consensus-building exercise to estimate User Stories. Each team member assigns a numerical value to a story based on their individual assessment of its complexity and effort, and the team discusses and reconciles any differences to arrive at a shared estimate.

Pro tip

We use the modified Fibonacci Sequence to assist in estimating the relative sizes of User Stories or backlog items. The sequence starts with 1 and each subsequent number is the sum of the previous two. We continue this pattern until 13, and then we use 20, then 40, and then 100. The full sequence is 1, 2, 3,5, 8, 13, 20, 40, and 100. By utilizing these numbers, Agile Teams can gauge the relative size or effort required for completion.

Whichever method you use to estimate story size, it’s essential to consider the Acceptance Criteria, complexity, and dependencies. To improve your estimates, use relative sizing to compare User Stories to others you have previously estimated and assign the size based on the perceived level of effort and complexity.

For example, if your team has estimated a User Story as three points, then a similar story may also be estimated at three points, regardless of whether the absolute effort involved is the same. Relative sizing is useful for several reasons, including the following:

• It is faster and less prone to errors than trying to estimate absolute values in hours or days
• It allows for more accurate estimation when dealing with uncertainty and incomplete information
• It encourages team collaboration and discussion during the estimation process, leading to a shared understanding of the work to be done

Normalized story points are essential in SAFe®. They provide a way to estimate work relative to other tasks and can be used by teams with no experience with Agile development or without real data on their performance.

By using this method, normalized story points provide a method for getting to an agreed starting baseline for stories and velocity as follows:

• Give every developer-tester on the team eight points for a two-week iteration (one point for each ideal workday, subtracting two days for general overhead).
• Subtract one point for every team member’s vacation day and holiday.
• Find a small story that would take about a half-day to code and a half-day to test and validate. Call it a “one.”
• Estimate every other story relative to that “one.”

Example: assuming a six-person team composed of three developers, two testers, and one PO, with no vacations or holidays, then the estimated initial velocity = 5 × 8 points = 40 points/iteration. (Note: Adjusting slightly lower may be necessary if one of the developers and testers is also the Scrum Master/Team Coach.)

Once a team has some real data about its performance, normalized story points should no longer be used as they become less accurate over time as the items in the backlog change. At this point, teams need to switch from normalized story points and start tracking velocity based on completed work items instead.

Relative estimating is comparing two pieces of work and determining how much more effort one task requires than another. This allows us to quickly determine how long it will take us to complete our backlogs without measuring each item individually, which would take too long and not provide accurate results.

Pro tip

Too often, I see organizations assuming based on this formula that 1 story point is 8 hours of work, and then teams begin estimating how many hours it will take to develop (10 hours), test (6 hours), and deploy (2 hours) the story. Total up the number of hours (18 hours), divide by 8, and round up to calculate the story points (3 points). Do not fall into this trap.

Story Splitting

When defining what a User Story is, we stated that we should be able to deliver it in a few days. That means that the team should be able to design, build, test, and deploy to meet the DoD for that User Story. This often means that the teams must rethink how they have typically received requirements and broken down the work.

This breakdown does not mean that the team will write a story to figure out what they are going to do, another story to do the work, another story to test the work, and yet another story to deploy it. If we are doing that, we don’t have a vertical slice of the work.

A vertical slice is a User Story that cuts through all the layers of a system from the user interface down to the data layer. A vertical slice is developed and tested from end to end, providing a working and usable increment of the system.

To create vertical sliced User Stories for our teams that can be completed in a few days, we will often need to split our Features and even other stories. There are several techniques as outlined in Agile Software Requirements [4] that we typically consider when splitting stories, including the following:

• Workflow steps: Stories can be split based on the steps involved in a particular workflow, allowing the team to focus on one step at a time and deliver value incrementally.
• Business Rule Variations: Stories can be split based on variations in business rules, allowing the team to address specific business rules separately and avoid developing a single, complex story.
• Major Effort: Stories can be split based on major effort, allowing the team to focus on the most important and valuable aspects of a story first.
• Simple/Complex: Stories can be split based on simplicity or complexity, allowing the team to work on simpler parts first and then move on to more complex aspects of the story.
• Variations in Data: Stories can be split based on variations in data, allowing the team to address specific data variations separately and avoid developing a single, complex story.
• Data Entry Methods: Stories can be split based on different data entry methods, allowing the team to focus on each method separately and deliver value incrementally.
• Deferred System Qualities: Stories can be split based on deferred system qualities, allowing the team to address those qualities in separate stories later in the development cycle.
• Operations: Stories can be split based on operations (Create, Read, Update, Delete (CRUD)), allowing the team to focus on specific operations separately and deliver value incrementally.
• Use Case Scenarios: Stories can be split based on use case scenarios, allowing the team to focus on specific scenarios separately and deliver value incrementally.
• Break-out Spike: A spike is a short, focused investigation to answer a question or resolve a technical uncertainty. Stories can be split based on breaking out the spikes into separate stories, allowing the team to address specific technical issues separately and avoid developing a single, complex story.

By splitting stories, we avoid developing big, complex stories that take a long time to deliver and may not provide much value. By splitting stories, we focus on delivering small incremental improvements that add up to significant progress over time.

Caution

Avoid the trap when splitting stories that a User Story originally estimated at 8 points, once split, still needs to equal 8 points. When splitting User Stories, you will need to re-estimate them independently of each other and relative to the other stories in your backlog. You might be surprised to discover that your 8-point User Story is now two 3-point stories.

User Story Prioritization

Achieving continuous value flow requires that the highest-value backlog items are delivered in the shortest sustainable lead time and in the right sequence. The PO enables this by regularly ordering backlog items according to their cost of delay and communicating that sequence to the team during Backlog Refinement and Iteration Planning. So, when we talk about Team Backlog prioritization, because the team inherits the prioritization from the Features prioritization, we are effectively sequencing the work, but thereafter we will refer to it as prioritization.

Prioritizing the backlog can be particularly difficult for a PO as they have to balance all of the following: the needs of the Stakeholders and customers, the priority of Features versus the Enabler Features, Architectural Runway and Technical Debt, Milestones and deliverables, and the list could go on.

When we prioritize the Team Backlog, we create focus and alignment and receive the following benefits:

• We ensure we deliver the most valuable items first
• We create a roadmap for our team with clear direction on what to work on next
• We are able to make better decisions and understand trade-off costs when priorities change, or new requests come in
• We see improved efficiency as we end up eliminating unnecessary work, reducing waste

When prioritizing your backlog, it may be helpful to define your prioritization criteria. Consider what factors are most important to your team. This may include Business Value, Feature prioritization, risk mitigation, dependencies, and sequencing.

MoSCoW is another common technique where you assign the story to one of four categories:

• Must have
• Should have
• Could have
• Won’t have

You could consider using this in conjunction with other techniques such as Story Mapping.

Regardless of the technique you use, remember that prioritization is an ongoing process and requires continuous communication and collaboration between the team and Stakeholders. It’s important to regularly review and adjust your Team Backlog to ensure that you’re delivering the most valuable work first.

Getting your Team Backlog to Flow

Managing the Team Backlog with hundreds of stories requires a lot of work and effort. By capturing the Team Backlog in a Kanban system, you can create alignment and visibility, which makes managing it much simpler. The Team Backlog Framework article suggests using a similar structure to the Portfolio Kanban. In Figure 4.4 is another example for your consideration:

Figure 4.4 – Example Team Kanban Board

When designing your Team Backlog Kanban board, it is crucial that you can quickly and easily identify which items are ready for the team to tackle, prioritize them effectively, and visually represent the current status of the backlog items. It is also essential to consider establishing Work-In-Progress (WIP) limits for each state and developing policies for when an item can be pulled into the next stage. The team should define and adjust the WIP limits and policies as necessary to ensure that work flows smoothly through the system and evolves over time to meet their evolving needs.

Kanban Team Stories

In Kanban, we typically use the term work item rather than story. However, in SAFe®, we understand that teams should have autonomy, but they are not autonomous. Therefore, wherever we can simplify the language to a common taxonomy, it makes it easier to communicate with other teams. To that end, in SAFe® Kanban, we also use the same story vernacular.

Figure 4.5 – SAFe® Team Kanban method overview (© Scaled Agile, Inc.)

It is much easier to calculate flow metrics when work items are roughly the same size and we always want to work in small batches. Make sure you have clear policies for the Definition of Ready (DoR) and the DoD and that you’re always comparing apples with apples.

Team Backlog Preparation for PI Planning

Having a Team Backlog that is ready for PI Planning is important in that it allows the team to focus on dependencies, ensuring alignment with the Vision, architecture, and Roadmap. They have the time and space to collaborate with other teams, create plans with high confidence, and draft PI Objectives at the event.

Each team will be different in the amount of preparation needed for PI Planning. We have found success when the teams have identified and roughly estimated the stories for the next PI ahead of PI Planning. These stories (except those that will likely be worked on in the first iteration) aren’t well refined and wouldn’t meet the DoR.

You will want to ensure that your teams don’t go into PI Planning with a fully refined and planned backlog, knowing what stories will go into which iterations and then spend the event staring at each other. You may even find that they become overly attached to their plans and resistant to changing them when necessary, based on feedback from other teams and Stakeholders. It’s important for teams to strike a balance with the amount of preparation and to be open to feedback and adjustments.

Summary

We discovered that the Team Backlog is a collection of work that the team can undertake, which includes User Stories and Enablers. The PO is primarily responsible for it, but any team member can contribute to it. We learned that User Stories are small pieces of desired functionality that our Agile Teams implement within a few days. Acceptance Criteria are the conditions the story must meet to be considered complete.

We also took a look at the importance of estimating User Stories, which is done by the team, and outlined several techniques for splitting and prioritizing User Stories with reminders to always factor in relative sizing. Lastly, we took a look at Kanban Team Backlogs, and how to prepare for PI Planning.

Let’s now take a look in w at the events the teams execute.

Further reading

1. Team Backlog: https://scaledagileframework.com/team-backlog/
2. Stories: https://scaledagileframework.com/story/
3. Enablers: https://scaledagileframework.com/enablers/
4. Leffingwell, Dean (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
5. Refactoring: https://scaledagileframework.com/refactoring/
6. Spikes: https://scaledagileframework.com/spikes/
7. Design Thinking: https://scaledagileframework.com/design-thinking/
8. Extreme Programming: https://en.wikipedia.org/wiki/Extreme_programming