Iteration Planning, Options for Success

The Scaled Agile Framework (SAFe) has become one of the more popular agile frameworks for large enterprises. Over the past 10+ years, Scaled Agile has adapted the framework to include several helpful development practices like DevOps, Lean-Agile Leadership, and Business Agility. Yet some of the original guidance remains in place. There are some parts of SAFe that simply aren’t helping teams adopt good agile practices. This article focuses on iteration planning options that are a part of the PI Planning process in SAFe.

In SAFe, teams plan 4 – 6 iterations per planning increment (PI). Most teams start with a 2-week iteration cycle. Given a set of work items, the team must decide how much work they will complete in their first several iterations. As teams are learning to write user stories and estimate them, they often struggle with how to determine what amount of work the team can complete in each iteration. There are a few aspects to consider here. First the team members should account for any time off they have scheduled during the iteration. Team members should record planned time off in increments of half or whole days. In addition to providing information about the team’s capacity, team members know each other’s plans for time out of the office. The time a team has available to work during an iteration is called their capacity. A team with 8 team members, working in 2-week iterations has a maximum capacity of 80 days. If there is a corporate holiday that falls within an iteration, the team’s capacity would be 70 days. That’s the easy part to calculate.

Calculating Velocity is Difficult, don’t SWAG it.

Next, the team is instructed to calculate their velocity. Velocity is a measure of the number of story points a team can deliver during their iteration. New agile teams don’t know really their velocity until they have completed several iterations. The guidance to calculate velocity that SAFe gives for new teams is to allow a point to every full-time developer and tester for every day they are working in the iteration. A team with 8 fulltime developers and testers would assign a velocity of 80 points for each 10 day iteration. You can see how quickly someone could associate time available or capacity to velocity.

Another challenge is that teams will remove 2 days from their 10-day cycle as days for planning, demoing and a retrospective, assuming that no productive work will be accomplished on the start and end of an iteration. This practice leads to several poor applications of velocity, including assigning stories to a person based on their skillset. Some teams write stories based on development phase instead of small units of business value. When it comes time to determine how many stories a team can accomplish during their iteration, developers are assigned stories that need to be coded, testers are assigned stories that need to be tested. Worse yet, analysis is scheduled in one sprint, development stories are scheduled in the next iteration, followed by testing for that story to be scheduled in the third iteration. This phenomenon is sometimes called Scrummerfall, one of the pitfalls of combining Scrum and Waterfall processes.

Agile Planning Starts with Good User Stories.

There is another approach that can be helpful to teams planning their first PI. Let’s assume that a new agile team has worked closely with the Product Owner and other subject matter experts to create a set of work items called user stories. The user stories have well defined acceptance criteria, and the team shares a common understanding of the work to be done. The team members should record their capacity for the next several iterations. It isn’t important for the team to size their user stories at this point. It may be helpful for the team to review the stories to determine if any of them are too complex to be done in less than a week. Any user story that the team feels will take more than a week should be reviewed to determine how best to split the story – think vertical slices.

The next step would be for the team to set the user stories in order from 1 – n that they will take on in each iteration. Once the list of stories is ordered, the team should look to establish groups of the work they will attempt in each iteration. When discussing the groups of work the team might want to discuss the complexity of the effort needed to complete each work item.

Assess relative complexity, not the story points.

Beware of the overall complexity in one iteration. Taking on a few stories that are complex is often quite challenging. The better choice is to plan for a set of stories with low complexity and one more complex story in an iteration. It is important to be mindful that everyone is learning while they are working and give sufficient space and grace for the learning to happen.

Once the team has finished setting their stories into iterations, they should take one more review of the sets of stories and check for dependencies or any questions that should be resolved before the start of their first iteration. It’s best not to have dependencies within an iteration. If you find that there are dependent stories, try to separate them by a full iteration.

The first time a team works through the planning process for a planning increment (PI) might require 2-3 days of focused effort. Taking the time to learn to plan effectively and efficiently will save time. It will also help alleviate frustration by the team and their business partners. At this point in the team’s experience, it is more important for the team to gain domain expertise and learning to work together than it is to hit any particular velocity metric.

Time for a Retrospective?

After the team completes a few iterations, they have enough experience working with user stories to reflect on the work they completed and determine the relative size of it. This is a good time for the team to hold a retrospective with the goal of establishing the team’s story sizing and velocity.

In the retrospective, review each of the user stories assessing the relative complexity of the work that was necessary to complete the story. Start with finding the least complex user story and assigning it a value of 1. All other stories are then sized by comparing them to the smallest story. As an example, a story that is more than twice as complex as the smallest story is set at 3 points.

Using this approach, most teams cannot complete a story size greater that 8 in an iteration. Now the team has some empirical evidence to support their velocity and can use it to capture their average velocity over 3 – 5 iterations. The 3 most recent iterations are the better indication of the team’s velocity. Consider throwing out any outlier iterations such as the Innovation & Planning (IP) iteration when calculating velocity.

This iteration planning option may provide for better outcomes for the new agile team and the business area they support. As for the ART and business partners, allowing the team to learn and form during their first PI will provide an opportunity to build trust between the team, across the team of teams and their business partners. Consider allowing the team to provide a PI plan that doesn’t have story points or a velocity for their first PI. The end result should be a well-formed team that can provide predictable results in the future.