3 ms·

Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should

by dartos 2y ago

Burn down charts, team velocity, and story points. They all exist to give software development the illusion of predictability, but saying that a project should take “x sprints” is just setting a deadline with extra steps.

PaulHoule 2y ago
There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.
- rerdavies 2y ago
  Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.
rerdavies 2y ago
Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?

by dartos 2y ago

PaulHoule 2y ago

There is nothing wrong with burndown charts but story points and team velocity are poison. The way you get good at estimating is looking at your database of experience. “I did a task similar to this in 8 days”. Calendar time is real and punchclock time is real, either can be measured. Story points are not real and not measurable and they leave you lost at sea thinking that estimation is impossible, a scam, etc. See also https://en.wikipedia.org/wiki/Function_point https://en.wikipedia.org/wiki/Function_point Which is also a kind of development “funny money” but which have a somewhat rigorous method to arrive at estimates.

rerdavies 2y ago
Agreed. Team velocity is a poison number. But entirely necessary in order to provide a data-driven approach to converting story points into time predictions (with appropriate disclaimer of risk) that people outside the team need. Data driven! How could that possibly be a bad thing? Maybe best to just treat it as a classified secret that nobody actually needs to know. People inside the team just need to know that their stories are arranged in correct order of priority. People outside the team actually do need time axes on their burndown chart. But they don't need to actually know the toxic voodoo that was performed to produce the conversion. :-P But actually seriously. Nobody needs to know that number.

rerdavies 2y ago

Right. So you don't do that. No development process ever has provided bulletproof predictability. Your job as a project manager is not to provide bullet-proof predictions; it's to manage risk, and expectations, and make sure that development work is correctly prioritized. And of course to keep your development team protected from external insanity, because happy, stress free development teams are productive development teams. (But that's a separate issue). Here's the feature list; here is where on the list we'll definitely get to, here's where on the list we definitely won't get to, and everything else is some shade of inbetween. Now, would you like to adjust the priorities of any of those features, or would you like to change the deadline?