None of us would hire a builder to build our dream home without estimating its cost and when we could move in. In much the same way, no matter how hard I’ve tried, I’m yet to find an executive whom I respect who will let me build a large software system without estimating its cost and completion.
Fortunately, in the last 30 years we have learned a lot from our experiments with project management (agile scrum), estimation (size, not effort) to develop estimations that help us build software systems relatively close to budget and schedule - ones that we can be proud of and delight our customers.
This is a high-level discussion about how I leverage agile velocity to support agile teams under my leadership in building software systems, without death marches.
Velocity is the average amount of work performed by a software engineering team within a set period; nowadays, most scrum teams practicing agile employ two-week sprints, and we associate these teams’ velocity with the average amount of work they complete within a 2-week sprint. Notice that the focus is on size, not time, and on the team rather than the individual. Team velocity enables software engineering groups to estimate large systems using a collective understanding of the size of each of its parts, integrating the entire team’s skills, experience, and collective understanding of these systems’ complexity and uncertainty. Although it might tempt managers to focus on individual velocity, my experience has taught me that this is a fool’s errand that leads to no productivity growth; in agile, it’s always best to focus on the team instead of individual productivity.
In Agile, we estimate the size of a requirement, not the effort it takes to implement it. Since it is counterintuitive to estimate size rather than effort required to execute a task, let’s imagine two friends standing at one end of a field who are considering racing to the other end. They know both will run the same distance, around 100 yards. They see a fence with a gate midway through the course, suggesting they will have to account for the complexity of overcoming this obstacle. They also notice that the field is full of little holes and large rocks; although they don’t know where exactly they’re located, they will have to be careful to avoid them or else they get hurt, suggesting they will have to account for the effort to deal with the uncertainty of these unknown obstacles’ locations. When all is said and done, the distance, complexity, and uncertainty are the same for both friends; the size of their challenge is the same for both friends. What might be different is the effort each will have to put in: a more skilled mountaineer might do better than a world-class sprinter! As with the case with our friends, although the agile estimator(s) agree on a requirement size, the effort required to implement the issue might vary, and that’s OK. What matters is the team’s aggregate size.
The common thread on all estimation methodologies I’ve used has been the analysis of the software we were going to build, forging a good understanding of its parts, how they related to each other, and how they plan to build them. I have been using UML for a long time to help me analyze systems, to understand their parts and how they relate to each other; UML enabled us to create a context through which we could reliably and consistently evaluate and communicate complex systems.
Another common thread has been my inability to assess the effort required for implementing these systems, and to deliver them on time and budget without compromising quality. I tried all kinds of techniques to estimate the number of hours or days that would be required to implement our tasks, or the size (lines of code, function points) paired with a (mostly arbitrary) constant to transform size into time. In the early days I relied on our experts for these estimates. With time, these highly inaccurate methods grew into attempts to use formulas based on historical data and regression analysis. Recently, we have been experimenting with integrating experts and formulas, which I’ll discuss in more detail in this article.
There are not many planning tools available even today and until the mid-2000s, I used several Gantt Chart approaches to collect these estimates into a plan. The bigger the project, the more unwieldy these charts became, and, invariably, I would barely use them towards the end of projects, relying instead on the prioritized list of things to do. From the mid-2000s forward, we abandoned Gantt Charts and institutionalized our list of things to do as sprint backlogs!
One of the beautiful aspects of agile is that it integrates half a century of accumulated wisdom into a simple and easy-to-use project management mechanism, including a sophisticated and adaptable estimation approach: velocity.
Agile metric velocity gives our teams a simple data-driven mechanism to estimate workload and schedule for large quantities of work, to assess the impact of new requirements quickly, and to prioritize the tasks ahead, all based on the team’s recent performance. It is also a powerful mechanism to assess the impact of losing or onboarding a new team member.
Let’s take a look at how we use velocity to assess the impact of new requirements discovered halfway into the implementation of a set of features. For instance, given a product backlog, roadmap of 518 story points and a team’s velocity of 62 story points (always round up):
.jpeg)
After four sprints, the team implemented 262 points:
.jpeg)
If a new requirement emerges, amounting to 93 story points, we have at least two data-driven alternatives:
Integrate the new requirements in the product roadmap:
.jpeg)
Complete product roadmap as is, implement the new feature later:
.jpeg)
We either bundle the requirements into the existing effort and take 6 sprints to complete, or we finish the project in 4 sprints, perhaps 5, release it, and then come back to implement the new requirements later on in only 2 sprints.
I love how simple this is!
Now let's use the same project and assess the impact of losing a team member at the end of the fourth sprint, when the size of the outstanding product backlog is now 265 points; assuming that this individual had an average velocity of 16 points:
.jpeg)
This is a situation where it’s OK to leverage individual performance to assess the impact of losing a team member.
Despite our best planning efforts, reality is stubborn; stakeholders discover new requirements, senior team members get sick or quit, software engineers uncover hidden complexity that negatively affects many tasks, our assumption that a library would help prove us wrong, and so on. Despite all of these challenges, our stakeholders want us to deliver the project on budget and on time. Without a robust mechanism to have data-driven conversations with our stakeholders showing them the impact of these events on our schedule, we have no option but to work extra hard, cut corners, and lose individual and team morale. No one likes death marches.
My practice has taught me that software engineers are more willing to embrace project changes when working for teams with a solid history of using sizing and velocity to estimate their work and changes to the project.
Thus, by embracing sizing and agile velocity, engineering leads and their software teams endow themselves with an elegant and robust data-driven mechanism to estimate large amounts of work and to re-estimate the rest of the effort as the project suffers unforeseen setbacks. As software teams and their stakeholders learn to leverage these tools to estimate deliverables, trust between them grows. We can only build amazing software systems when our stakeholders trust us, and vice versa.
Get instant visibility and the actionable insights you need to maximize your dev team’s potential!
Book demo
