How to Maximize Scrum Team Velocity & Predictability? Why Does It Matter for Stakeholders?
Hi everyone,
I'm looking for insights and best practices on improving velocity and predictability in Scrum teams.
- What strategies or tools have you found most effective in helping Scrum teams achieve their maximum potential in terms of velocity and predictability?
- How do you balance optimizing these metrics while still fostering a sustainable work environment for the team?
- Why do you think stakeholders care so much about velocity and predictability?
- How do you communicate these metrics in a way that is meaningful and actionable for stakeholders without overwhelming them?
In your experience, why is it essential to keep track of velocity and predictability over time?
Are there any specific data points or trends you prioritize when analyzing these metrics?
I'm curious to hear about the challenges you've faced, the solutions you've tried, and the lessons you've learned regarding these topics.
Looking forward to hearing your thoughts and learning from your experiences!
Why do you want to improve velocity and predictability?
It's probably easier to discuss the two concepts independently.
Velocity, as it's typically defined, is the rate at which work gets done. In my experience, it's usually measured by looking at the completed work items and adding up the estimates for those work items to get a single value. However, this isn't a meaningful measure of anything useful.
The first problem is that it's often based on estimates. The estimate is done before beginning the work and is rarely, if ever, revisited when the work is complete. There are ways to mitigate this - you can apply the law of large numbers, or you can choose to invest the time to update estimates with actuals after the fact.
The second problem concerns assumptions about what velocity does (or doesn't) imply. Doing more work says nothing about the value of that work. Consider Goodhart's Law and the Hawthorne Effect. If you measure how much work people do, and especially if you reward getting more work done, people will optimize the system for appearing to do more work rather than delivering value. People may inflate estimates, try to get more units of work done regardless of the value of that work, or even create unnecessary work.
Instead of velocity, I've found that measuring throughput and cycle time is often more meaningful. It's also important to treat these as indicators rather than something to optimize. That is, instead of trying to increase throughput or decrease cycle time, understand what is causing delays in the workflow and addressing those. However, even these metrics fall victim to the problem of not measuring value and delivering more work in less time doesn't add stakeholder value.
Any measure of output would need to be paired with a measure of outcomes, but outcomes are highly context sensitive.
Predictability is a more vague idea. What do people want predictability in or of?
Scrum inherently offers one form of predictability. Within the Scrum framework, the Developers are expected to produce a product Increment at least once per Sprint. Therefore, by the Sprint Review, stakeholders can expect a new and improved product Increment to examine. Since Sprints are generally stable in duration, this offers consistency and predictability.
Beyond that, the Sprint Goal also offers a form of predictability. At the Sprint Planning, the Scrum Team commits to a Sprint Goal that will move the product closer to the current Product Goal. The team should achieve the Sprint Goal more often than not, although the tolerance for risk and reaching for a more ambitious goal varies by team and context.
If a Scrum Team isn't predictable - meeting their goal Sprint over Sprint by delivering a usable product Increment - that is something to address through the Sprint Retrospective.