‘ba’ – We, the work, and the knowledge are all one.



Team Level

The Team Level contains the roles, activities, events and processes through which Agile teams build and deliver value in the context of the Agile Release Train (ART).

While depicted somewhat separately for discussion, the SAFe team level is an integral 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 organizational model for the artifacts, roles, and processes for the activities of Agile Teams.

Each Agile Team is responsible for defining, building, and testing stories from their Team Backlog. Using common iteration cadence and synchronization, each team aligns with the others in a series of fixed-length iterations, so that the entire system is iterating. Teams use ScrumXP or Kanban to deliver high-quality systems routinely 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 Team Level describes how Agile Teams power the Agile Release Train (ART) as is seen in figure 1. They apply 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 and includes all the roles necessary to build a quality increment of value in each Iteration. ScrumXP roles include the Scrum MasterProduct Owner, dedicated individual contributors, and any SME (Subject Matter Experts) 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 EngineerProduct ManagementSystem Architects/EngineeringSystem TeamShared ServicesDevOps, and anyone else required. Thereby, the team is fully capable of defining, developing, testing, and delivering working and tested systems every iteration (at least).

Figure 1. Team Level


Below are the highlights of the Team level:

  • Iterations – a fixed-length timebox which provides the basic development cadence for Agile Teams building features and components. Each iteration provides a valuable increment of new functionality. Identifying, prioritizing, scheduling, elaborating, implementing, testing, and accepting stories are the primary requirements-management processes at work on the team level.
  • Program Increments (PI) – Teams share common iteration start/stop dates and durations—both the Iteration boundary and the PI boundary—so as to synchronize and integrate with other teams on the ART.
  • Develop on Cadence – 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 on Demand.
  • ScrumXP – is a lightweight process for self-organizing, self-managing, and cross-functional teams of five to nine people to deliver value within the context of SAFe. ScrumXP uses the Scrum framework for project management and XP (eXtreme Programming) technical practices to continuously deliver value.
  • Team Kanban – a lean method that helps teams facilitate the flow of value by visualizing work flow, establishing work-in-process limits, measuring throughput, and continuously improving their process. SAFe teams can choose to operate as ScrumXP or Kanban teams.
  • Built in Quality – practices inspired by eXtreme Programming (XP); which ensures that Software (SW), Firmware (FW), and/or Hardware (HW) solution increments are high in quality and can readily adapt to change.


The team level roles help coordinate and synchronize team level events, through which the Agile Teams build and deliver value in the context of the Agile Release Train (ART):

  • Agile Team – A cross-functional ScrumXP or Kanban team which consists of the Dev Team as well as Scrum Master and Product Owner. This team of five to ten people have the ability and authority to define, build, and test an element (Story or Enabler) of solution value within an Iteration.
  • Development Team (Dev Team) – A small, cross-functional team of developers, testers, and other specialists, that work collaboratively to deliver a vertical slice of functionality. The Dev Team is a subset of the Agile Team.
  • Product Owner (PO) – a member of the Agile Team and is the content authority for the Team Backlog. The PO is responsible for defining Stories and prioritizing the backlog. The PO is the only team member empowered to accept Stories as done.
  • Scrum Master – a member of the Agile Team, the Scrum Master is a servant leader and Agile Team coach. The Scrum Master helps the team to remove impediments, facilitates team events, and fosters an environment for high performing teams.


The Team level uses several events to help synchronize and coordinate activities among teams within the ART:

  • Iteration Planning – an event in which an Agile Team determines the Iteration Goals and how much of the team backlog they can commit to during an upcoming iteration. The number of stories and enablers selected is based upon team capacity.
  • Iteration Review – a cadence based event where the team inspects the increment at the end of the Iteration and adjusts the team backlog based on feedback. All work done during the Iteration is demonstrated during the Iteration Review.
  • Iteration Execution – is how the Agile Team develops an increment of effective, high-quality, working, tested system within the timebox. During execution, an Agile Team will meet each day for a 15 minute timeboxed meeting called a Daily Standup Meeting (DSU). The goal of the DSU is to synchronize, review progress, and identify issues.
  • Iteration Retrospective – An event held at the end of the Iteration where the Agile Team reviews their practices and identifies ways to improve. The retrospective is based upon qualitative and quantitative information presented during the Iteration Review.
  • Backlog Refinement – an event held once or twice during the iteration to refine, review, and estimate Stories and Enablers in the Team Backlog. The event is attended by the Agile Team and any necessary subject matter experts.
  • Innovation and Planning (IP) Iteration – An iteration which provides the teams with an opportunity for exploration and innovation, dedicated time for planning, and learning through informal and formal channels. In the case where a Release is on the PI boundary, teams perform final system verification, validation, and documentation.


The following team level artifacts help describe the business and technical value delivered by the teams during each Iteration and PI:

  • Story – Stories carry the Customer’s requirements through the value stream into implementation. The teams use stories to deliver value within an Iteration, and the Product Owner has content authority over their creation and acceptance.
  • Enabler stories – like any Story, must fit within an Iteration. Although Enablers may not require the user voice format, their acceptance criteria clarifies the requirements and support testing.
  • Iteration Goals – an output of the Iteration Planning event, they are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They help ensure alignment with the PI Objectives.
  • Team Backlog – consists of user and enabler stories, most of which are identified during PI Planning and Backlog Refinement meetings.
  • Team PI Objectives – are a summarized description of the specific business and technical goals that an Agile Team intends to achieve in the upcoming Program Increment (PI).

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.


Last update: 19 June, 2017