Six SAFe Practices for ‘S-Sized’ Teams

by Juha-Markus Aalto, Director Product Development, Qentinel Group

The Scaled Agile Framework (SAFe) has been designed to tackle the challenges of ‘M–XXL’ (medium to extra, extra, large) sized programs. Such programs consist of several agile teams with approximately 50 to 100 people, or even up to hundreds or thousands of practitioners.

Are Scrum and Kanban Enough?

But what about ‘S-sized’ (small) development organizations with just one or a few teams, is there anything in SAFe for them? Or is Scrum and Kanban, just enough?  The answer of course is, it depends. Please read on to find out what those things are.

If a pure software team mainly works on short programs, Scrum or Kanban would seem to be the way to go. However, while a full-scale use of SAFe practices, roles, and events wouldn’t make sense for an ‘S-Sized’ project, a small team can certainly benefit from selected SAFe practices, at least under one of the following situations:

Strategic Software Product with a Long Lifespan
The longer the lifespan of the software product, the more important it is to link software development explicitly to the strategy of the enterprise. Scrum provides little support for linking such development to the longer-than-sprint timespan of strategic goals.

Dependencies with Multiple Non-Software Development Teams
It’s common for a company that has a relatively small software team to develop solutions for other teams for integration. For example, software teams face this situation in a hardware or services company which has a decent portfolio of products but just has a moderate amount of software assets. Software companies whose product is heavily tailored for each customer, through delivery, have this multi-project challenge, too; all the dependent teams need to sync and agree on priorities and plans.

Necessity to Invest in Long Term Capabilities like DevOps
Intense focus on delivering the next set of user stories, sprint by sprint, may result in great products, but it’s all too easy to forget about investments in the team’s own capabilities. We can all probably agree that investing in DevOps capabilities is worthwhile to achieve higher quality and faster time to market. However, becoming a true DevOps team doesn’t happen overnight. It requires planning and executing, as you would do for any project. Changing the development technologies, or modernizing the software architecture, are other examples of long term capability investments that are in fact, true projects.

Expectation to Scale From ‘S’ to ‘M’ Size
If a startup (a new business, or internal business unit) has a strong projection for growth, it makes sense to prepare for it upfront, and use agile approaches that scale when needed. But, unless the foundational capabilities have been built from the ground up, scaling can be painfully slow, difficult, and challenging.

Applying Six SAFe Practices for S-Sized Teams

There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the following six practices of SAFe to deal with them more effectively.

Figure 1. Scaled Agile Framework with six practices for S-Sized Teams

1. Strategic Themes

Companies big and small need a strategy to be successful. It’s crucial to understand how a company’s products create value—how they affect processes and the concrete benefits that customers gain. Product quality and user experience are equally important for long term success. In additi­on to product strategy, a software development team needs to have an idea of how to continuously improve its engineering capabilities to increase productivity and competitiveness.

While SAFe does not offer explicit tools to identify and build the strategy, it does have Strategic Themes—these are the business objectives that connect the team’s portfolio to the strategy of the enterprise.

I’ve successfully used strategic themes during sprint (iteration) planning to help ensure that the team works on strategically relevant items. Some tools, such as Visual Studio Team Services (VSTS), allow the tagging of work items with ‘theme’ keywords, which further helps analyze backlog items against strategy. If a strategy exists, the extra step to identify the strategic themes requires minimal effort.

2. Program Epics

Scrum teams typically interpret ‘epics’ just as really big user stories that don’t fit in one sprint. SAFe defines epics as “initiatives significant enough to require analysis, using a lightweight business case and financial approval before implementation.” The requirement to prepare a business case is not the point here, rather, it’s to ensure that an epic is something that creates significant value and is feasible.

SAFe contains a rich hierarchy of epics to ensure sufficient scaling: Portfolio Epics, Large Solution Epics, and Program Epics. Portfolio and large solution epics are not relevant for small-scale development, but program epics are. Moreover, when a team works on a program epic linked to a strategic theme, the team’s efforts contribute to something valuable and are aligned with the strategy of the company.

Epics are useful for an ‘S-sized’ team. They describe the ongoing key initiatives, those proposed by its stakeholders, or those invented by the team itself. Software teams should also have some enabler epics in their backlog in addition to business epics, to improve architecture or DevOps capabilities.

As “significant enough initiatives” tend to require significant investments of people, a lightweight business case is recommended for each epic before determining its approval for implementation or rejection. This process is particularly useful when the team has several stakeholders and each initiative’s priority and capacity needs to be understood to make tradeoff discussions meaningful.

3. Program Kanban

SAFe uses kanban systems to manage initiatives at the portfolio, value stream and program levels. The program level is sufficient for an S-sized team, and it’s particularly useful if the team has several stakeholders offering their own epic proposals for implementation.

SAFe’s Program Kanban provides a simple and transparent process for capturing, analyzing, approving, and tracking epics. Completed epics will have passed through the following states: Funnel, Review, Analysis, BacklogImplementing and finally Done. For an S-sized team, the process to study epics can be extremely lightweight. But these logical steps should be present anyway, so the Product Owner will know that the team can create the most value for the next time. Managing the key initiatives, as epics, in the program kanban requires only moderate effort but offers transparency to the team’s priorities at the program and portfolio levels.

4. Features

Feature is not really a part of the core definition of Scrum; there are just product backlog items. Many Scrum teams borrow ‘user stories’ from eXtreme Programming (XP) and label big stories as ‘epics’ and bunch related stories together as ‘themes.’

SAFe defines a feature as “a service provided by the system that addresses one or more user needs.” Features elaborate epics and are defined by their benefits and acceptance criteria. Features are exactly what they sound like—the main functional characteristics of the proposed product. It can be difficult to explain the team’s plan and progress to customers, dependent projects, or to management through user stories alone. But features, as defined in SAFe, serve that purpose well. Their size is suitable and understandable, versus user stories, which tend to become too small and numerous.

What makes features particularly useful is that they’re sized to fit in one PI. That makes them concrete deliverables, facilitating clear communication with stakeholders.

5. PI Planning

Traditional Scrum teams work in a sprint cycle, which is where the planning and execution of work occurs, with two weeks being the most popular duration. More often than not, Scrum teams provide true visibility into their plan for just the next sprint, along with the backlog, which hints at the order in which the user stories might be implemented. Different variations of PowerPoint and Excel roadmaps are typically used to address the need for longer-than-the-next-sprint visibility. Backlog tools can help plan stories for future sprints, and some provide forecasts based on the team’s velocity and the order of the backlog items.

Program Increment (PI) in SAFe is “a cadence-based interval for building and validating a full system increment, demonstrating value, and getting fast feedback.”  The duration of a PI is typically eight to twelve weeks, or four to six sprints of two weeks. The last sprint of the PI is the Innovation and Planning (IP) iteration, which will be discussed as the sixth next.

Just as there is sprint planning in Scrum, SAFe provides a planning practice for these super-sized iterations, known as PI Planning. I have facilitated SAFe PI Planning, more or less by the book, for ‘S sized’ teams. The planning horizon of eight to twelve weeks is short enough for useful planning and long enough for a team to achieve something really valuable: a set of potentially releasable features. The PI Planning event is a good use of time for all participants. The team gets an update of the ‘bigger picture’ from the business, which includes the vision and priorities, and develops an Agile plan. The stakeholders can contribute to planning directly. They will also get an overview of all the work that the teams will do during the PI. For an ‘S-sized’ team, the PI Planning event can be condensed into one long day, so that the investment of time is commensurate with the benefits.

6. Innovation and Planning Iteration

Thomas Edison described his innovation approach as “one percent inspiration and ninety-nine percent perspiration.” In other words, innovations require time and hard work, not just a creative mind. In ‘never ending’ continuous product development, there’s a risk that a team just executes sprint after sprint without taking a break and becomes exhausted. Sprints tend to be hectic, and for an S-sized team, it’s likely to be harder to find time to work on some more risky, seemingly lower priority, yet innovative ideas.

SAFe doesn’t have any ‘silver-bullet’ solutions to magically release lots of time for developers to innovate like Edison. But its IP Iteration, at the end of each PI, is something that teams should appreciate. No stories are planned for this sprint, however, it’s an opportunity to do some final system integration and testing activities, such as performance or security testing. It’s also where the Program-level retrospective, known as the Inspect & Adapt (I&A) is held. During the I&A, the achievements of the PI will be demoed to stakeholders, followed by a retrospective and problem-solving workshop. The IP iteration is also where we plan our next PI. But as the name suggests, the IP iteration is the time for innovation, this is where some teams do a ‘hackathon’ or work on innovations or improvements in infrastructure, refactor code or improve architecture. And last but definitely not least, the team can have a break from the hectic pace of software deliveries. Part of the break can be used for competence development, as an example.


Scrum and Kanban by themselves can be just enough for S-sized teams. However, there are at least four circumstances that I’ve found that using select SAFe practices, along with Scrum or Kanban, is more effective:

  • Strategic software product with a long lifespan
  • Dependencies with multiple non-software development teams
  • Necessity to invest in long term capabilities like DevOps
  • Expectation to scale from ‘S’ to ‘M’ size

There are ways to handle these four cases with pure Scrum or Kanban, but experience suggests that it’s better to apply the following six practices of SAFe to deal with them more effectively:

  1. Strategic Themes shortlist the portfolio’s strategic priorities and helps the team align with them.
  2. Program Epics define the valuable key initiatives that the team needs to focus on, so that they can meaningfully prioritize their backlog.
  3. The Program Kanban shows the priorities and status of epics for the stakeholders.
  4. Features elaborate epics, thus providing a common language for the team and its stakeholders. And Features are sized so that each fit in a single PI.
  5. PI Planning happens on a cadence, building a shared understanding of priorities and goals for the next eight to twelve weeks (depending on the chosen cadence).
  6. The Innovation and Planning (IP) Iteration held at the end of each PI gives the team a well-deserved break from the urgent and allows it to spend some time on innovating and developing its capabilities.

About the Author

Juha-Markus Aalto leads product development of digital services at Qentinel. He has made several contributions to the Lean and scalable requirements model of SAFe and has implemented an XXL sized Lean-Agile transformation program when he worked at Nokia Corporation.