Team Backlog Refinement

While building trust gives teams the ability to reconfigure and “do the right thing,” it is also necessary to make sure that team members know what the right thing is. Team members must all work toward the same goal, and in volatile, complex environments that goal is changeable.

– General Stanley McChrystal, Team of Teams [1]

---

---

What is Team Backlog Refinement?

Tam Backlog Refinement is for the Agile Team to understand and prepare upcoming stories, identifying the work needed in future Iterations to achieve their PI Objectives or prepare for a future PI Planning.

What is the purpose of the Team Backlog Refinement?

Team Backlog Refinement helps the Agile Team identify and clarify the challenges they need to tackle in upcoming work cycles. By doing this, they can better achieve their commitment to their PI Objectives and upcoming iterations.  Agile Teams usually break down work into smaller pieces called stories, expressed in terms of what the customer needs. Each story includes its acceptance criteria, which outline what a successful solution will look like. 

Agile Teams play a crucial role in product development, focusing on solving problems. The business depends on these teams to improve existing products by adding new features or even developing entirely new products. To manage these complex issues effectively, larger problems need to be split into smaller, more manageable tasks. 

The team benefits from breaking work into smaller parts, which also makes it easier for them to track their progress. 

This business benefits by gaining more deliberate planning across. This enables reliable forecasting and predicting how much work can be done in future iterations.

How does Team Backlog Refinement connect with the SAFe Principles?

SAFe Principle #6: Make value flow without interruptions – Agile Teams are most effective with small, consistently sized stories that fit in the Iteration timebox. Backlog refinement breaks large work into manageable stories, enabling smooth flow through the Agile Team.

SAFe Principle #8: Unlock the intrinsic motivation of knowledge workers – Knowledge workers are best suited to break down and prepare the upcoming stories. This direct ownership of the team backlog ensures a continuous flow of ready work generated by the Agile Team within the broader ART backlog.

What is the outcome of the Team Backlog Refinement?

An understanding of the problems that need to be solved in future Iterations. Team and stakeholder have a shared understanding of the upcoming work and it’s priority in relation to other potential work.

What are the inputs and outputs?

Inputs to Team Backlog Refinement include:

• Team and ART PI Objectives: Understanding the PI Objectives that were committed during PI Planning allows the team to focus on refining the backlog of stories that could contribute to the next Iteration. 
• Stories: Stories that were created throughout PI Planning. Candidate stories that have been identified through the Team Review and Retrospectives. New insights that have emerged from completing earlier stories.

A successful Team Backlog Refinement event delivers the following outputs:

• Stories: The stories within the team backlog which are higher in priority to achieve next have been discussed and further detailed. Acceptance criteria has been identified. The stories have been adjusted in priority order based of recent learnings. Additional stories have been identified such as spikes or enablers.

How does the Agile Team prepare for the Team Backlog Refinement?

Agile Teams prepare for refinement by focusing on ensuring they have the necessary inputs and context before starting the process.

• Gather Initial Stories (Inputs): The team needs some initial stories, sometimes called shell or placeholder stories, to start the refinement process. These stories initially consist of just a title and act as placeholders for potential future work. The Agile Team typically creates stories during PI Planning to understand the work they can commit to for the PI. New stories may also emerge from the Agile Team’s local context or external demands, often identified through the Iteration Review, System Demo, and Retrospectives.

Understand ART Context and Priorities: The Agile Team needs to understand the ART’s goals for the PI and the vision for the ART as a whole. This insight can be found in ART vision artifacts, the ART’s PI Objectives, and the ART Planning Board. This insight allows the team to prioritize which stories to prepare so that it has enough ready for Iteration Planning in the next Iteration.

How to run the Team Backlog Refinement?

Agile Teams apply a continuous, flow-based approach to backlog readiness. So, the backlog always contains some stories ready to implement without significant risk or surprise. Maintaining the team backlog is a critical activity and includes the following activities:

• The PO regularly collaborates with the team and stakeholders to prioritize the team backlog
• Stories that have aged or perhaps are no longer relevant are removed
• New stories, including enablers, are discovered and described
• Stories are readied for the next iteration by defining acceptance criteria and sizing them to fit within the iteration

Although the PO leads the refinement and prioritization of the team backlog, refinement is a collaborative process.

Who Attends Team Backlog Refinement?

Attendees of the Team Backlog Refinement event include:

• The Product Owner
• Scrum Master/Team Coach
• The Agile Team
• Any other stakeholders required as needed, including any subject matter experts and representatives from other Agile Teams or ARTs.

The Scrum Master/Team Coach typically facilitates the Team Backlog Refinement, ensuring that Agile Team gets through the process effectively and has enough Stories elaborated, ready for Iteration Planning. 

The Product Owner, representing the Business, with their knowledge of the Product and of what the Business wants from the Product, provides the overall context for Backlog Refinement and insight into acceptable solutions to the problems being posed.

What is the usual agenda for Team Backlog Refinement?

There is no single recommended pattern for refining the backlog. Some teams like to refine the backlog after their Team Sync. Others prefer weekly sessions or requirements specification workshops, applying behavior-driven development (BDD) techniques to help explain stories. Multiple teams often collaborate on feature development, so new issues, dependencies, and stories are likely to emerge. Backlog refinement also helps surface problems with the current plan, which may require discussion at Team, PO, or Coach Syncs.

Regardless of style, an agenda generally contains:

Align on Priorities	Remind the team of ART vision and PI Objectives to guide refinement.
Define the Stories	Discuss each item to establish acceptable solutions and capture acceptance criteria.
Initial Sizing & Splitting of Stories	Break down large stories so they fit easily within an iteration.
Collaborative Prioritization	Adjust backlog sequence based on value (Product Owner and stakeholders) and technical sequencing (Agile Team).

The Agile Team regularly reviews its priorities based on recent learnings, PI Objectives, and the ART Planning board. These priorities guide the selection of stories refined for the upcoming PI.

In refinement sessions, each story is presented, followed by discussions with the Agile Team, the Product Owner, and relevant external participants. This dialogue helps clarify the acceptance criteria, which define the boundaries of an acceptable solution. If stories are too large for the iteration, they are split into smaller ones that can be completed within that timeframe.

Refinement fosters collaboration among the team, customers, and stakeholders, breaking down barriers and reducing waste. Together, they create acceptance criteria that clarify requirements and promote ownership.

Prioritization is also a collaborative process. Stakeholders provide business insights while the team suggests an order for addressing the backlog that optimizes problem-solving.

---

References

[1] McChrystal, Stanley, T. Team of Teams: New Rules of Engagement for a Complex World. Penguin, 2015

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007