Implementing SAFe at the Team Level
As teams are trained in SAFe, they learn how to use a Kanban board to visualize their iteration execution. They also experience their first PI Planning during which they create their Iterations Plan, which will be used to feed their Team Backlog throughout the Program Iteration (PI).
There is a saying in SAFe that “Nothing beats an Agile team—other than a “team of agile teams.” While you can choose to have one team Kanban board per team, we recommend visualizing all teams on one board with a lane per team. This enables different teams to see each other’s work—providing better transparency and alignment.
To reflect this approach, the Team Kanban Board template in AgilePlace provides a horizontal lane for every team on the Agile Release Train (ART) in which they can manage their Team Backlog structured into iterations if they wish to as well as their iteration execution area.
Team Backlog and PI Program Kanban Board
The Team Backlog is where the Product Owner and the team manage upcoming work at the story level. This includes a mix of user stories, enabler stories, defects, maintenance, etc.
In SAFe, planning occurs at the PI level to provide a high-level forecast into which stories are targeted to start and during which iteration within the PI. We visualize this information in AgilePlace by splitting the Team Backlog area into sub-lanes for each iteration within the PI. This helps reflect the “Program Board” that was created during PI Planning.
Estimating Work at the Team Level
SAFe Agile Teams estimate the size of their work so that they can plan a realistic high-confidence iteration and PI. The canonical way is familiar to Scrum practitioners, using fibonacci-scale poker planning to estimate story points for each story.
In parallel, work out the potential velocity/capacity for the iteration and then aggregate the 5 iterations in the PI. Your potential velocity/capacity should be based on either historic data if available or a simple function of the # of people on the team, their available capacity for the iteration, and some focus factor in case historical velocity isn't available. This is well documented in the "SAFe for Teams" and "Leading SAFe" training workshops.
SAFe doesn't mandate breaking stories into tasks as part of iteration planning. Note that tasks can be used for team planning purpose but shouldn't be estimated. One of the effects of applying Kanban principles in SAFe is to deemphasize task management and focus more on story flow using the Team Kanban Board.
Side note: Avoiding Story-Level Estimates Altogether
To take it further, a team/ART could decide that counting stories, or throughput, using AgilePlace’s speed report is sufficient - and that it may even be a more accurate estimate at the Team level. Note that more and more teams/organizations are starting to do exactly that. This is known as the "No Estimates" movement. You can read http://yuvalyeret.com/safe-with-no-estimates for a deeper explanation of how to apply No Estimates to SAFe.
Representing PI Program Dependencies between AgilePlace Boards
You can connect cards across the same and/or multiple boards in AgilePlace to help you manage inter-dependent work items:
- Create a connection between card A and other cards B,C,etc. to represent the fact that A depends on B, C. etc. This will be reflected on card A.
- If a card is blocked while waiting for a dependency use the "Block" indication in AgilePlace and include the dependency information as part of the block reason.
- Cards B, C, etc. that other cards are dependent on should be marked with an appropriate class of service - the "Has dependents" indication.
- Refer to this help article for more info on card connections.
How to Plan a Program Increment (PI Planning)
PI Planning is such a crucial activity in implementing SAFe that it is worthwhile reviewing how the different elements of the SAFe templates in AgilePlace come into play as part of it:
- When preparing for PI Planning, the Program Kanban Board is used to manage and visualize the flow of backlog readiness and the preparation of Features for the PI.
- In preparation for the day after PI planning and the start of execution, relevant boards should be created for teams, objectives and risks.
- Note that during the actual PI planning sessions we recommend using physical boards to manage Iterations, Risks, Objectives.
- After PI Planning:
- Agile teams update the “Team Backlog” area in their specific lane on the team’s board to represent the view of the Iterations
- Agile teams update their team PI objectives using the objectives Kanban board.
- The Release Train Engineer (RTE) updates ART-level PI objectives in the objectives Kanban board.
- The Release Train Engineer (RTE) updates Program Risks in the Program Risks Kanban Board.
- Work item dependencies captured on a physical Program Dependency Board created during PI planning can be visualized on the Team’s Kanban Board (see dependencies discussion above) through card connections.
NOTE
For highly distributed PI planning workshops, the program-level board templates in AgilePlace can be used throughout the meeting to enable remote collaboration. We recommend that local teams still use physical boards during their breakouts and then populate the relevant AgilePlace board in time for review.
The psychology of using a virtual tool vs a physical tangible board as part of a workshop is non-trivial. If you’re planning to run a highly distributed PI planning make sure you consult with an experienced SPC/consultant to figure out how to effectively use technology to help make your PI planning successful.
Team “In Process” Area - Flexibility to reflect your team process
Teams in SAFe might follow different workflow processes. Some might be practicing pure Scrum. Some might be doing Kanban on a cadence, ScrumBan, or a continuous-delivery focused Kanban. Even within each one of these approaches, there might be different workflows or value streams for different teams.
You can adapt the SAFe templates in AgilePlace to give each team the flexibility to create the process that works for them. For example, this might require different lane structures, lane order, policies etc. Use the Board Layout Editor and clone one of the existing team lanes several times until you have the right amount of lanes for all teams on the train and then adjust the lanes if necessary for the process of each team.
Scrum teams will have a “Sprint Backlog” committed queue while Kanban teams will have a “Ready/Next” queue they continuously pull from. Teams using Kanban in more depth will typically have more sub-lanes reflecting queuing/in progress stages and more policies.
Acceptance Testing
Acceptance criteria that help confirm what the User Story is about are discussed in a conversation once the story is about to be pulled into development (either at the Sprint/Iteration Planning for classic Scrum Teams or as part of pulling the story for Kanban teams working Just-in-Time).
These acceptance criteria can then be documented either as bullet points in the description or using the "Acceptance Test" task type within the Story card "Tasks" area as can be seen on this example card. We recommend agreeing on a standardized template for new cards to adopt. Keep a copy of the template card in a reference lane and copy this card as a shortcut for creating new cards.
A test should be pulled into "in progress" when focusing on designing and implementing code to pass it and then moved to "done" when there's working tested code that passes that test. This is essentially a Test-First practice implemented at the acceptance-test level (which is ATDD - Acceptance Test Driven Development as compared to TDD - Test Driven Development. This is a highly recommended practice for all agile teams and is one of the Built-In-Quality SAFe practices)
For a couple more ideas on Test First, see http://scaledagileframework.com/test-first/
Integrating at the ART level
After teams develop their stories, the system should be integrated. Separate PI Integration lanes visualize which stories have been integrated already and which are pending integration. This helps make sure you are not accumulating “Integration Debt”. This area should be “WIP Limited” to make sure that at some point we will “stop the line” and force development teams to figure out why integration is lagging behind and focus on solving this crucial problem.
Recommended reading
Additional resources
Here are some other great resources/videos around the Agile framework: