We, the work, and the knowledge are all one.
Team Level Abstract
While depicted somewhat separately, the SAFe Team Level is part of the Program Level. All SAFe teams are part of one Agile Release Train (ART)—the central construct of the program level. The team level provides an organization, artifact, role, and process model for the activities of Agile Teams. Each Agile Team is responsible for defining, building, and testing stories from their Team Backlog in a series of fixed-length Iterations, using common iteration cadence and synchronization to align with other teams, so that the entire system is iterating. Teams use ScrumXP or Team Kanban to routinely deliver high-quality systems and produce a System Demo every two weeks. This ensures that all the different teams on the ART create an integrated and tested system that stakeholders can evaluate and respond to with fast feedback. The system demo creates a routine “pull event,” which pulls the effort of the different teams to a specific point, bringing forward the hard work of integration and testing that phase-gated models often leave until too late in the life cycle.
The Team Level describes how Agile Teams power the Agile Release Train (ART). They apply SAFe ScrumXP or Team Kanban, along with the Built-in Quality practices that help ensure a quality end product. Each team has five to nine team members (ScrumXP) and includes all the roles necessary to build a quality increment of value in each Iteration. ScrumXP roles include the Scrum Master, Product Owner, dedicated individual contributors, and any specialty resources the team needs to deliver value. Team Kanban roles are less rigorously defined, though many SAFe Kanban teams implement the ScrumXP roles as well.
Each team is supported by the program personnel, including the Release Train Engineer, Product Management, System Architects/Engineering, System Team, Shared Services, DevOps, and anyone else required. Thereby, the team is fully capable of defining, developing, testing, and delivering working and tested systems every iteration (at least).
Program Increments and Iterations
Teams share common iteration start/stop dates and durations—both the Iteration boundary and the Program Increment (PI) boundary—so as to synchronize and integrate with other teams on the ART. Each PI begins with the teams participating in PI Planning, where they build Team PI Objectives—which are aggregated to Program PI Objectives—that help guide the teams during the iterations.
Teams plan and execute two-week timeboxed iterations in accordance with agreed-to Iteration Goals. Each iteration provides a valuable increment of new functionality, accomplished via a constantly repeating pattern: Plan the iteration, commit to some functionality, execute the iteration by building and testing Stories, demo the new functionality, hold a retrospective, and repeat for the next iteration. At the end of each iteration, teams also support the System Demo, which is the critical integration point for the ART. In larger Value Streams with multiple ARTs, teams also support the Solution Demo, where the entire solution from multiple ARTs comes together to be integrated and tested in its entirety.
The Innovation and Planning (IP) Iterations provide the teams with an opportunity for exploration and innovation, dedicated time for planning, retrospecting, and learning through informal and formal channels. And in the case where the Release is at the PI boundary, teams perform final system verification, validation, and documentation. In order to provide a buffer, teams don’t plan stories for the IP iteration, so each PI is planned at less than 100% utilization. This increases flow, throughput, and delivery reliability.
The PI timebox is used to aggregate larger, system-wide functionality into valuable and evaluable program increments. The functionality can be released at the PI boundary, or that can happen more frequently. Programs should Develop on Cadence and Release Any Time.
Number of Iterations per PI
SAFe divides the development timeline into a set of iterations within a PI. The Big Picture illustrates how a PI is initiated by a PI planning session and is then followed by four execution iterations, concluding with one innovation and planning iteration. This pattern is suggestive but arbitrary, and there is no fixed rule for how many iterations are in a PI. Experience has shown that a PI duration of between 8 and 12 weeks works best, with a bias toward the shortest duration.
Stories and the Team Backlog
The teams use stories to deliver value, and the Product Owner has content authority over their creation and acceptance. Stories carry the Customer’s requirements through the value stream into implementation. The Team Backlog consists of user and Enabler stories, most of which are identified during PI planning, when Product Management presents the Vision, Roadmap, and Program Backlog. Identifying, prioritizing, scheduling, elaborating, implementing, testing, and accepting stories are the primary requirements-management processes at work on the team level.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update 19 October 2015