25 ms·

Useful engineering metrics and why velocity is not one of them

241 points by lucasfcosta 4y ago

mkl95 4y ago
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.
vcryan 4y ago
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
fmajid 4y ago
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.
- jdgoesmarching 4y ago
  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.
- geekjock 4y ago
  "Using velocity metrics is like looking for your lost keys under the streetlamp because that's where the light is brightest." ^ 100% agree. Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes. Metrics like cycle time get a little bit closer, but still fail to account for team context or surface root causes.
  - jrumbut 4y ago
    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.
  - Supermancho 4y ago
    > 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.
- pierrebai 4y ago
  > 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. One useless metric though, is snark.
  - tanseydavid 4y ago
    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).
    - arealaccount 4y ago
      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.
- Retric 4y ago
  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.
  - myownpetard 4y ago
    > "Velocity ignores direction". 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.
    - Retric 4y ago
      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.
    - atoav 4y ago
      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.
      - myownpetard 4y ago
rufflez 4y ago
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.
- tra3 4y ago
  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.
  - djbusby 4y ago
    Q: how long will this take? A: what is your budget? What other work will you sacrifice?
  - tadfisher 4y ago
    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.
    - cortesoft 4y ago
      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.
OrvalWintermute 4y ago
Maybe I am biased because I've attended spacecraft & sensor engineering design reviews for much of my career. But this does not look like engineering; looks more like statistic process control applied to software dev Not engineering!
- lucasfcosta 4y ago
  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
  - 8note 4y ago
    Swapping "engineering" to "software management" would be clearer. Velocity has a strong definition in engineering that has been borrowed and misused in software management. I expected the article to be about accelerometers and how the ill effects of vibration have been mitigated
    - archibaldJ 4y ago
      > 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.
      - q7xvh97o2pDhNrh 4y ago
        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.
vannevar 4y ago
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.
- hbarka 4y ago
  Isn’t kanban a tool within sprints?
  - vannevar 4y ago
    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.
    - seadan83 4y ago
      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)
tootie 4y ago
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.
- spaetzleesser 4y ago
  The problem is that these estimates and projections often get converted into hard commitments by management.
  - tootie 4y ago
    That's a problem. People making mistakes is a pretty common disease.
orangesite 4y ago
Fantastic work Lucas, beautifully explained! Is this currently being applied at your employer? Are you hiring? :-D
maerF0x0 4y ago
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)
- aprdm 4y ago
  That’s only true if the team is working in the same sort of problems
- mandeepj 4y ago
  > After sufficient iterations of the loop a team should both have increasing velocity The velocity cannot keep on increasing forever :-)
  - twic 4y ago
    It can if the estimates do!
  - maerF0x0 4y ago
    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) . [1]: https://xkcd.com/1205/ https://xkcd.com/1205/
opmelogy 4y ago
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.
- fnordpiglet 4y ago
  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.
  - opmelogy 4y ago
    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.
    - fnordpiglet 4y ago
dieselgate 4y ago
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.
burlesona 4y ago
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.
- q7xvh97o2pDhNrh 4y ago
  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?
  - switchbak 4y ago
awinter-py 4y ago
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
__t__ 4y ago
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.
kcexn 4y ago
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.
cgrealy 4y ago
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.
ChrisMarshallNY 4y ago
> like adding resources to an inefficient system 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.
carabiner 4y ago
Any mechanical engineer is very confused by this headline.
- fezfight 4y ago
  I was tremendously confused as a Canadian mechanical engineer.
amelius 4y ago
Perhaps momentum makes more sense.
wefarrell 4y ago
"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: "The kanban card is, in effect, a message that signals a depletion of product, parts, or inventory" https://en.wikipedia.org/wiki/Kanban#Kanban_(cards) https://en.wikipedia.org/wiki/Kanban#Kanban_(cards) 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.
- Normal_gaussian 4y ago
  These are consistent definitions; they talk of production line style work, not heirarchical work assignment.
  - wefarrell 4y ago
    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).
a1445c8b 4y ago
I have a problem with this premise: > 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.
thedougd 4y ago
Some myths of velocity and points: - Points are a measure of time elapsed. - Velocity between teams can be compared. - Points between teams can be compared. - Points are a unit of value. - Velocity has meaning or utility outside of the team, scrum master, and product owner. - Velocity measures or indicates individual productivity. - Velocity needs improved. Keep it simple, use it within your team to plan your next sprint and estimate when/what you can deliver.
- tanseydavid 4y ago
  This is very well put and reflects the proper viewpoint IMHO. And yet I still can hear some peanut gallery murmuring saying "Yeah, but, but..."
DSingularity 4y ago
There is no substitute for management that have insight based partly on experience and partly on direct knowledge of what the managed are working on.
ppeetteerr 4y ago
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.
deleted 4y ago
[deleted]
e12e 4y ago
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?
worik 4y ago
Engineering. Metrics. Velocity. I thought this would be about physics.
throwaway787544 4y ago
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.
gautamdivgi 4y ago
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 :)
deleted 4y ago
[deleted]
hinkley 4y ago
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.
hinkley 4y ago
> 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.
jrsj 4y ago
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).
langsoul-com 4y ago
Most engineering metrics seem to bank on linear models. All tasks past, present and future will at the same time.

241 points by lucasfcosta 4y ago

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.

vcryan 4y ago

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

fmajid 4y ago

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.

jdgoesmarching 4y ago
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.
geekjock 4y ago
"Using velocity metrics is like looking for your lost keys under the streetlamp because that's where the light is brightest." ^ 100% agree. Tracking output metrics (including LOC, # of PRs, velocity points) doesn't help you identify or fix poor tooling, culture, or processes. Metrics like cycle time get a little bit closer, but still fail to account for team context or surface root causes.
- jrumbut 4y ago
  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.
- Supermancho 4y ago
  > 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.
pierrebai 4y ago
> 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. One useless metric though, is snark.
- tanseydavid 4y ago
  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).
  - arealaccount 4y ago
    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.
Retric 4y ago
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.
- myownpetard 4y ago
  > "Velocity ignores direction". 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.
  - Retric 4y ago
    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.
  - atoav 4y ago
    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.
    - myownpetard 4y ago

rufflez 4y ago

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.

tra3 4y ago
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.
- djbusby 4y ago
  Q: how long will this take? A: what is your budget? What other work will you sacrifice?
- tadfisher 4y ago
  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.
  - cortesoft 4y ago
    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.

OrvalWintermute 4y ago

Maybe I am biased because I've attended spacecraft & sensor engineering design reviews for much of my career. But this does not look like engineering; looks more like statistic process control applied to software dev Not engineering!

lucasfcosta 4y ago
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
- 8note 4y ago
  Swapping "engineering" to "software management" would be clearer. Velocity has a strong definition in engineering that has been borrowed and misused in software management. I expected the article to be about accelerometers and how the ill effects of vibration have been mitigated
  - archibaldJ 4y ago
    > 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.
    - q7xvh97o2pDhNrh 4y ago
      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.

vannevar 4y ago

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.

hbarka 4y ago
Isn’t kanban a tool within sprints?
- vannevar 4y ago
  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.
  - seadan83 4y ago
    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)

tootie 4y ago

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.

spaetzleesser 4y ago
The problem is that these estimates and projections often get converted into hard commitments by management.
- tootie 4y ago
  That's a problem. People making mistakes is a pretty common disease.

orangesite 4y ago

Fantastic work Lucas, beautifully explained! Is this currently being applied at your employer? Are you hiring? :-D

maerF0x0 4y ago

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)

aprdm 4y ago
That’s only true if the team is working in the same sort of problems
mandeepj 4y ago
> After sufficient iterations of the loop a team should both have increasing velocity The velocity cannot keep on increasing forever :-)
- twic 4y ago
  It can if the estimates do!
- maerF0x0 4y ago
  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) . [1]: https://xkcd.com/1205/ https://xkcd.com/1205/

opmelogy 4y ago

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.

fnordpiglet 4y ago
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.
- opmelogy 4y ago
  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.
  - fnordpiglet 4y ago

dieselgate 4y ago

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.

burlesona 4y ago

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.

q7xvh97o2pDhNrh 4y ago
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?
- switchbak 4y ago

awinter-py 4y ago

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

__t__ 4y ago

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.

kcexn 4y ago

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.

cgrealy 4y ago

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.

ChrisMarshallNY 4y ago

> like adding resources to an inefficient system 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.

carabiner 4y ago

Any mechanical engineer is very confused by this headline.

fezfight 4y ago
I was tremendously confused as a Canadian mechanical engineer.

amelius 4y ago

Perhaps momentum makes more sense.

wefarrell 4y ago

"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: "The kanban card is, in effect, a message that signals a depletion of product, parts, or inventory" https://en.wikipedia.org/wiki/Kanban#Kanban_(cards) https://en.wikipedia.org/wiki/Kanban#Kanban_(cards) 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.

Normal_gaussian 4y ago
These are consistent definitions; they talk of production line style work, not heirarchical work assignment.
- wefarrell 4y ago
  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).

a1445c8b 4y ago

I have a problem with this premise: > 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.

thedougd 4y ago

Some myths of velocity and points: - Points are a measure of time elapsed. - Velocity between teams can be compared. - Points between teams can be compared. - Points are a unit of value. - Velocity has meaning or utility outside of the team, scrum master, and product owner. - Velocity measures or indicates individual productivity. - Velocity needs improved. Keep it simple, use it within your team to plan your next sprint and estimate when/what you can deliver.

tanseydavid 4y ago
This is very well put and reflects the proper viewpoint IMHO. And yet I still can hear some peanut gallery murmuring saying "Yeah, but, but..."

DSingularity 4y ago

There is no substitute for management that have insight based partly on experience and partly on direct knowledge of what the managed are working on.

ppeetteerr 4y ago

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.

deleted 4y ago

[deleted]

e12e 4y ago

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?

worik 4y ago

Engineering. Metrics. Velocity. I thought this would be about physics.

throwaway787544 4y ago

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.

gautamdivgi 4y ago

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 :)

deleted 4y ago

[deleted]

hinkley 4y ago

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.

hinkley 4y ago

> 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.

jrsj 4y ago

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).

langsoul-com 4y ago

Most engineering metrics seem to bank on linear models. All tasks past, present and future will at the same time.