Insights: Capacity Planning of a Team in a SAFe Environment

Introduction

Our team has been part of a SAFe organization for about a year. During this time, we have encountered various challenges and would like to share our experience with you on how we calculate our capacity for PI Planning.

As an independent Scrum team, you can be quite flexible when it comes to planning your next iterations. However, this changes when agile development is scaled through an organization involving multiple teams in product development.

The framework chosen to support scaled product development in our company is called SAFe (Scaled Agile Framework).

In SAFe, one of the most relevant events that aligns development teams and stakeholders to a shared mission and vision is PI (Planning Interval) Planning, which is a cadence-based event for the entire ART (Agile Release Train). Therefore, the collaboration of multiple teams needs to be considered.

Our ART consists of component teams which are mostly stream aligned or maintain complicated subsystems. When Team A requires the implementation of a Product Backlog Item (PBI) from Team B in advance to finish their work, managing these dependencies becomes crucial. Otherwise, the whole plan could collapse, making the achievement of the committed scope unfeasible.

Because of the current ART setup, we manage dependencies in a way that Team B would implement their story at least one Sprint earlier (e.g., in Sprint 3), so that Team A can start their story as planned (e. g. in Sprint 4). However, there is a risk that both teams may not achieve their forecasts due to unplanned work, unexpected support tasks, or higher prioritized bugs in the Product Backlog. Thus, we want to align the plan across the teams and minimize the amount of desynchronized work. In this regard, let us have a closer look at how capacity planning for the upcoming PI may help the teams provide a reliable forecast while staying adaptive with respect to business needs.

Capacity planning

To delve deeper into the matter of capacity planning, we would like to share the learnings we have gathered in our team so far. We have observed the following patterns occurring in almost every iteration that have an impact on Sprint scope. These occur during the Sprint Review when the outcomes are presented to stakeholders, or sometimes in the Retrospective when the team generates ideas on how to improve their ways of working, Definition of Done (DoD), and experiments with new ideas. Changes are then recorded as new items and added to the Product Backlog. By doing this, we emphasize the importance of embracing changes. Otherwise, we would lose momentum and could only plan the newly added Product Backlog Items for the next PI, which commonly takes three months. Therefore, we started to experiment with a buffer for these kinds of changes and considered it in every Sprint. We took the same approach for support tasks, which began to impact the team’s velocity.

The good thing about this approach is that we generally work with empirical data, which serves as the foundation for our plans and predictions. The team has had a positive experience with planning work by measuring story points not only for the known refined Product Backlog Items but also for support tasks. The calculation is as follows:

Average team velocity — average unplanned tasks = available velocity

In the last few PIs, the share of unplanned tasks in our team was around 30–40%. This means if your average velocity is 100 story points, you should only plan 60 to 70 story points for a Sprint.

If you haven’t gathered empirical data so far and are about to start with the first PI Planning, we recommend considering at least 50% of your available capacity as a buffer. We also suggest adding an additional buffer to Sprints during vacation time to reduce the risk of overcommitment.

Hence, your plan for a PI could look like this:

In the above picture, you can see the burn-up chart made during PI Planning. The business value has not been entered by the business owners yet. You can clearly see that we planned our entire available velocity/capacity but still the forecast (dotted green line) predicts that the team will deliver the scope several Sprints before the end of the PI because of our buffer.

Summary

We have shared our experience on capacity planning for a PI. Adding a buffer during PIP, using empirical data and orchestrating the dependencies among the teams has helped our team to better anticipate and accommodate changes and become a reliable partner in the ART.

Authors

Oksana Briese, Scrum Master at Mercedes-Benz Tech Innovation

Marco Kranz, Product Owner at Mercedes-Benz Tech Innovation