A Tale of Two Capacities
It was the best of sprints, it was the worst of sprints.
One reason I find scrum so invigorating stems from its reliance on compiling lots and lots of data. Back when I was getting my English degree, I never would have imagined how much I love plugging numbers into spreadsheets and adding formulas to those sheets that makes the numbers show me things. I think it’s the same instinct that gave me great pleasure in alphabetizing my CD collection in a giant black binder (back when I actually needed stacks of physical media on my person to enjoy music).
Yesterday’s weather
There’s a saying that people invariably attribute to wherever they live: if you don’t like the weather in [PLACE] wait five minutes. That said, more often than not, the opposite is true. A great way to predict tomorrow’s weather is to look at yesterday’s. You won’t always be right (and likely never exactly right), but you will be close enough to not die from exposure to the elements.
Scrum: how to not die from exposure
With enough successful sprints in the rearview mirror, teams gain more and more certainty in knowing what they can (and cannot) commit to in a sprint. In the scrum world, this certainty stems from yesterday’s weather, which is used to determine a team’s sprint capacity. Since the agreement is “once work is in a sprint, it shall be done by sprint’s end,” teams need to make informed commitments. If sprints are planned by the holy-cow-we-have-so-much-to-do-lets-do-all-of-it-at-once method, the team will fail not for lack of trying, but because the situation is untenable. Pulling in more work than a team can reasonably complete in a sprint is not only a lie to project stakeholders, it can lower team morale too. Responsible teams need to set achievable goals.
Before sprint planning, the scrum master needs to figure out yesterday’s weather. This is done by taking the amount of completed story points from the last three sprints and calculating their average - easy peasy. Let’s say we have a team using one-week sprints (which is what I run, after some initial apprehension, and now longer sprints seem insane to me). This team’s historical data goes like this: 77 story points (sp) for the sprint from 3 weeks ago (s3wa), 89 sp in s2wa, and 81 sp in s1wa. How much work can this team confidently say they can complete in the next sprint?
(77sp+89sp+81sp) / 3 sprints = 82
OR
82sp
This hypothetical team has the capacity to commit to 82 story points for their next sprint with confidence. While not a locked-in guarantee that they will complete 82 story points, they are very likely to do so. Making a data-driven plan eases a team’s anxiety around work, as well as provides readily available context of expected progress for all stakeholders involved.
At the end of the next sprint, the scrum master will recalculate yesterday’s weather with the three most recently closed sprints just as before. Having this data sprint-over-sprint for a stable team can inform burnup charts for longer projects, as well as forecasting and sales. Need a timeline for a new scope of work? Yesterday’s weather has you covered.
Sprints as manifest destiny
While it is wonderful for a team to take assurance in sane sprints planned using capacity data, it can be a double-edged sword. I liken it to my lifetime membership in the Clean Plate Club.
When it comes to eating, I never leave food on my plate. Brought up in an Italian household, my younger days were buried in mountains of meals. I faced many a full plate and never backed down. Regardless of the portions, I would clean that plate and be satisfied with my efforts. That said, it is horribly unhealthy to eat this way! Like a goldfish that expands to consume every last inch of its environment, without portion control, many of us will happily chow down on a box of Girl Scout cookies or bag of potato chips until all that is left is empty packages and shame.
This psychological effect works the similarly when a plated amount of food is reasonably sized. If that’s all we get, once done, it satisfies the completionist inside of us. So in a sprint, completing all the points yesterday’s weather served up is good, high performing teams should finish all of those points and more. For that, we need to talk about the other capacity of agile, which shows up once all the work is done.
One more for the road
As a scrum master, one of my primary responsibilities is to remove or address impediments that block the team so they can be their most efficient selves. Sometimes this is external (a task needs some asset only a third party has) and other times it is highly internal (team unhappiness is getting in the way of work). In the end, no matter the issue, I help my team move past it in order to increase our productivity, which allows us to grow our velocity.
For velocity to increase, a team needs to do more work than they planned on doing back at planning. By deftly and swiftly moving through planned sprint work, the team creates capacity for themselves, room to pull in more work (ideally tasks that can be completed in the time left before sprint’s end). By completing even one extra story point, the team increases their velocity and will likely have an increased yesterday’s weather at next planning.
Often, velocity gains stem from the team getting faster at completing tasks which bear similarity to previously done work. That said, if velocity increases regularly stem from tasks overpointed in hindsight, teams should revisit their reference story examples to ensure that future estimates more accurately represent the effort and risk involved in finishing a task.
Velocity isn’t a highway, but it also isn’t the scenic route. Teams won’t experience an ever-increasing velocity each sprint, nor should a high performing team see velocity that rises and twists all over the map. Rather, put it in your mind now that gains will be slow, yet steady. Dips will be present, but not prevalent. Focus on maximizing the good things that happen each sprint and mitigating the not-so-good things. Over time, you’ll see an upward trajectory of both velocity and work product to boot.