Perhaps in terms of micromanagement software tracking velocity metrics, but the concept of velocity, and the practice of getting rid of obstacles to getting things done is an essential part of engineering management. It involves identifying and replacing poor tooling (easy), and fixing broken culture or processes (very hard), specially at the interface with product management and support.
This is a qualitative process, though, and using velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest.
It is also important to recognize the importance of keeping slack in a system and not over-optimizing it, as explained in Tom DeMarco's excellent book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
Velocity ignores direction making it completely useless for quantifying useful output or just about anything else. Replacing a buggy design as part of a bug fix can be more productive than individually fixing dozens of subtle errors that take months or even years to discover and work through. However it’s easy to endlessly refactor without making net progress, and unfortunately the exact same culture can do both.
The problem with velocity isn’t poor metrics, the problem with velocity is it’s trying to measure a meaningless quantity.
I think the word choice of "velocity" indicates that its original intention was to have direction, otherwise it would be "speed" :).
What you're defining as velocity here is the exact 'micromanagement software tracking velocity metrics' that the parent comment is arguing against.
Velocity is probably more accurately thought of as the rate at which we can improve or create the right products for our business goals. But as the parent said, this is a qualitative and difficult to capture with metrics.
Depends on context, in music, economics, etc velocity doesn’t include a vector.
But to help clarify the point, if the project knew what was useless then people wouldn’t be working on it. Essentially, the team is defining useful work by what’s being worked on which robs the direction of any meaning.
What is the unit of velocity? LoC per hour? Then people would just spread out their code. Businesspoints per hour?
When I hear such things I have the strong urge to factor in how lasting such solutions are.
A company that puts up 100 bridges a year of which 90 collapse within two years is a worse engineering company than one that puts up one a year that lasts for 50 years.
That's the problem that was raised by the parent comment. There is no single 'unit' for this formulation of velocity because it is too qualitative.
It's a similar property to "code quality" in that regard. There are metrics like 'test coverage' or 'dependency graph complexity' but these can also be gamed intentionally or unintentionally much like LoC.
There are lots of descriptive metrics you can come up with that can be useful in exploring how you are performing or how your performance is changing with regard to quality or velocity. But treating such a metric as an actual proxy for the underlying property is not useful and sometimes counterproductive as you point out.
I think this is where the notion of software craftsmanship appears. We are still at the point where it requires an expert who is engaged in the process to essentially sense how they or their team is performing on these properties. They can use metrics to inform that sense or to help in determining what actions should be taken.
But this is frustrating for larger organizations where frequently the people who want to measure a certain property are not actually participating in the process because they are separated by multiple layers of management. You essentially have to trust that every management layer below you is able to accurately assess a qualitative property, which is difficult to standardize and scale.
How about measuring time until a customer (or plural) gains value from a feature? I know it's very ephemeral, but in general building a bridge is not the end goal, what if no one uses it or even knows about it?
> Velocity ignores direction making it completely useless for quantifying useful output or just about anything else
Velocity is important but I think it's an orthogonal concept to quantifying useful output. In my mind, velocity is how quickly developers are able to unblock themselves and overcome obstacles. It's very possible that people can have extremely high velocity working on pointless stuff but that's not what velocity is meant to track anyway.
> The problem with velocity isn’t poor metrics, the problem with velocity is it’s trying to measure a meaningless quantity.
that's exactly right, it's taking 2 dimensions (estimate and fitness of estimate) and quashing it down into 1 dimension, where you necessarily lose information.
It's a point in that it's an abstract idea that can represent an atom or a universe.
It's not useful for anything outside of the abstract.
> Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes.
So what? The question isn't "what helps you fix everything?"
The question is "how useful is velocity?"...without qualification as how you quantified the values. Looking deeper, the question naturally progresses to "what is the most useful metric?" or even "what is a useful metric?" in determining performance (a scary thought experiment for most developers).
Narrowing the scope of the analysis is a necessary step in determining value. Let's dispense with the gaming numbers strawmen and refactoring and testing rigor etc etc.
Theoretically, if it's you (alone) on a project and you have no other external signals about how well features are valued, what singular value, over time, would you look at and judge your progress historically? This is the closest you can get to an abstract vision of (personal) performance on a project divested from all other concerns. I can always look at my LoC.
Given that there isn't one number (or five numbers or five thousand numbers) that can tell you if your engineering team is good or bad, there is no easy mapping between high and low velocity and good and bad, and velocity can't really be compared between teams or even the same team on different projects, it does have uses.
Particularly when a team has multiple projects, looking at each project's velocity helps you see if you're smoothly building out new features, getting bogged down, distracted by bugs in an old project, consistently underestimating the effort required for all things, etc.
It's a terrible target, not good for evaluation, but a handy metric for a PM to quietly check and use to make sure things are proceeding smoothly. The PM should probably know by other means but no one is perfect.
I think it’s still a useful input into planning and decision making if it is understood to be lower quality data that can’t account for all variables in software projects. Unfortunately, MBA-types refuse to interpret estimates this way and can’t keep their grubby paws off using them as bad performance measures.
> velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest
That's not just a poor analogy but wrong. I can't even start to identify what aspect of velocity is the key and the street lamp or searching. Velocity is a tool to assess the amount of work you do per cycle and to help plan how much work to take in a given cycle.
It has nothing to do with losing key,, searching or only looking where there is light.
As usual, for any process, haters will just trade jabs and nod appreciatively and how much it all suck. Assessing how much work you team does every cycle is a useful metric, and people higher up like to have at least a small glimpse of how much work and and much time it will take to finish a feature.
Ok, so you seem to appreciate the value of a VELOCITY metric.
I am curious if you also track UNPLANNED WORK.
The reason I ask is because in my experience a VELOCITY metric is in fact useless without also tracking PLANNED vs. UNPLANNED work. I am hoping you say "Yes, we track that".
BTW I thought the metaphor was quite appropriate (and hardly snarky -- not sure why you read that into it).
If you dont count UNPLANNED WORK into your velocity, then it becomes a useful metric for planning. Its basically an inverse of disruption. Dev always wants to assign points to anything that gets pulled into a plan after commitments, or any scope creep, but if you can resist then your velocity becomes relatively consistent and predictable.
In my experience, metrics are a giant waste of time for engineers and engineering managers. Project managers and folks who depend on the fruits of engineering labor on the other hand love these metrics. It is simpler (and wrongheaded) because who wants complications after all?
Look at the trivialization in this article for instance - "tasks come in, and software comes out". Oh really? I had no idea!
Tasks vary drastically from project to project,including due to varying requirements, ambient software environment, technological changes and a host of other factors. Metrics are a way for project managers to pass the buck on to the engineering teams and nothing more.
You gotta have some way of answering the "how long is it going to take" question. There's no better way of predicting things than looking at how long things have taken in the past.
Unfortunately what everyone forgets is that historical information only applies if you are doing "a thing" that is similar to what you've done before.
One way to address this problem is to not ask the question, but to work with your teams to set goals for a longer period of time such as a quarter. Then structure your organization such that it doesn't depend on the exact timing of work completion.
How does a longer period of time help with estimation? Trying to estimate what you will complete in a quarter is even harder than estimating what you will complete in a week… errors compound.
If you are setting “midrange objectives” for a quarter, you are basically saying “I estimate I will complete this much work in the quarter”, because you are estimating you can complete enough work to meet the objective in a quarter. Either the objective is easy enough that the estimate doesn’t have to be that accurate to still meet it, or the objective is not specific enough to require an accurate estimate.
I actually mostly agree with the comment I was replying to, I just think the “set goals for a longer period of time” was not filling in the whole picture. You can’t just set the same types of goals you had when you were making sprint estimations, stretch them out to be quarter estimations, and expect the problem to go away.
I think the difference is in plurality. Setting goals for a quarter (or month, or year) to me is more of a team thing/focus/discussion rather than an individual's estimation of what they can do. And I completely agree with you that stretching a sprint into a quarter makes no sense if it is only for estimating one person's work.
Given that so much of what we do as developers typically depends on more than just ourself in an effort, I agree with what I think tadfisher is expressing; realistic delivery planning can be achieved by focusing on "teams and goals for the next few months" and cannot be by trying to answer "how long will <insert feature never done before> take?"
It really comes down to: can you provide the value we need in this area. That value might be "validate experimental research is implementable", or "perform a spike to de-risk a future effort".
There's a fog of uncertainty that gets impenetrable past a certain time horizon. We need businesses that are capable of forging ahead into the unknown, being honest about the level of confidence given our knowledge at the time. I don't see that approach coming out of MBA schools, and I think Elon's approach is in marked contrast to that.
In many ways old school grassroots agile has penetrated the lower levels of the org (to some degree), but the upper levels haven't changed in decades, and this impedance mismatch is most visible in the rigidity of planning (which is also forced on them by outside pressures).
> You gotta have some way of answering the "how long is it going to take" question.
Code (implementation) is an integral alert part of the software design and planning process, and you can’t know how long something will take until that’s complete.
While estimation seems to be a shibboleth of certain types of project management, the fact that implementation time estimates are rarely accurate - and often significantly wrong - suggests that they are not as vital as we’re lead to believe.
> While estimation seems to be a shibboleth of certain types of project management, the fact that implementation time estimates are rarely accurate - and often significantly wrong - suggests that they are not as vital as we’re lead to believe.
I disagree with your conclusion. Just because we're terrible at estimating doesn't mean it's not important.
"100% uptime is rarely achieved, which means it's unnecessary and unimportant".
> Code (implementation) is an integral alert part of the software design and planning process, and you can’t know how long something will take until that’s complete.
McConnel talks about it in "Software Estimation". The only way to accurately predict anything is to base it on your previous experience, which I allude to. Unfortunately (or fortunately, depending on how you look at it), even projects that looks similar on the surface are more frequently dissimilar than similar.
Regardless it's useful to be able to answer the "how long" question at least a coarse level to see if it's worth doing something.
I understand that we disagree, but Eric Evans also talks about how implementation is an inescapable part of design, as does Jack Reeves. So it follows, for me at least, that estimates can never be accurate.
Recently posted on HN was a link to a post at Lunar Logic where estimation is basically broken into 3 categories: “NFC” (no clue), “TFB” (too big) or “1”. They explain why here [1].
This has been my experience over more than 30 years of building products. The duration of any given feature/story is effectively unknowable, but we can make a decent guess as to it’s achievability, we can get a decent idea of the rate at which stories are completed.
The main problem I have with more detailed estimation is that the estimation process itself consumes significant engineering resources which IMO should be assigned to actual engineering.
To your specific points:
> "100% uptime is rarely achieved, which means it's unnecessary and unimportant".
This is specious. As an industry our estimates tend to be wildly wrong, and despite decades of dealing with “the software crisis” they are not improving. My position is that this means that we’re spending a lot of time estimating and then more time dealing with them being wrong. It’s just a waste.
> Regardless it's useful to be able to answer the "how long" question at least a coarse level to see if it's worth doing something.
This seems to be the wrong way to do it. Surely the approach should be to ask what value this “something” has to the business, and then determine if it’s technically feasible within that value.
But that would mean more work for the executives, and quite frankly this, in my direct experience, is not the kind of responsibility they like to take on.
I am an engineer, and I rely heavily on metrics, because my job requires quantifying that a system is working correctly. It is impossible to do that correctly without metrics.
Similarly, managing a product team is also managing a running system; that system is just made up of meat sacks whacking plastic buttons with their bony protrusions, rather than computers humming away in data centers. A product manager still needs to quantify that the system making that product is working correctly, and metrics are essential. Otherwise you will only be guessing as to how the system is working, and those guesses will be much more haphazard as the system grows.
The hard truth is metrics work. I can quantify someone’s performance and if they’re not doing well put pressure on them to do better or hire someone else. Velocity is a pretty good measure of someone’s performance especially if the estimating is done in a sprint planning session with the entire team.
The harder truth is that metrics only appear to work. As soon as you use metrics to judge performance, people will start gaming them. They’ll do whatever it takes to get a good score, regardless of whether it’s good for the company or its customers.
The metrics “work,” in that they’ll go up, but the things you don’t measure will get worse, often (eventually) catastrophically.
In the case of velocity, you’ll get people taking shortcuts and sacrificing quality, both internal and external, so they can juice their numbers. The outcome is technical debt and arguments about what it means for something to be done, resulting in slower progress overall.
Source: I’ve been consulting in this space for a few decades now, and have seen the consequences of using velocity as a performance measure time and time again.
(Other metrics are just as bad. See Robert Austin, Measuring and Managing Performance in Organizations, for an explanation of why knowledge work like software development is incompletely measurable and thus subject to measurement dysfunction.)
Yes, that is true. But metrics cannot pinpoint the cause of the problem, which is where the engineering approach fails. You cannot accurately measure the stress levels of individual developers like you can with force plates. You cannot accurately measure developers taking shortcuts in their code like you can measure gear slippage. Similarly, you cannot accurately predict the critical load of a particular configuration of developers like you do with beams in bridge construction, nor can you accurately measure the weight of a feature request like you can weigh a vehicle. You cannot measure the "velocity" of two developer teams working on a different codebase and then assume that the metrics are comparable just because you're measuring the same quantity.
The only way software development metrics are useful is to get an indication of the performance over time of the same team working on the same codebase. That should give some indication of the overall trends, but when the numbers start going down, how will you accurately determine the cause of that? Will you treat the developer team as a black box and insert more probes, or will you talk to them and rely on their qualitative assessments after all?
Using data and metrics for analysis and self-reflection is great, when used thoughtfully. The problems arise when they’re used to judge performance—or even perceived to be used to judge performance. That’s why they’re so tricky to use well. You have to set up a situation where it’s systematically impossible to abuse metrics, typically by putting the data and analysis/judgement at the same level, and only reporting aggregated/anonymized results and qualitative conclusions rather than the raw data.
Some people don’t know how to manage without measurements, punishments, and rewards. It’s a correctable flaw. Measurement-based management is called “theory X” management, but knowledge work needs “theory Y” management. There’s a lot of material out there on how to do it, including a section on it in my book.
The hard truth is that using velocity to measure performance will guarantee that developers bias their estimates to ensure they make themselves look good, thereby making your "estimates" useless.
Anyone who's built software knows that estimates are guesses and are bound to change once the work actually begins (not to mention if scope changes midway through).
Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.
> Additionally, velocity does not "count" work happening outside of tickets, e.g., helping with a customer support issue, assisting another developer with legacy code, reviewing other people's work, spending time on feature planning.
Your capacity is adjusted accordingly. In my team an engineer who's going to work-on production support, would not have his capacity accounted. Similarly, if an engineer has a lot of cross-team work going-on then we'll reduce his capacity as well, and so on.
Yuck, I'd quit your team. That level of micromanagement is demoralizing and it hurts the company. "Sorry support, I have zero autonomy. I can't talk to you unless my manager adjusts some number in some spreadsheet"
Sorry! I'm not doing it in just my team; that's how it's across hundred of teams in my org.
I believe I was not clear: it's a rotational support - where every engineer is encourage to spend a sprint worth of time in every quarter on working on support tickets. You've complete autonomy - you don't want to work on support tickets, it's alright. No one is forcing you. You want to spend next two weeks on a training or self-learning - go for it.
> > Your capacity is adjusted accordingly. ...
> That level of micromanagement is demoralizing and it hurts the company.
The micromanagement identified is not in the type of work which is most appropriate to success, but instead in the "detailed capacity accounting." This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control).
Encouraging engineers to "spend a sprint worth of time in every quarter" or the "next two weeks on a training or self-learning" is laudable, but does not qualify as providing autonomy or the lack of micromanagement. The reasons why are A) the decision is still solely yours and B) clearly time-driven instead of collaboratively prioritized.
You've complete autonomy ...
Not if you decide when, how long, and with what fixed frequency someone can work on tasks which impact "velocity."
> This level of "accounting" does not convey trust in an engineer, thus demoralizing them by way of eliminating their autonomy (freedom from external control).
I'm curious to know how it's done at your workplace. Please share.
This is exactly what I would not want my team to suffer. They need to feel inspired, and those who are not inspired will know it themselves, and so will everyone they work with. I don't need a spreadsheet to tell somebody's commitment
I’m glad I don’t work on anything you’re responsible for. I’ve made a great career out of hiring the people folks like you burn out and frustrate.
I’ll bet $5 that people conform to your model by working longer than necessary and your “velocity” is considerably lower than it could be, despite being measurably consistent.
No, I’m very insistent on not working late, almost ever. I know the velocity isn’t bullshit because having been a developer for years I know the estimates are reasonable. I also had a 100% retention rate on my team this year with a sizable team and my company paying salaries only a little bit above average.
You are technically correct, which is (technically) the best kind of correct.
For better or for worse, though, most of the modern software industry has converged on "software engineering" as the name for what they do, while terms like "web developer" usually invoke spooky prehistoric (20th-century) connotations of companies that treat software as "part of the IT department" and a "cost center."
I enjoyed this series of interviews with engineers from other fields who switched to software development. Their broad conclusion is that software engineers are either already engineers, or are pretty close.
It's just title inflation. Previously, a system engineer used to work at Nasa, now they configure computer networks.
Now everyone is a tech/dev advocate because they have 500+ linkedin connections and repost the same cloud news everyone has already read.
I'm just going to coin the next stupid title now, 'cloud astronaut', they're so good they're beyond the cloud. That will fill the blank void that is your ego. You're welcome.
Cloud astronaut already has a connotation. An "astronaut" is like a loftier more out of touch cowboy. The cowboy will get work done (their own way) even if they're off the beaten path.
The astronaut is about the journey of exploration into the unknown. Forget bike shedding. We're talking research into moon bases.
Thanks so much for this brilliant comment. Indeed, this is statistical process control. What I meant by “engineering” was that it applies to software engineering teams.
I’ll consider adapting the title, but not sure whether folks would grasp my intent as quickly
> has been borrowed and misused in software management.
as a software engineer, I really apprecaite this.
> about accelerometers and how the ill effects of vibration have been mitigated
I really hope I can mitigate vibrations of mood, esp the procrastinatory kinds. But then I don't want to over-"engineer" my behaviours or it would start to become existential. Like sometimes I don't even know what is meaningful anymore (despite working on my dream job), or if I can truly humanly love myself. Being human is tough.
An old mentor used to talk about "installing shock absorbers" (in the metaphorical sense) for this sort of thing.
Hope you're doing okay, dude. Meaning doesn't mean much, but learning to love and be happy is (from what I can gather) far more important than the zeroes and ones we tinker with. I'm trying to figure it out myself and waiting for the good times to come around again, too.
> Meaning doesn't mean much, but learning to love and be happy is (from what I can gather) far more important...
Thanks. This hits me hard. I think I've been focusing too much on "meaning" (and trying to do the meaningful things, etc) and over-exhausted myself. I think I need to practise loving and being happy more. That turns out doesn't come automatically.
Maybe you don’t need to completely mitigate those vibrations and they’re just a part of moving through life as a human. A very related image that stuck with me is “run on the engine, not the pistons”.
Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning. If you're using sprints and not kanban, the "cycle time" is fixed, and only the amount varies (approximated inexactly by story points).
This statement FTA is completely antithetical to agile development:
"A manager who wishes to make their team’s cycle times more uniform can try matching the rate at which tasks enter the system to the rate at which they leave."
On an agile team, "the manager" doesn't moderate the work rate; rather, the team measures their own work rate (approximately) via velocity and manages themselves accordingly.
> Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning
It's nice in theory. Usually once these metrics exist, PMs and other managers get a hold of them, and they always seem to turn into hard deadlines or interpreted as predictions with high certainty.
Kanban is an alternative to sprints, for contexts in which the team is persistent across projects and it makes sense to let them manage their work apart from the projects that they contribute to---e.g., an ops team that supports the organization via a help desk and ticketing system.
You could certainly think of the sprint board as a kanban board with a finite lifespan, but I don't think there's any benefit to doing so.
There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog. Rather than predicting what you will get done (and invariably failing to predict well, or using developers own predictions as their accountability and a way to pressure overtime), perhaps just see what you get done instead. Then instead of planning, actual work could get done. Anyone needing estimates can look back historically and compute number of tasks getting done and extrapolate against the backlog.
By keeping the backlog prioritized at all times, and pulling from the backlog instead of a 'sprint backlog' - it avoids priority inversions. Planning what will be your highest priority, that possibly changes mid-sprint, is a priority inversion.
Kanban works well in all situations where sprints work well. Instead of trying to predict in a planning, you just do the work instead. Any predictions are still the same based on looking at historical data and comparing to the backlog, just less waste involved and less subterfuge to try and get developers to work overtime (I'm not aware of any sprint planning that really takes into account error bars, so the prediction/planning is BS & management planning porn, nothing more)
You can't really do this without having some idea of how long each item in the backlog will take. If feature A is twice as valuable is feature B, should A or B come first in the backlog? Depends if A takes the same time as B, or four times as long.
(ignoring various other considerations about how you prioritise, and just focusing on delivering value here)
This is why rough estimation is part of the planning process in XP. The developers estimate stories so that the product owner can prioritise them. The estimates don't need to be precise, just roughly right relative to each other, to act as a denominator.
Since the developers are only pulling from the top of the backlog, the product owner doesn't need to prioritize the whole thing, just enough to keep the team busy. That means the developers only need to estimate stories which the product owner is considering for prioritization.
You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. But that would involve everyone interrupting everyone else quite often. So typically, you get together once a week and do this until you have enough stories to keep the developers busy until the next get-together.
You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity.
Sure you can keep your backlog prioritized at all times. Prioritization can be net benefit, or can be net ROI, the choice is yours! If you find out that item A will take half the time, perhaps that will boost its ROI and change its position in the queue. If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes.
Nothing in this way of defining priority is really any different between scrum & kanban. Perhaps the only key difference is when work is allocated to be done, scrum often focuses on 'how long will it take' to avoid "assigning too much to one sprint". Hence, a low ROI item could certainly be fit into a sprint simply because of time constraints, even though it might be really low on the overall ROI list (thus a priority inversion where the wrong thing is worked on simply because it fits an arbitrary time period).
> You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next.
If you have your backlog prioritized (or at least deep enough you can pull work for a while), then doing this continously is cake. The developer pulls from the top of the backlog. When a new task or a story is introduced, it is stack ranked. When and how often you introduce new stories in kanban is really up to you. So it need not be a constantly disruptive process. Typically new stories are looked at on a daily basis, which allows for a lot of responsiveness. At the same time, if knowledge changes about a story, it's priority rank is changed right then. It does not take very long to do stack ranking.
> You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity.
Tl;dr, velocity makes some interesting assumptions and uses bad math
Velocity does not take into account error bars. This is bad math! Each story has an error bar of give or take 30% (assuming it is well estimated with Fibonnacci). EG: An '8' could be a 6.5, or could be a 10.5. Yet, somehow by adding up the expected size of stories together the overall accuracy increases.. This is an oddity and bad math. Velocity should always be reported with a plus or minus, yet, it doesn't.. Somehow all of math behind propogation of error is assumed to cancel out. Beyond bad math, velocity only says how well you did last sprint, and "past performance does not guarantee future results." In short, velocity assumes that people can estimate. The only tasks that will have reliable estimates are ones that are very similar to something you have already done many times (eg: how long would it take you to brush your teeth with this new electric toothbrush? You know how long it takes to brush teeth with a convention toothbrush, so your estimate would be pretty good). But let's say, how long will it take you to learn Electromagnetism? Cool, you just learned that, how long will it take you to learn Calculus III? If you've taken Calc I and II, you would perhaps have something of an idea, but you're still to be really way off on estimating that.
> Since the only purpose of velocity is to know roughly how many stories to prioritize in the backlog, none of this matters in the slightest.
Given error bars are not taken into account, the proposition is that velocity is incredibly inaccurate. Presumably, most of a backlog is prioritized (otherwise a high priority story could be at the bottom, leading to priority inversion). I thought the purpose of velocity was to know commitment size for a given sprint (how many stories to bring into a sprint). Given that the inaccuracy of velocity is not taken into account, nor the compounding of the uncertainty, knowing how much to commit based on an inaccurate value leads to a lot of "failed sprints".
Re: prioritization, how you evaluate priority is completely up to a team. Anecdotally, Maesk ran agile and did not take into "cost of not completing a story". By that measure, there were three stories that were worth over 100x all other stories combined. Yet, they delayed deployment and efforts of these stories in order to "fit" in other stories that had low effort. Logically, with that large of a benefit, they should have stopped literally everything else and gone all in on those 3 stories. If you're really interested, I can try to dig up the youtube talk that went into this anecdote. The speaker in that video also noted that the data they looked at suggested the benefit of stories usually was magnitudes more than the level of effort. Hence, at times it almost does not matter the level of effort since the return is a better proxy for overall value.
Prioritisation can be whatever you want, scrum does not say what 'priority' means. That can be as silly, or as complex as you want. There are many inputs to priority. In practice there seems to be an over-emphasis (near-obsession) over 'cost' rather than value provided. A good example of this are items that have deadlines to them. At some point, the "cost" of implementation is not the biggest factor, yet it often gets the most attention and time allocated (vs say, dollar cost of not implementing per day)
My point with velocity is that it is inaccurate and using it will be just wild guessing. It's like saying, it's 65 degrees out - "cool, I'll wear a t-shirt". But, it's 65 degrees out plus or minus 30 degrees. As an engineer/scientist, we should already know that any number should always have error bars reported, otherwise it is meaningless. Similar to the temperature, you can look outside and infer the temperature through other means. It is likely then that "velocity" is noise compared to the true means we use to know if we have enough in the near backlog or not. Worse yet, velocity is often used as a cudgel to force overtime and declare a sprint "failed," even though velocity is so uncertain (yet is not treated as an uncertain value).
>There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog.
The purpose of sprints is not to divide up the work---this is a common misunderstanding. The purpose of the sprint is to set incremental goals based on incremental learning. So instead of setting a goal to create the complete software system from the beginning, you set a goal that can be accomplished within a fixed timeframe that people can make reasonable estimations in and that will test some of your key assumptions about the software.
Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure, since there is no opportunity to reflect on the larger picture: the team is too busy focusing on the assembly line and not paying attention to the product. And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong.
As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
> So instead of setting a goal to create the complete software system from the beginning, you set a goal that can be accomplished within a fixed timeframe that people can make reasonable estimations in and that will test some of your key assumptions about the software.
In Kanban you can do all of that, except faster. Instead of waiting for the arbitrary sprint boundary, you can immediately evaluate an item that has landed in production and immediately re-prioritize the backlog based on any learnings. That would be compared to: we will deploy this in sprint A, then in B we will see the results, and then in sprint C we will work on our updated items. The latter is a many week delay compared to assigning tasks in strict sequence of "ship/measure/adjust".
In the worst case, you ship at the beginning of a sprint and then instead of working on the next priority thing (that you learn from having shipped), you instead keep working on the other sprint items. At that point, it could be waterfall, working on items that you now know are pointless, but you still have to anyway because it was planned some time prior to do so.
Kanban doesn't forbid regular retrospectives. You can still pause frequently, reflect, and update your process accordingly.
The purpose of sprints is to try to estimate the completion of a release -- and as progress is made the drift from that original prediction. Sprints in theory let a manager estimate a team velocity. Together with estimates for the task in a release, that, in theory, gives one the ability to predict when a set of features (a release) will be complete. I have yet to see this actually work, but it could just be reflective of where I have worked.
>The purpose of sprints is to try to estimate the completion of a release -- and as progress is made the drift from that original prediction
This is not the purpose of sprints. The sprint is a fixed increment of time intended to encourage incremental development of complete software systems. The idea is that while people don't have an intuitive idea about how much work will have to go into developing a complex application, they do have an intuitive feel for how much work they can accomplish in a couple of weeks. So instead of asking, how much time will it take us to implement a fixed set of features, the team will be asking how many features can we implement this sprint?
>Sprints in theory let a manager estimate a team velocity.
A manager is not a consumer or producer of team velocity. The team itself is the only legitimate consumer and producer of team velocity. Agile is about team self-management.
This idea of asking how much can be implemented in a given sprint is an important clarification. Though, this can be impractical and/or sub-optimal for many contexts. The one-size-fits-all approach of scrum, where so often it is a company or a new person joining and just declaring that "we'll do scrum" now is where things can get de-railed because it is not the universal way to do all development.
So, to paraphrase the distinction, instead of death marching for a large set of features without any feedback, the team decides "we won't do more than 2 weeks of work at a time before we ship & deploy some feature."
(I really wish I could find the link) A recent hacker news article looked at this situation and noted how this does not really allow for extensive R&D where there is no deliverable after the end of two weeks. An example was Google BigTable which had no deliverable at all for 8 months. Yet, the investment into BigTable lead to a very huge pay-off, and the point made was that there was no good way to break up the R&D required into two week deliverables, and the ROI of that work was far more than most any 2 week increment.
Overall the issue for scrum is context, it has its places where it works well - but it is not the one-size fit all solution that so many places try to make it out to be. For example, two weeks does not always allow for a lot of rework, experimentation, architecture, and R&D. A team can choose to make a deliverable be "the results of R&D", is this still fungible thinking and is not actually delivering a release.
Personally I would be a lot happier whenever a scrum master and/or product owner/manager that run a scrum team could clarify exactly when scrum is a bad fit (this feels like the expert-beginner problem). If a person knows when scrum is a bad fit, they can at least try to mitigate those problems and/or lean on other development methodologies. It is almost like silo'ing into one programming language and using only that language despite it not being the best tool in some situations (and also of detriment, various alternative techniques are not learned; eg, sometimes a bash script is the right tool to use, and not branching out and trying to solve some problems with a full blown programming language leads to a lot slower of a solution. To illustrate this, Amazon once had a team spend time to find all phone numbers on its website. This took a long time and the program was complex and never worked well, a very competent shell scripter got wind of this and solved it in 15 minutes with a bash one-liner. This became an interview question at Amazon at one point even, in part to check if a candidate will realize that their language of choice might be a bad fit for the problem at hand)
Breaking a story down into smaller stories is not the same as incrementally developing a complete system. This is the difference between reductionism (breaking a large pre-defined project into smaller pieces for execution) and holism (always delivering a complete system, but incrementally extending the functionality as the team learns more). Sprints provide the time increment for the latter. Note that a sprint increment may differ from project to project. But most teams find 2-3 weeks to be a good increment.
Even in a reductionist approach, though, sprints provide a regular opportunity to review the appropriateness of the breakdown or the validity of the parent story.
You make a really good point on the importance of having a complete iteration at the end of the sprint.
In my experience, the fixed time increments have always felt too constraining.
I think a team can accomplish a similar goal of having regular incremental progress in the form of complete systems by relaxing the fixed-length sprints requirement.
The alternative that I favor is Kanban with defined releases. A release, as a collection of features, is a complete system, but it doesn't necessarily have to be finished in the same time that the previous release was. A larger release may take six weeks instead of the smaller previous release that only took one.
You make a lot of good points, thank you for sharing your thoughts.
General reply to those who say, "but you can have planning and retrospective in kanban!":
Sure, you can. But it requires discipline to actually do it. It's very easy to get wrapped up in a task that runs over, and when you multiply that tendency by everyone on the team, the idea that it will actually get done regularly in practice is optimistic, to say the least. And if you are doing it regularly, together as a team, is that really so different from a sprint?
Conversely, the notion that you can't change course mid-sprint is simply wrong---you absolutely can. The concept of sprint commitment is an acknowledgment that there is value in completing something workable, even if it's the wrong thing, as opposed to staying constantly in a state of WIP. But if it's obvious you're doing something no longer needed or technically feasible, nothing in scrum says you have to complete the sprint as planned.
That incremental goal is not mutually exclusive to kanban. The difference is whether you are stating at the beginning what goal you will hit, vs just working towards that goal. It's the same thing, one creates pressure to hit inaccurate estimates, the other just marches towards the goal.
> Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure
Why is that? Scrum has the same backlog.
> since there is no opportunity to reflect on the larger picture
Why is this the case? Kanban often says that you talk about retrospective items any time they come up. You then even can re-prioritize such items right when needed, meaning you solve todays problem today, not tomorrow. Retrospectives in scrum can often come too late (and personally I've never really seen them work well, too little, too late, and often compete against 'business' priorities that always win out).
> And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong.
Kanban is less susceptible to priority inversion. You keep the highest priority at top, it is evaluated more often, and you pull from the top. Why does this mean that months can go by? Why is that any more the case than say scrum where you are encouraged to fix priority for weeks at a time?
> As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
I think the burden of proof is on you to state places where scrum uniquely bests kanban. The statement that kanban is best for places where ad-hoc work comes in constantly is a case where scrum spectacularly fails. For regular project work, kanban can be a great fit (I'd say universally better than scrum, since planning is just complete BS. Kanban is often little more than scrum without the planning sessions and with far more frequent prioritization, and you get to keep all of the same retrospective & estimation tools)
I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban.
But I'm confused by this statement:
>planning is just complete BS
To me, planning is where design meets reality. Planning involves several activities, but probably the most important is prioritization. I'm curious why you think that prioritization happens more frequently in kanban, where the convention is to simply take the next task off the stack. Are you saying that every time someone takes a task off the kanban backlog, they independently re-prioritize the entire stack? Or do you have regular re-prioritization sessions with the team? If it's the former, that seems like a lot of overhead and opportunity for conflict and misunderstanding. If it's the latter, how is that really different from regular sprint planning? Because surely, as part of the prioritization, you would also consider things like estimation of difficulty and risk.
... for contexts in which the team is persistent across projects
and it makes sense to let them manage their work apart from the
projects that they contribute
Here I disagree only in applicability. Kanban can be successfully used in a single development project if the team maintains prioritized tasks based on risk and/or dependencies. To wit, a development team with sufficient maturity can identify and plan their work, address same in the requisite order, and have confidence that the probability of success will increase as each task is completed.
Prioritization is an output, not an input, of the scrum process. That's the whole point, to engage the user early and often so that information about the desired functionality can be derived from experience and not just speculation, and then fed quickly back to the team for iteration.
So sure, if you:
- release usable software
- collect feedback from stakeholders based on the release, and
- re-design and re-prioritize the perceived work remaining
on a regular basis as a team, then you can use Kanban for a single project. But it will look an awful lot like sprints, because it's hard to do all that on a continuous basis, it would be a lot of overhead and context-switching to do it daily. On a project of any size, you'd have to do it all periodically. Say, every couple of weeks.
Kam is basically a big to do list (aka backlog) and you just work through it. I find it way easier to manage than scrum with sprints and sprint planning.
It's much easier to simply hit the accelerator and drive straight ahead, too, but you wouldn't win many F1 races that way. And most software projects are a lot more complex than an F1 track.
Sometimes the easiest thing to do is not the best thing to do.
I don't think F1 is a good analogy. In any case, I prefer to deal with complexity directly and not add more complexity in the form of sprint planning, velocity and other stuff. Maybe some people run scrum well but I have yet to see that.
Two cars are driving from A to B. Ideally they want to get there as quickly and efficiently as possible, without driving dangerous or stressing the cars.
Car 1 takes 15 hours to drive from A to B.
Car 2 takes 10 hours.
Why is that? Well, car 1 has a 1.3l engine and took a wrong turn because the navigator can't read a map.
Car 2 stopped 3 hours in because it had a flat, but they got going again much faster.
The speedometer won't tell you any of those things. It can't tell you WHY you're going slowly (you're under-resourced or you have a problem that needs fixing) or if you're going the wrong direction.
That doesn't mean it's useless. It can still tell you if there's a problem, or if you appear to be doing well but you're not making any progress, maybe you're going the wrong way.
I really appreciate the depth and explanation in this article. In my many years in the industry, I have yet to see such rigor coming from task maintenance as is displayed by the author.
For starters, tasks require deep knowledge of how something will be done. In our industry, a lot of the work is discovered while executing some other work. What you get are tasks being created while other tasks are being worked on. This back flow of work would also have to be captured as part of the process with the additional metric of how well we plan our work and hold people accountable to that result.
Since software engineering is part art, industrial processes are inadequate in capturing the productivity of software engineering work. Instead, a lot of focus is on the ability to estimate overall completion dates, adherence to that schedule (often requiring evaluation of compromise and reduction of scope), and the impact of that work (both positive in a measurable way, and negative in code debt and incidents).
What's unfortunate is that a lot of infrastructure work focuses on improving engineering cadence. Without the process described in this article, measuring productivity gains from introducing a new tool or technology can at best be measured using adjacent metrics (e.g. compile time, deploy time).
I hope one day we can reach the level of engineering rigor prior to execution described in this article, but I still believe that the nature of software engineering is that there will be a non-trivial amount of immeasurable effort that doesn't fit the model described in the article.
OK, this is actually a really good and insightful article hidden behind a provocative title.
I will say that “velocity” is an extremely helpful concept at the level of the individual and small teams. With my trams I challenge each engineer to try and batch work into 2-4 hour chunks, with each chunk being labeled “1 point.” Thus if we have an ideal week there are theoretically 10 points of “velocity.” We also try to batch up meetings etc. and discount the coordination overhead from the plausible output, so maybe the theoretical ideal is lowered to 8-9 points. We all discuss and agree on that based on whatever overhead we can’t eliminate.
Then each engineer does their best to “call their shot” every week and say how much work they’ll finish. At the end of the week we compare their prediction against reality, using a burn-up chart as a visual aid to the flow of work. There’s no penalty for getting it wrong, just applause for nailing it, and always a discussion of what worked and what could have gone better.
Following this habit, I have consistently seen teams get much better at forecasting work into the future accurately. This ability to have a steady velocity and make reasonably accurate forecasts about how long things may take is extremely valuable and helps us align and coordinate efforts across many teams.
This is why people prefer remote work. Seeing coworkers in person is nice, for sure. But management still assumes people work 8 hours a day, meaning office workers spend most of their day trapped in the office pretending to work, which is a huge waste of time.
I've found this isn't true for myself and for many others. If you are getting good, deep focus time then you can generally get one productive stretch in the morning, take a good long break, and then do one more productive stretch in the afternoon. We can be pedantic about it and say "well the sum total of truly deep focus time was probably not more than 4-5 hours" and that may be true, but it's also not a realistic take on the context switching and ramp up time that it takes to get into that flow in the first place.
Also don't underestimate how many shallow tasks there are that somebody has to do to keep the lights on. We try and eliminate as many of these as we can, but it's just not cost effective to eliminate the entire long tail. So it's pretty common to have the morning focus session be true "deep work," and the afternoon session be a batch of minor stuff like small bug fixes, updating dependencies, running some tests, etc.
- 1 hour misc, like coffee breaks, bathroom breaks, walking between meetings, etc
I think a lot of managers fail to account for everything else employees have to do, so “four hours of deep work per day” doesn’t sound right… even if it is. Of course, a lot of managers also just push their team into working more than 8 hours per day.
I'm generally extremely allergic to time-based micro-estimation like this, but it sounds like you've got the rare healthy implementation of it. (Or as healthy as it can get, at least.)
Two questions, if you don't mind:
1. One of the biggest dangers of time-based estimation is the cultural danger around the "penalty for getting it wrong." It's got quite a lot of gravity to it, in my experience. Once there are time-based estimates for tiny bite-sized amounts of work, it's a hop-skip-jump to the toxicity of "holding people accountable for their commitments."
It sounds like you, as the team manager, are the one preventing this backslide. How do you think about maintaining a healthy culture around this when you go on vacation, get distracted, get promoted, etc?
2. What if a new discovery happens mid-week? Specifically, what if it's the kind of discovery that invalidates the current plan, so that finishing your "committed" work would be worthless (or actively negative) for the business?
I echo your concerns. On teams I've been on (exclusively at large, boring organizations), I've seen a tendency to create lots of really trivial tasks, and also to game things via pretending these tasks are more complex than they are.
It's easy to nail your estimations when you're operating at 1/3 your capacity, and you only ever meet but don't exceed the planned velocity.
I wonder if this also disincentives learning and innovation in the solution domain - because that would throw off all those estimates.
This is addressed by batching into same-sized chunks - the engineers discuss the work plan as a group and if you give yourself ten tickets that everyone knows are tiny and should probably be done in an afternoon, the group will ask you to group it into a parent ticket to make it a "half-day" chunk of work.
(1) This is part of blameless culture, and it can't work without everyone being bought in, so once it is established and working culturally it doesn't matter if one person on the team changes. In the same way that we "hold people accountable for incidents" by reviewing them and discussing what we could learn, we do "hold people accountable for their estimates" by asking what happened and reflecting on whether we could have seen that coming. But we're never perfect and we don't expect to be, we just try to see if we can get better over time.
(2) When something unexpected comes in you flag it and report it to everyone so everyone knows the expectations are invalidated. This is super important! I can't even tell you how much easier it is for a PM or other stakeholder to handle learning on Tuesday that the plan is not going to work than showing up for a check-in the next Monday expecting to see some deliverable and only then learning that it's late. The goal is to communicate expectation changes as close to real-time as possible, which builds trust and also helps the non developers see how volatile and unpredictable development can be so they learn to believe you when you say "the range is 10 to 30 weeks, and no I can't narrow it down any more than that."
This sounds sensible and effective, and fairly similar to experience on effective XP teams.
Two things are different to the XP approach. Firstly, you track expected work capacity at the level of individuals, rather than the whole team. Secondly, you use estimates of work capacity, rather than the "yesterday's weather" approach of assuming it will be the same as last week.
Do you think there are advantages to doing it your way?
Sorry if I wasn't clear, in the method I'm describing each engineer is tracking and forecasting their own capacity one week at a time. We discuss it briefly as a team to gut-check each other's forecasts and learn from misses as a group. Misses are almost always unexpected interrupts, so talking about what did we fail to see last week and then checking what might we be missing in the plan for this week is the essence of the whole thing.
Having never done XP I can't say if the differences are better, I can only say that this basic approach works pretty well :)
> Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or how to fix it.
Specifically, it assumes that there is that one metric out there than can answer the “why” and “how” questions.
In reality there is none, even your proposed CFD (which I use myself) doesn’t really answer them. Instead what these metrics do is answer the “what” question. Specifically, they signal to the team that something is wrong and they need to dig deeper to get to the bottom of it before arriving at a solution. In fact, one of your examples skips this very important step:
> A manager who wishes to make their team’s cycle times more uniform can try matching the rate at which tasks enter the system to the rate at which they leave.
How did the manager know that this was the correct solution. Perhaps they went further, asked questions, and maybe even consulted stakeholders instead of just looking at the CFD and go “Ah! I will control the arrival rate!”
This would’ve been the same with burnup/down charts provided that the user of these charts knows the probabilistic nature of these metrics.
In the end, it’s not the charts/metrics that matter the most but the person interpreting them.
With all measures that are applied in management contexts I find that the mistake people tend to make is that there is a linear relationship between the measure of work and the financial measures (revenue, profit, margin, etc.)
Velocity seems like a simpler measure than a Network Queue, and both seem like they are valid measures since neither will have a linear relationship with the bottom line of the company.
The goal of the entire business is to tune all the parts of the business and seek out an efficient solution.
The theory of constraints as it is quoted in this article isn't advocating for rate matching everywhere in the business specifically. Rather it is making the statement that some inputs and processes in the business have a disproportionately large effect on the business outcomes. And you should weight management priority to the processes that affect your outcomes the most.
If you have a process (say deploys to production), that dramatically affects your business outcomes, in the sense that small changes to this process lead to large changes or even most of the changes in outcomes (e.g. revenue). Then most of the resources should be allocated to optimising that part of the business, since resources allocated anywhere else will be wasted, since the magnitude of the effects (even assuming they'll still be positive), will be dwarfed by your most sensitive inputs.
The theory of constraints preaches that after you have chosen your most important business outcomes (a strategic decision), you should measure how much the different inputs to your business affect the outputs of the business, and allocate resources to the most sensitive inputs.
Most big businesses do this very well. It's why you can find yourself in a team where doing more work or less work doesn't seem to matter, even though your direct manager is up your ass all the time.
"Contrary to popular belief, Kanban cards do not refer to the cards (or post-its) on the Kanban board. Instead, they refer to cards that folks in one segment of the manufacturing process would send to the previous segment to indicate they’re ready to receive more work"
The wikipedia link that you provided doesn't say this. It says:
Which is quite different. The card is sent from the people who need the work to the people who deliver the work and not the other way around like you claim.
The post claims that the cards originate from the people who perform work and are sent to the people who need it. That's not consistent with the definition from wikipedia (or any other source).
People take velocity too seriously. Generally speaking, it helps you identify how much work the team typically does so you can ensure you have at least that much refined for planning the next sprint. That's pretty useful... depending on the circumstances
Velocity is a useful engineering management metric, but solely for the Product Owner's discretion in informing the Business when some particular functionality or set of value can be delivered, based on an ordered, story-pointed backlog.
It's essentially a long term weather forecast. Don't plan your beach vacation for November; don't plan to launch Product Feature X before we could have it done. "Velocity" makes it sound like it's measuring your productivity now, but it's more of a general forecast of the future. And absolutely nobody should be looking at it but the PO.
Velocity metrics and burn down charts tell you something is happening. It's purpose is as an indicator of something trending right or wrong. It doesn't preclude good design and architectural analysis and product feature prioritization. If you don't have direction for the velocity it is meaningless. Unfortunately many a times its just a number to berate dev. teams on their productivity. That was not its intent. I forget who said it but - the road to hell is paved with good intentions :)
I've had the exact opposite experience. Velocity has helped my teams multiple times. It gives a sense of how much productivity drops when we add new members and if we don't recover within an expected time then we know something is up. It's also used as a rough early indicator that projects are running late and that there's no way we can hit expected time lines. Teams escalate and get alignment across the larger org on how to handle it (move dates, get additional help, etc.).
> Velocity metrics are as loathsome as the horoscope because neither provides any insight on why something went wrong or how to fix it.
This is such a weird statement to me. Of course it doesn't tell you why, it's just data. It's up to anyone that works with data to figure out what's going on.
I’ve found talking to my developers regularly tells me when there are issues and what they are, and we can solve the issues together. While I could have seen the trend in a velocity chart the act of collecting velocity data is both time consuming, tedious, and feels like micromanagement to those being measured. I have literally never seen a velocity chart tell me something more easily observed by taking team and individual temperature consistently. I’ve found managers who depend on metrics to be terrible at empathetic listening, and I avoid hiring them.
Absolutely agree on the empathetic listening. But there are definitely times when devs come to be and no amount of empathetic listening is going to get to the room of the problem. Like when things are moving slower, why dates are being missed etc. And no amount of empathetic listening is going to be enough data to go to leadership to argue why things are off, why we need to delay things (and delay other teams), and build any sort of trust that you can reasonable manage the work for the team. But this may be limited to working at a FAANG company where projects span 100's of developers and any shift needs to be backed up with a lot of data about what's going on.
No amount of velocity measurement will either. My observation has been time estimation is often precise and people confuse precision for accuracy. If dates are being missed I evaluate carefully the decisions made given the information at the time and understand that as long as decisions are being made well stuff doesn’t always move at the pace we expected or desire. I don’t need fake velocity data to argue for time, people, or prioritization with management because I can actually explain what’s going on in my organization. Btw - I’ve been in FAANG as well as other large software development orgs with 60k+ developers for my entire career. Nothing beats steady and rapid delivery, but I occasionally do have to move teams to avoid micromanaging scrum waterfall agile folks.
Martin Fowler, who I had the pleasure to know back in the XP days, says:
“Agile Development is adaptive rather than predictive
is people-oriented rather than process-oriented”
Reconcile that with agile as you understand and practice it - the entire point of measuring velocity is to be predictive. How on earth is that agile? How many process and planning oriented ceremonies do you go to? Does my empathetic listening approach sound more people oriented or OP’s “I’ll fire you if you aren’t burning down points” approach?
All great points. And it's becoming clear that we are using different tactics to reach the same ends. I've laid out how it's useful for me, you've laid out a another approach. Circles back to my original point - my experience has been different from what the author says and we just add in that you go about things a different way too. Looks like there's more than one way to achieve things which isn't terribly surprising.
This is a really misguided opinion but possibly based on working with misguided managers. Velocity in traditional scrum-style agile is metric of product completion. If you're doing point estimates or the like and you've sized your MVP at 128 points and you've completed 64 points with 180 developer-days then you are 50% done and can project completion in another 180 developer-days. That's what it's predictive of. Saying it doesn't explain why your velocity is your velocity is a big duh. It's not supposed to. It's the primary indicator of progress. If velocity is too slow then you go figure out why or what can be done. If you're on time or early, then great.
Interesting article. I find the following quote to be a bit odd - though in the context of "what makes a good metric", towards the end, it makes more sense:
> Besides telling you that “velocity is low,” what else does a burndown chart reveal about your team’s bottlenecks, problems, and inefficiencies? Nothing.
I mean - it's good to know there's a problem (deadlines won't be met), right? It might not answer why, but it certainly allows you to ask why.
I'm also a little confused about what definition of velocity the article argues against while promoting a form of velocity called cycle time/avg cycle time; which seems to mesure how long tasks take to complete?
velocity is a vector and by rights should include angle as well as magnitude
if your measure of velocity doesn't rate direction (i.e. 'quality of goal') as well as magnitude ('how quickly you are getting there'), at minimum it needs to be renamed
ok that was a really long and involved article, I will admit I didn't read the whole thing. If the punchline is the inverse of the title, then jokes on me.
afaik most agile systems are pretty clear that cross team velocity is non-comparable. (if if teams are shuffled the velocity will change).
But, the one thing it's meant to be used for is estimates. After sufficient iterations of the loop a team should both have increasing velocity (due to knowledge of codebase), and increasing accuracy of estimates (both dialing into sprint point / effort tuning, and knowledge of codebase) .
afaik velocity was never meant to tell you about how to improve itself. Thats more for Retros. (retrospectives)
ok, obviously not forever... surprised you didnt mention eventual death of the contributors, heat death of the universe et al.
Jokes aside, yes there is some asymptote of peak velocity that will reach. But keep in mind that some amount of effort can actually increase velocity in a net profitable way given long enough time windows... cue the table of automation from xkcd[1]. Imagine if we're playing with legos, and instead of using the smallest units I start to build with bigger blocks? I can build the same house by placing fewer blocks (analogy-- faster) .
My biggest complaint about velocity is that most people I've worked with don't actually think of it as velocity, they think of it as speed. The vector aspect of it is often ignored, and of course if you're going fast in the wrong direction that isn't particularly helpful.
Trying to model velocity as a "metric" also bakes in A LOT of assumptions. If the right cards aren't being created, or if the backlog isn't being prioritized correctly then what you are attempting to measure isn't even velocity (or at least not the specific velocity in the direction you ought to care about).
That was a fairly typical response, when I talked about having issues meeting deadlines. The Japanese did stuff like that, all the time, in hardware, but it didn't work, for software.
I have found that I am best off, trying to establish a structure that allows each engineer to work alone. That's difficult to do, when you have a complex, hybrid system. Usually, it meant lots of small tasks, with clear coupling and API specs.
If even one additional person is added, the whole thing slows down exponentially.
I think Devlin Henney complains several times about story points per week being a graph that plots time on both axes, which does not make any sense at all.
It’s predominantly recording point inflation over time.
I disagree that velocity is a terrible metric. I think a more comprehensive suggestion from the article could've been to use velocity in conjunction with other metrics. Perhaps with the ones the author points out in the article.
Measuring things is hard. Most of the time when you measure something there will be a loss of information. Velocity, in the context of software engineering, is no exemption. However, this doesn't mean that it can't be a helpful signal.
> Besides telling you that “velocity is low,” what else does a burndown chart reveal about your team’s bottlenecks, problems, and inefficiencies? Nothing.
I’ve been in “The room where it happened” a number of times, and this question just reveals that we have collectively forgotten what a burndown chart is for.
The point of a burndown chart is that management is asking the wrong questions, and you’re giving them something that looks like what they asked for but invites a bunch of uncomfortable questions later on. It’s insidious, in a useful way. What we’re trying to show is that wishy washy decisions - from management - keep moving the goal post and costing us hundreds of thousands of dollars. Potentially millions. It’s an up-management technique in the right - or even passingly competent - hands.
The mistake we made is in thinking that putting a mirror in front of somebody will lead them to improve. But what happens when you put a mirror in front of a narcissist? They thank you for your help getting that stray eyebrow hair to lay straight, and then change the subject.
Not sure if this is mentioned in other comments but in my work it seems relevant to “keep an eye” on velocity but not worship it. Hopefully it stays pretty consistent in general but if there’re are big swings maybe it’s reason to check out other process items.
Velocity metrics are good when treated as a symptom of other issues. They are particularly good at detecting engineers who don't know what scope means.
This is a qualitative process, though, and using velocity metrics from your project management tools is like looking for your lost keys under the streetlamp because that's where the light is brightest.
It is also important to recognize the importance of keeping slack in a system and not over-optimizing it, as explained in Tom DeMarco's excellent book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.