Velocity-Based Sprint Planning

Managing sprint planning involves careful consideration of various factors to ensure a realistic and achievable workload. When employing a velocity-based approach for sprint planning, the challenge lies in determining the appropriate amount of content to pull into the upcoming sprint. This decision is influenced by several key elements that teams must take into account.

Bottlenecks

Identifying and addressing bottlenecks within the sprint is crucial. Bottlenecks can damage the progress of work items, leading to content being blocked. Blocked content can lead to incomplete backlog items by the end of the sprint — those items will be dragged to the following sprint. Velcoty accommodates the reality of dragged items from sprint to sprint. There is no need to adjust the average velocity to reflect the reality of bottlenecks.

Bad-Sprint Good-Sprint Syndrome

The occurrence of a significant deviation between sequential sprints, characterized by one sprint having a lower velocity followed by another with a higher velocity, is known as the bad-sprint good-sprint syndrome. This can be attributed to incomplete items from one sprint being carried over to the next. When planning for a potentially ‘good sprint’, where the velocity is expected to be higher, teams may consider pulling in more content than the calculated average velocity.

‘Bad Sprint’ — ‘Good Sprint’ Syndrome

When transitioning from a ‘bad sprint’ to one anticipated to be more fruitful (‘good sprint’) during sprint planning, it’s essential to recalibrate the expected velocity based on the total velocity of both sprints. The rationale behind this approach lies in the nature of average velocity: while a ‘bad sprint’ tends to underperform relative to the average, a ‘good sprint’ typically exceeds it. To illustrate, let’s consider the following scenario:

• Let’s assume a team’s average velocity stands at 32 story points per sprint, and the team has just concluded a ‘bad sprint’ with a velocity of 17 story points.
• In preparation for the upcoming ‘good sprint’, the team projects a combined expected velocity (of both the previous ‘bad sprint’ and the upcoming ‘good sprint’) of 64 story points (32*2).
• Given the shortfall in the previous sprint (17 story points, compared to the average of 32 story points), we anticipate the forthcoming ‘good sprint’ to have a velocity of 47 story points (64–17). Therefore, in the sprint planning session, we will aim for that number.

Scope Creep Mid-Sprint

Teams may encounter scope creep, where additional items are pushed to the sprint after it has already started. To address this, it’s essential to calculate the average of added content during the sprint. For instance, if a team typically adds 10 story points on average during a sprint with a velocity of 35 story points, they should factor in this additional workload when pulling content into the sprint (e.g. taking less than 35 story points). This means reducing the commitment at the sprint start to accommodate the expected scope creep during the sprint, ensuring a more realistic workload.

Burndown chart indicating content added during the sprint

Unexpected Interruptions Mid-Sprint

Unexpected interruptions during a sprint introduce a recurring challenge for teams. By recognizing that unforeseen events are an integral part of each sprint, teams can confidently base their planning on historical velocity, which naturally incorporates these interruptions. Whether to adjust the team’s commitment during sprint planning in anticipation of these interruptions depends on whether they are estimated as they arise. Take, for instance, the common interruption of a production incident. If the team reflects production incidents as estimated backlog items, thereby increasing the final velocity, it necessitates treating this scenario similarly to the ‘scope creep’ situation discussed earlier. However, if the production incident activity isn’t reflected as an estimated backlog item, there’s no need to change the team commitment at sprint start, as the velocity already accounts for the likelihood of production incidents (as production incidents happened also in previous sprints).

Exceptional Vacations

Regular and ongoing vacation days are already factored into the team’s average velocity. However, when the team encounters exceptional vacation days, it necessitates an adjustment to its velocity. For instance, if we have a holiday of 4 days within a 2-week sprint, we should recalibrate to 60% of the average velocity. Therefore, if the team’s velocity stands at 32 story points, we would consider a velocity of 19 story points (32 * 0.6) for that particular sprint.

Stakeholders’ Items vs Internal R&D Items

Distinguishing between Stakeholders’ Items and Internal R&D Items is crucial within the velocity calculation. While some estimated items are tied to stakeholders’ requirements, others are related to internal R&D activities such as refactoring, addressing technical debt, or maintaining architecture integrity. During the sprint planning phase, when determining our commitment to stakeholders, it’s essential to base this decision on the velocity assigned to the stakeholders, rather than the team’s overall velocity. For instance, if the team typically allocates around 20% of its estimated effort to internal R&D activities, this implies that when making commitments to stakeholders, we should base them on 80% of the velocity. For example, if the team’s overall velocity is 30 story points, then the velocity allocated for stakeholders would be 24 story points (80% of 30 story points).

Dragged Items

A frequent question I encounter from teams revolves around managing sprint backlog items that are dragged from previous sprints. There’s often a notion that splitting a dragged backlog item into two — a completed backlog item (with the effort that was already invested) and an uncompleted backlog item (with the remaining estimated effort) — is the way forward, driven by a desire to both reflect progress and ensure accurate planning. Let’s address these concerns.

• Reflecting Progress: I advocate strongly against splitting stories to reflect progress, and here’s why. Firstly, a backlog item is binary — it’s either done or not. Any attempt to describe a partially complete item damages its value as a cohesive unit representing a full use case. A fragmented item lacks demonstrable value in sprint reviews, as it essentially showcases technical progress rather than functional outcomes. Secondly, envision future scenarios where the team measures the size of a new backlog item relative to this one (relative sizing technique) — splitting breaks the team’s reference point, and prevents accurate sizing.
• Accurate Planning: Now, about planning concerns — our velocity metric accommodates dragged items seamlessly. Here’s where teams often stumble — how can a partially completed item, counted in full, not disrupt planning? The logic lies in our sprint-by-sprint approach. Let’s illustrate with an example. Imagine two stories, each rated at 3 story points, left uncompleted from the previous sprint, totaling 6 story points to carry forward. Suppose the team’s average velocity stands at 30 story points. This includes both the 6 story points of dragged items and the expected new backlog items. As the sprint progresses, we’re likely to complete the dragged items early, alongside additional new backlog items, and probably end the sprint with a few backlog items uncompleted (items that will be carried over to the next sprint). Therefore, the team’s average velocity reflects both the drag from previous sprints and anticipated carryovers of new backlog items into the next sprint. The mathematics of including dragged items as part of the average velocity works, across sprints.

In conclusion, there’s no need to divide the completed portion of dragged items — it’s already accounted for in our velocity, streamlining planning without complexity.

Coding vs Testing

When pulling content into the sprint, we add items one by one, reducing our available commitment by the story points of each backlog item until we reach zero.

I’ve observed a common dilemma in teams that include both developers and QA engineers. Some teams attempt to split the story points of a backlog item between coding and testing efforts, ensuring they don’t take on too many “testing story points”. This approach comes from the fact that most teams have fewer QA engineers than developers. These teams continue pulling backlog items until they believe the total number of testing story points is too high.

The underlying assumption here is that the testing phase is a bottleneck due to the smaller number of QA engineers compared to developers. However, this assumption is often incorrect. Even if there is a bottleneck, the average velocity already reflects it (as what was not tested was not delivered and therefore not part of the velocity). Adding this extra layer of complexity is usually unnecessary and can be counterproductive. Limiting the pulled items due to a perceived shortage of testing resources often reduces the overall delivery throughput of the team.

Boosting Team Productivity: Embracing the Extra 20%

In sprint planning sessions, I encourage teams to commit to an extra 10%-20% of content. This isn’t just to account for unexpected bottlenecks, but also to push the team to challenge themselves to deliver more. A team that continually improves should increase its output over time. If we maintain the commitment rate equal to the delivery rate every sprint, the delivery rate is unlikely to improve.

You might argue that as a team improves, they will finish their committed content earlier and then pull in extra work towards the end of the sprint. However, Parkinson’s Law suggests that work expands to fill the time available. This means the original work pulled in will probably stretch to the end of the sprint, rather than being completed more quickly.

While I encourage teams to challenge themselves by committing to goals that may exceed their average velocity, it’s crucial not to pull in an unrealistic amount of backlog items into the sprint, exceeding approximately 120% of their established velocity. This threshold helps maintain a balance between stretching the team’s capabilities and ensuring a feasible workload. Striking this balance promotes a healthy sprint rhythm where teams can push their limits without compromising on quality or risking burnout. By setting realistic yet ambitious goals within this framework, teams can effectively manage expectations, maintain momentum, and achieve sustainable delivery over the long term.

It’s important to note that teams using time-based effort estimation will eventually hit a ceiling in their improvement. An individual can’t deliver more than 10 days of work in a 10-day sprint. However, if your team uses story points for effort estimation, there’s theoretically no limit to their improvement rate — the ceiling isn’t reached as quickly as it would be with time-based estimation, allowing for greater potential growth in productivity.

Bringing It All Together: Simplified Sprint Planning

Now that we’ve reviewed the factors that might impact our velocity-based commitments, let’s consolidate this into a streamlined approach for sprint planning.

1. Calculate Average Velocity: Begin by calculating the average velocity over the last four sprints. Using an even number of sprints helps mitigate the “bad-sprint, good-sprint” syndrome.
2. Adjust for Scope Creep: Subtract the average scope creep experienced during a sprint from this number. This could be zero if usually there’s no scope creep.
3. Account for Recent Performance: If the last sprint was notably poor, increase your committed velocity to bridge the gap between the bad sprint and your average velocity.
4. Factor in Exceptions: Adjust for any exceptional vacations or holidays. Reduce your commitment proportionately.
5. Increase (a bit) commitment: Add approximately 10%-20% to your commitment allowing opportunities for delivery rate improvement.

With these adjustments, you can determine your sprint commitment. Next, allocate this commitment between stakeholder requests and internal R&D activities.

Example Calculation

Consider a team with an average velocity of 40 story points. They’ve just completed a two-week sprint with only 25 story points delivered. The team usually faces 5 story points of scope creep per sprint and has an upcoming one-day holiday. Additionally, there are two backlog items, each worth 3 story points, that were not completed in the last sprint.

1. Starting Point: Average velocity = 40 story points
2. Scope Creep: Subtract 5 story points for average scope creep = 35 story points
3. Recent Performance: Add 15 story points to account for the bad sprint (40–25) = 50 story points
4. Holiday Adjustment: Reduce by 10% for the one-day holiday (1 day out of 10 days) = 45 story points
5. Increase (a bit) commitment: Add 20% = 54 story points
6. Unfinished Backlog Items: Subtract 6 story points (2 items x 3 story points each) = 48 story points for new backlog items

Thus, the team can commit to 48 story points of new content for the upcoming sprint ((40–5 + 15) * 0.9 * 1.2–6). Divide this commitment between stakeholder requests and internal R&D activities accordingly.

In most cases, when there is no significant scope creep and no exceptional vacations or holidays, the calculation is straightforward. For example, if the average velocity is 40 story points, simply add 20%. This results in a commitment of 48 story points.

By following these steps, teams can plan their sprints more effectively and ensure a balanced workload that considers past performance, expected disruptions, and potential bottlenecks.

Embracing Predictability in Agile: Setting Realistic Expectations

Predictability, the alignment between commitment (at sprint start) and expected delivery (at sprint end), is a crucial metric in Agile. Using a velocity-based approach, our goal should be to achieve 80% (or more) of our commitment. Striving for 100% delivery predictability is unrealistic in software engineering due to the “unknown unknowns” (as highlighted by the Cynefin framework) and other potential bottlenecks in the delivery pipeline, such as dependencies and handovers between silos.

We should set organizational expectations for an 80% delivery predictability, sprint over sprint. Focusing on maintaining a stable delivery velocity is more beneficial. Achieving 80% predictability doesn’t contradict having a stable delivery velocity; in fact, it supports it. By planning for 80% delivery predictability, unforeseen issues and bottlenecks do not damage the average delivery velocity.

Striving for 100% predictability often leads teams to pad their estimates, which can hinder improvement and lead to a lose-lose situation for the organization. Maintaining 80% predictability with a stable velocity provides a solid foundation for healthy roadmap management.

Therefore, a team should be encouraged to pull more story points into the sprint than the average velocity. The sprint boundary, in my view, should not constrain us from achieving more or slow down the continuous flow of delivery. I actively encourage teams to tackle new backlog items, even towards the sprint’s end, even if completion by the sprint’s end seems unlikely. Embracing a continuous delivery mindset over a stop-start paradigm fosters a more efficient workflow. In my experience, this continuous approach results in a higher delivery rate compared to the rigid insistence on completing 100% of sprint backlog items.

Conclusion

A thoughtful approach to sprint planning considers the unique dynamics of the team’s workflow. Addressing bottlenecks, anticipating fluctuations in velocity, expecting items to be dragged between sprints, assuming bottlenecks, and accounting for scope creep mid-sprint are essential strategies for refining the content pulled into a sprint. By understanding and mitigating these factors, teams can strike a balance between ambitious goals and realistic commitments, fostering a more sustainable and effective development process.