Is Velocity Broken?
Or, am I just looking for trouble…
Velocity in scrum is a measure of the average productivity of a team that can be used to project future productivity. The basic gist of how velocity works is that teams assign points to tickets relative to complexity and risk, the amount of points completed in a cycle/sprint is tracked, then some running average of points completed per sprint informs that team as to how many points they should be able to take on during their next sprint. The running average used in this calculation is the team’s velocity.
There are many nuances not covered in this description of velocity, and each team tends to do things a bit differently — but essentially, this is how velocity is supposed to work. We can tell when velocity is working correctly by looking at whether or not the amount of work planned into a sprints is just the right amount of work for that sprint.
Overall, managing velocity is a somewhat complex process that some teams to get right. For the teams where I’ve seen this happen, there is usually a strong scrum master working continuously to ingrain a balanced set of practices into each team member . Each team member succumbs to the scrum master and the team’s norms. Eventually, things start to click and, barring disruption, you get a highly functioning team — at least from the perspective of scrum — driving their way through smooth, evenly paced sprints.
Working on highly functioning teams is a great experience. All the cogs in the wheel are oiled and the machine is happily turning out features. Sadly, I haven’t worked on many teams that regularly planned about the right amount of work for their sprints. Habits begin to develop to account for shortfalls in the velocity based planning system. The predominant habit is regularly moving things in and out of sprints to account for regular breakdowns in planning versus reality.
For these scrum teams where velocity and scoring aren’t successful, things can chaotic — and velocity and scoring leads to sprint after sprint of broken promises. Velocity, scoring, and planning becomes a ritual of denial where teams bend the rules, or begin to ignore them completely. Scoring sometimes becomes a “usually” process, the measure of velocity breaks down (if it was working in the first place), and we move into a world of team heroes and empty promises.
I’d like to talk about some systemic reasons why scoring breaks down from a methodology standpoint. Then propose a path for teams that just can’t seem to get velocity and scoring to work for them.
Scores and Velocity are Tightly Coupled
When teams score stories, the points assigned map directly to the output velocity. So, if a team consistently completes 4 tickets — each scored 5 points — across several sprints, then the team’s velocity is probably going to be 20.
These calculations make it easy for teams to think of work in terms of time: “We can do four five-point tickets in a week. With four team members, that averages a week ticket. Each point is worth a day of work.” The math is too easy and values become obvious over time. Knowing this mapping as a team member, I can now start thinking of work in terms of days. (Note that even if we started scoring in shirt sizes, we could still do the math.)
This isn’t a problem for all teams. Teams that are scrum experts, or have a very strong scrum master may not have this problem, but it’s possible (probable?) even these teams may have members that think it terms of days. Really, there is probably complete solution around this problem that involves scoring.
Scoring — by it’s very nature — can be looked at as taking the notions of effort and risk and attempting to measure them against a task. For most of us, the easiest way to contextualize these factors is to put them in terms of time. Time is, after all, a common denominator between the two.
More to the point, what product and project managers want from scores is a way to predict how long work will take. In this way, velocity and points are inherently time-centric. Again, strong teams will strive to think of score as something else (a measure of effort/complexity and risk) without falling into the pit of “points are time”. Others can mitigate this behavior through practice and repetition the same way these strong teams gained these skills. I’ve never really been able to completely separate the two in my head — and neither have many others.
Ultimately, I suggest that the notion of points as a product of effort and risk does not readily work for a large number of us—as proven time and again. When was the last time you worked on a team that gave up and just starting scoring in days? Or, try asking a team how many points a day is. If someone doesn’t head off the answer, you’ll probably get a number from at least one team member that the entire team knows intuitively.
Who Needs Velocity?
Hint: velocity is not directly tied to creation.
As team members, our focus is or should be on getting through the work put before us in the order it is put before us. Velocity, and scoring as a mechanism that supports velocity, are tools used to determine how long it will take a team to complete a set amount of work. This in turn informs the business as to what work should be done and when.
Teams may value timelines and roadmaps as part of their sense of (or actual) ownership in the greater business; but, these other factors have nothing to do with the scrum process from within the scope of a building features. Why do we ingrain scoring and velocity into our scrum processes when they do not and/or should not impact the process of moving the doing the work before us? Why is time tracking so often the predominant focus of our process of productivity?
Generally, I say we do these things to meet the needs of the business — not the product. Stated more directly and from a process standpoint: we have prioritized business needs over product needs. Our processes focus on tracking and tend to ignore product.
To be fair, scrum has sprints, and sprints have benefits tied to scores and velocity. Namely, we can use velocity and scoring to more accurately set goals and complete those goals. I won’t argue that having tangible goals and accomplishments are good. I will ask — is this the only or best way to achieve these benefits? Goals and accomplishments are great, but is there a way to get those benefits without wrapping our entire system of delivery around velocity and scores?
Velocity and Scores as a Measure of Success
In regards to goals in particular, I question the idea that the goals defined in the scrum process are tied to to the act of completing a construct of the process. We don’t always do this. Formal sprint goals are sometimes product focused. I see too often though sprint goals such as “complex feature X by the end of the sprint”. The feature is in the goal, but the real goal is to bend the feature development to the will of the sprint cycle.
Shouldn’t our primary goals be tied more directly to the product? Instead, we focus our goals on the act of engaging in the process, and our product becomes a side effect once removed from our goals.
At the end of the day, velocity as a measure of what work we think we can complete, and how we drive that into sprint goals is kid of sad. It becomes a sort of participation award. Congratulations, you did the amount of work you normally do — and within that work, some feature was marked complete.
Getting back on track…
We know who needs velocity: the business. Velocity is, as I see it, a way to inject productivity measures and predictability into a creative process. If this holds true, velocity is the implementation of the external forces towards a teams productivity and predictability. That’s not so bad; but, when it overrides the teams focus on product, then maybe it is so bad.
Velocity as Accountability
Velocity does provide another benefit. It provides accountability. We measure how much work we can do, and pipe work through our teams as points. Teams agree to complete points and then we see plainly whether or not the team has completed the agreed upon work. Accountability is certainly very important.
Sadly, velocity and scoring as a mechanism for preventing nefarious behavior is a system easily gained. Pad a few story’s points and you’ve got time to burn. Systems are meant to be gained. Good product managers and leads will prevent this — but good product managers and leads will also ensure accountability without the mechanism of velocity.
Accountability is hard work for the smart leader. Accountability is people skills. It is ground level intuition. It is trusting your subordinate manager’s subordinate manager to know their team — how to fix or remove weak links, when to apply pressure, how to motivate.
Time spent focusing on ceremony is time lost focusing on the team. The ceremony of scrum is a poor replacement for these real management skills. Sadly, this ceremony too often enables poor managers to continue to be poor managers. It is too easy to run a team that always meets scrum objectives while also being broken, ineffective, and inefficient. It is too easy to tell yourself things are going well because velocity is being maintained.
A side thought on accountability: Accountability should be taken daily (and probably during standup). Applying accountability in retrospectives is a sentence (as in punishment). It has demoralizing value. Attempting to apply accountability during planning is no where near granular enough. Teams need daily support and monitoring in order to ensure productivity, not semi-monthly pep rallies.
Velocity, the Best We can Do?
I’ve spent a good bit of our time breaking down velocity. Tearing it apart and attempting to extinguish the notion of it’s usefulness. What I haven’t clearly stated is that velocity is important. It is essential to the function of business. A business that cannot measure its productivity cannot guarantee its success. A business that cannot plan against time the development of their product cannot hold itself accountable.
I don’t mean to extinguish the notion of velocity. I just think that velocity is ingrained deep in our teams processes and I don’t think it belongs there. I think we need a better system of running teams that isn’t driven by velocity. I think that business should be the primary arbiter of velocity. I think there is a better path forward, and if we don’t realize we are living in a broken system, we will never fix that system. I think there are enough smart people working in the world of project management and scrum that we find a better solution —a solution that pushes our teams away from focusing on velocity and refocuses them on product. Let’s move away from the process of making work happen. Let’s get to the business of making product happen.
Epilogue
I do have some notions of what a product focused system might look like. Unfortunately, I am just a engineer and there are people much wiser and more skilled at project management that may know better ways. Regardless, I intent to write about my ideas in an upcoming blog post.
The ideas I have focus around using information architecture to break down features, refactors, and other large team tasks into bite size pieces. From there, each task becomes a single unit. Each unit is a single point (no more scoring). Business can then do planning and monitor productivity against points completed. The use of information architecture to break down stories at the team level is much more product centric — and I’d argue much better for breaking down stories than most other mechanisms.
Sprints probably don’t have a place in this world — so presumably an alternative system is something more kanban-esque. My argument against sprints is that they will always drive a team to focus on time commitments rather than product commitments. Our goals can focus on completing features. There will still be time commitments, I’m sure, but we can be more concerned about what feature configurations we can achieve by given deadlines, and focus less the rituals of sprints.
Until next we meet, happy product making!
- Randall
