Planning: Velocity-Based vs. Formula-Based

Effective sprint planning is crucial for agile teams aiming to achieve optimal productivity. Two primary methodologies, the formula-based approach, and the velocity-based approach, are commonly employed to determine the amount of content a team can deliver, and based on that pull an appropriate amount of backlog items into a sprint.

In this post, we will review both methodologies and explore why the velocity-based approach is superior in almost every aspect. Furthermore, we will take a deep dive into the characteristics of sprint commitment based on the velocity approach.

Delivery Rate by Formula-Based Approach

Calculating the expected delivery rate in the formula-based approach, teams carefully calculate the available working days by factoring in team size, sprint duration, and deducting planned vacation days. On top of that, a buffer, often determined by a subjective magic number, is then applied to account for various activities that are done during the sprint but are not reflected as estimated backlog items, such as release activity, regression testing, Scrum meetings, design meetings, weekly meeting with the manager, production incidents, sickness days, etc. However, this approach often requires a lot of data collection and a lot of guesstimations due to the unpredictable domain of software engineering, which is characterized by unknown unknowns (as defined by the Complex domain in the Cynefin model).

Teams that embrace this method not only waste precious planning effort but also frequently find themselves overcommit or undercommit due to the guesswork and buffers involved in this method.

Formula-Based Approach: Step by Step

Let’s delve into a typical sprint planning scenario using a formula-based approach.

1. Total Working Days Calculation: The team calculates the total working days in the sprint. Multiplying the number of team members by the total days in the sprint.
2. Accounting for Vacations and Holidays: Each team member reports their vacation days, which are then subtracted from the overall number of working days. Holidays are considered as well.
3. Buffer for Unestimated Knowns: An allocation is made for unestimated knowns — activities occurring during the sprint but not reflected in estimated backlog items. This includes various meetings (design, knowledge transfer, weeklies, Scrum), release activities, etc.
4. Buffer for Known Unknowns: An allocation is made for unestimated known unknowns — activities we know will occur during the sprint but we don’t know beforehand their specifics (e.g. we know we usually have 2 production incidents in a sprint, but we don’t know which incident exactly will occur). This includes bugs, production incidents, sickness days, etc.
5. Buffer for Unknown Unknowns: An additional buffer is used for unknown unknowns such as technology barriers discovered during implementation, unexpected workflow bottlenecks, unexpected dependencies, adjustment of backlog items by the stakeholders during the sprint, etc.

With the remaining capacity in mind after accounting for the above, backlog items are pulled into the sprint.

While this formulaic approach puts confidence in planning, it’s full of hidden assumptions and pitfalls. For instance, the predetermined amount of buffer, both for known and unknown factors, is often based on guesswork rather than concrete data. Furthermore, those buffers tend to remain fixed across sprints, failing to adapt to the evolving realities of the team.

An Example

Consider a team containing 5 developers operating within a 2-week sprint cycle. Here’s a breakdown of the calculations often undertaken:

1. Total Working Days Calculation: The team calculates the total working days in the sprint. In this example, we have 50 working days (5 developers x 10 work days in a sprint).
2. Accounting for Vacations and Holidays: 2 of the team members take 3 vacation days each. In this sprint, there are no holidays. We remain with 42 working days (50–2x3).
3. Buffer for Unestimated Knowns: the team believes that their design meetings, knowledge transfer meetings, weeklies, Scrum events and release activities take around 1 workday per team member. We remain with 37 working days (42–1x5).
4. Buffer for Known Unknowns: the team usually has 2 production incidents in a sprint, which take around half a day for each. Moreover, they incorporate ~5% buffer for unexpected sickness days (let’s say 2 days of sickness in the team). On top of that, 2 days are allocated for each team member for defect fixing. We remain with 24 working days (37–2x0.5–2–2x5).
5. Buffer for Unknown Unknowns: the team decides to take an extra 20% buffer for technology barriers discovered during implementation, unexpected workflow bottlenecks, unexpected dependencies, and adjustment of backlog items by the stakeholders during the sprint. We remain with 19 working days (24–0.8).

With the expected delivery rate of 19 working days in mind, backlog items are pulled into the sprint. Please note that it doesn’t mean the team should pull, at sprint start, 19 working days of backlog items. This number should be adjusted (increased or decreased) based on various factors such as scope creep mid-sprint (backlog items that will be pushed after sprint start), bottlenecks (that might require working on more items without finishing them), etc.

The Downside of Using Buffers

When planning sprints using formula-based, we saw how teams include buffers in their commitment calculations to account for unestimated knowns, known unknowns, and unknown unknowns. Let’s look at some of the downsides of using such buffers:

• None Adaptive: The buffers tend to be fixed, meaning we will usually use the same buffers sprint over sprint. In our example, the team took a 1-day buffer for the unestimated knowns (e.g. meetings). If some of the meetings get shorter over time, most probably no one will change that buffer.
• Guesstimation: A large portion of the buffers is based on guesstimation. For example, 20% unknown unknowns. It is extremely hard to estimate the unknown unknowns section, even in retrospect.
• Parkinson’s Law: 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, using all buffers, rather than being completed more quickly, as teams may not feel the pressure to push their limits and optimize their performance.

The Downside of People-Based Calculation

The formula-based approach relies on the basic calculation of multiplying the number of team members by the number of work days in the sprint. In our example, we took a team of 5 developers. Calculations get complicated in case there are people with different domains on the team. For example, suppose our team has 1 team leader, 5 developers, 2 QA engineers, and one architect. Several questions emerge regarding how to calculate the total working days in a sprint:

• Team Leader: Should the team leader be counted as contributing 50% of the time due to their leadership responsibilities?
• QA Engineers: Should QA engineers be included in the calculation? While they contribute to quality, they might not be directly involved in delivery. Yet, without QA engineers, testing efforts would fall on the developers.
• Architect: Should the architect be counted? If there were no architect, some of the architecture work would shift to other team members.

Another challenge is accounting for different skill levels. Among the 5 developers, there might be 2 junior developers and 3 senior developers. Should they be counted equally? If not, reducing vacation days for juniors versus seniors adds another layer of complexity, as their contributions have different weights.

Attempting to break the team down into individual capacities and then summing them up to determine overall team capacity is nearly impossible. This method is full of complications and often leads to inaccurate planning and misallocation of resources.

In Conclusion

The formula-based approach relies on buffers that are fixed and based on guesstimation, as a strategic response to the unpredictable nature of the software engineering landscape. This approach is fueled by a desire to mitigate the impact of unknowns and unestimated activities, resulting in sub-optimal planning (either under-commitment or over-commitment).

Moreover, the attempt to summarize the individual capacities, in order to achieve the overall team capacity, is complicated and prone to errors. As a result, most often team uses hidden assumptions in the calculation (e.g. team leaders are 50%, none-developers are not counted or partially counted, and juniors and seniors are counted the same) which results in an inaccurate team capacity.

Delivery Rate by Velocity-Based Approach

Alternatively, the velocity-based approach, also known as yesterday’s weather approach, relies on historical performance data. Teams analyze delivery numbers from the last few sprints, computing an average as a reliable indicator of future team velocity. Instead of relying on fixed buffers, guesstimations, and breakdown into individual capacity, the velocity-based formula is a reliable and straightforward calculation that reflects reality. Teams operating within the same parameters — consistent team structure, same organization, same technology, and same software modules — should exhibit predictability in their type of activities sprint after sprint. This method minimizes the impact of unestimated activities and unknowns, fostering a more reliable and efficient planning approach.

At its core, velocity encapsulates the essence of what a team can achieve within a sprint based on what it achieved in previous sprints. It incorporates not only the backlog items that were carefully estimated but also, perhaps even more importantly, the quantity of activities that were not explicitly accounted for, but happened during the sprint. This is where the magic of velocity truly shines.

The velocity approach is so powerful as a result of its focus on actual past estimated delivery and the activities that it intentionally excludes. To understand this statement better, let’s see what is included in the velocity and what isn’t.

The activities that velocity includes are activities that are estimated, some are known and some are unknown:

1. Estimated Knowns: backlog items pulled into the sprint at sprint start, and delivered by the end of the sprint.
2. Estimated Unknowns: estimated backlog items pulled into the sprint after sprint start (this is why they were unknowns). The average velocity includes those unknown estimated activities as those kinds of activities occurred in previous sprints as well. An example of such activities is bugs (in case the team assigns effort estimation for bugs). Another example is a change in the design of an existing backlog item during the sprint, implying a change in its effort estimation.

The activities that velocity excludes are activities that are not reflected as backlog items or are not estimated, but usually occur every sprint:

1. Unestimated Knowns: meetings, software release activity, lunch breaks, coffee breaks, company events, etc.
2. Unestimated Unknowns: unexpected vacations, sickness days, etc.

The predictability of unknown activities (whether estimated or not) and unestimated activities is a cornerstone of velocity’s effectiveness. Whether it’s vacation days, sickness days, meetings, release activity, bugs, production incidents, or ever-essential coffee breaks, these elements exhibit a consistent pattern across sprints. As a result of their consistent pattern, the velocity reflects them either explicitly (accounting for those items as estimated delivery) or implicitly (not reflecting them as a delivery, but understanding they consume team efforts).

The velocity holds a dynamic quality, tailored to suit the unique essence of both the team and the organization. Should there be changes in the effort allocated to unestimated activities within the organization as time progresses, the velocity shall mirror these changes. For instance, consider an organizational choice to incorporate a three-hour technology presentation meeting into every sprint, involving all team members. Following a sprint or two, the velocity will naturally recalibrate (shown as a reduction in velocity as less time is available for estimated activities).

Consequently, the beauty of velocity lies in its simplicity. Rather than dealing with complex formulas attempting to account for every conceivable activity, per team member, and reduce it from the total team capacity, teams can simply observe their team velocity based on previous sprints as a prediction for the coming sprint.

A Story

In one of my roles as VP of R&D, I once faced a critical request from our CEO: provide a clear picture of each team’s delivery rate for product management backlog items. Given that our teams were using a velocity-based approach for their sprint planning it seemed straightforward at first. However, the challenge was revealed when the CEO requested an explanation for the gap between delivery days (velocity) and the total available working days. This led to a complicated task: presenting the exact number of days invested in all types of the teams’ activities. Essentially, this involved guiding the CEO through the journey from the total number of working days to the output of delivery days (velocity), while deducting all the additional activities that fell outside the scope of product management backlog items handled by the teams.

The process involved a significant amount of guesstimation. We carefully categorized and estimated the time spent on activities such as release activities, Scrum meetings, weekly meetings, architectural design discussions, HR events, production incidents, sickness days, context switches, waste due to non-ready backlog items, lab maintenance, and other non-backlog-related activities. On top of that, we struggled with the dilemma of which people to include as part of the working days' calculation — specifically none developers such as QA engineers, architects, etc. Even with the luxury of knowing the actual velocity as our end goal, constructing this formula proved challenging. It emphasized the difficulty of accurately predicting team output using a formula that relies heavily on estimated variables. This experience highlighted the pitfalls of a formula-based approach — while it may offer a structured framework, its reliance on assumptions and estimations can undermine its reliability when attempting to forecast future outcomes.

White Board Thoughts on Building the Transition from Working Days to Velocity

Conclusion

In the dynamic landscape of software engineering, where uncertainties are the norm, the velocity-based approach emerges as a robust and effective strategy for sprint planning. By leveraging past performance data, teams can enhance predictability and streamline their planning processes, ultimately leading to more successful and achievable sprint goals.