The team that sizes together, rises together
How finding your Agile team’s “sustainable velocity”—the amount of work they can do consistently—can lift morale, lower stress, and improve quality.
Heroic efforts aren’t sustainable
The Agile Manifesto tells us that maintaining a constant, predictable pace of work is a key characteristic of a successful team. But why? Well, have you ever been on an effort when your team overestimated how much they can do? The result—heroic efforts, stress, long hours, stress, cut corners, stress—does not make for a viable long-term strategy. On the other end of the spectrum, you can consistently hit your goals if you low-ball them. But then you won’t be getting the most out of your team. Finding the sweet spot is key. High-performing teams find and optimize their throughput capacity through experimentation and learning (failing fast and iterating is another tenet of Agile). But to learn from your failure, you need to measure it.
Scrum (the most popular Agile framework) suggests teams need two components to measure their predictability: the size of the work and the team’s velocity (or capacity to deliver value). Scrum teams find the size of their work by breaking the work into small pieces called stories, and then sizing them against each other. The most popular sizing mechanism is story points. To begin, Scrum teams find the smallest story on the list and give it one point. Then the team chooses another story on the list and determines its size relative to the one-point story—the same size (1 point), twice as big (2 points), five times as big (5 points), etc. This process is repeated for all the stories. Sizing shifts from an individual estimate of “how long” to a crowd-sourced estimate of “how big.”
A team finds their velocity by selecting a consistent iteration cadence (two weeks, for example) and seeing how much they can complete in that period. If they complete 20 story points, that’s their velocity. If in the next iteration, they complete 30 points, then their velocity will be 25 points.
By making this collaborative with your whole team, not only do you get accurate information, you get everyone’s buy-in and investment. Anxiety levels drop as people know they have the time and resources to meet their commitments. Conversations with stakeholders outside your team become less fraught because you can deliver what you promise, and have a clear rationale for turning down work beyond your capacity. Planning becomes a calm, rational, and—dare we say it—even pleasant experience.
A better way for cross-functional teams—in and out of tech
Within technology ranks, I often hear the question, “Does velocity only apply to developers and testers?” Which is a particularly relevant question for cross-functional Agile teams that may have process and data analysts, UX designers, developers, testers, etc. (Spoiler alert: no.)
Let’s say you have a cross-functional team working on a large Salesforce implementation. A story (which remember is Agile-speak for a chunk of work) to enable a business manager to search through a list of opportunities may require contributions from a developer, data analyst, and tester.
Any work that contributes to the completion of the story should be taken into account when assigning points. As the team sizes the story together, they consider two factors:
- What size is my contribution to the story?
- How big is the story when we take into account the contribution of others, the overall complexity, and potential unknowns?
As teams size together, I’ve seen raised eyebrows when a developer suggests three points for a story while a tester estimates eight. Not everyone may be aware of the complexity of others’ work. Sizing as a team is an opportunity for critical team dialogue. This conversation can save the team hours of work as each person gains a better understanding of what’s needed to accomplish each task, and the overall project.
I’ve seen this process transform not only tech teams, but business teams, too. A marketing team I once coached used to work in silos. Every project required unique contributions from each team member, who would work on multiple efforts at the same time—and depended on someone else to finish their work. Arbitrary dates were set by leaders to complete certain work without regard to the team’s capacity—which was unknown because it wasn’t measured. People were logging crazy hours and grew more and more frustrated, impacting the quality of work and overall morale.
Applying Scrum and planning together using the point system resolved a host of challenges. They sized each story as a team, and maintained a velocity that reflected the deliverables of the entire team. This enabled them to be more predictable, and to manage executive expectations as to what was achievable and by when. Morale improved, the team became more unified.
Whether we’re on a software development team, a marketing team, or even a finance team, a cascade of good things happen when you work as a team, size as a team, and deliver as a team.
