The points are needed because it's convenient to do reports based off of it. If we used estimation language such as "easy, medium, hard, dummy-thicc" they'd still need to assign points to those labels so they can do math on reports and graphs to watch your performance
The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for no reason. I think even the slow developers rarely get fired, and you also get nothing for clearing more story points than other developers.
No bonuses for higher velocity is the real reason no one takes it seriously.
> points are needed because it's convenient to do reports based off of it
So, you’re saying it’s convenient for management, yes? Making things convenient for management at the expense of the front-line workers inverts the priorities of a company. The managers ought to be working harder to make things as efficient and convenient for the workers to build the right thing. Putting management first is the stupidest thing you can do for your company. You immediately separate yourself from quality and by and by your company will whither and rot. If it doesn’t die, it certainly will never be great.
>So, you’re saying it’s convenient for management, yes? Making things convenient for management at the expense of the front-line workers inverts the priorities of a company.
You'd end up having a points system whether you like it or not. If it wasn't story points, it'd be days/weeks/months estimates.
Almost nowhere you will find "it's done when it's done, don't bother me until it's done" as an option for a developer.
If you want an even more utopian arrangement, management would know how to look at git and use the software once in a while to see how things are progressing.
You, like tbrownaw, are arguing against something I didn't say. (Please go read the sibling thread.) I didn't say that planning, goals, etc. are bad. What I said was that story points lead to bad plans because they oversimplify the complexities of software development. A project timeline can be fine—but only if it is born out of a nuanced discussion and not by adding up a bunch of unitless points.
Developers (at least, ones like me) despise story points because they ask developers to collapse a ton of nuance and detail into a single scalar. It’s about as meaningful as this comparison of food recipes: compress the cook time, number of ingredients, cost of ingredients, quality of ingredients, whether or not some of the ingredients are allergens, and how much you like the food independent of the weather and your mood into a single scalar value and using that to plan what you will eat during the week. Madness!
Story points can enable corporate despotism. Bad managers who demand developers make up story points, and then turn around and use that to dictate what developers will work on—without engaging in a thoughtful discussion on what is feasible and what will keep the product stable—are on a power trip and are treating developers like cogs in a machine. They know the price of everything, but the value of nothing.
The good managers that I have had in the past regularly discussed with the dev team what was needed and—with the developers' input and without artificially compressing the complexities of the task at hand—set good goals that gave the dev team focus and direction.
The purpose of a company is to make money. Even if you hate shareholders (like for example your own 401k) and think invested capital deserves zero return, making money is still what allows the company to pay your salary.
Most companies do this by selling things to customers, whether services or products.
If you're building software for a specific customer, they'll want to know when then can start using it.
If you're building something for retail, marketing will want to know what release date to advertise.
These are the mind of things that management uses those reports for. Saying that actually customers don't need to be able to make plans, or marketing doesn't need to be able to advertise, is effectively saying that your employer doesn't need to make any money.
Which is quite a silly thing to say, at least if you recognize that devs don't exist in isolation and maybe even aren't the center of the universe.
> Saying that actually customers don't need to be able to make plans, or marketing doesn't need to be able to advertise, is effectively saying that your employer doesn't need to make any money.
That's not at all what I said. I said, if you choose to make management more efficient to the detriment of the people making the thing your company sells, you've made a bad choice. Bad managers like story points because it usually doesn't hurt their heads too much to add and compare scalar values. But a story point doesn't come anywhere close to representing the complexity of building any product. I've had one or two bad managers who wanted to make all things subservient to their precious Excel file. The productivity of that team (when the manager and story points process were introduced) plummeted and the entire team quit within a month of each other leaving.
The best managers I have had have worked by discussing customer and business needs with engineering and walking away with a richer picture of the tasks involved and an estimated timeline. It is very hard work to do this—it usually takes someone with a little knowledge of how software engineering works. I've had good product managers like this and I've been able to deliver some of the highest-value code I've written (measured strictly monetarily) thanks to managers who took a rich, nuanced view of the process.
I am not advocating for no management or no planning. I am advocating for management not requiring over-simplified metrics because it makes their life easier. Management does not exist to make its own tasks easier. It exists to make it easier for the people making the product to build the right thing at the right time and sell it. You can make plans without story points.
Having worked where a megacorp attempted to normalise points and incentivise velocity, there is a fatal flaw. The people doing the work estimate the size of the work! Increased “velocity” will happen automatically. Actual work throughput will remain the same. Prediction becomes impossible.
The most damning problem with “points” is that you can’t even do basic math with them. Does 4 points take twice as long as 2? No, no it doesn’t. The whole thing is just a giant waste of time.
My team needs to get 17 points done daily, but no-shows-no-calls keep kneecapping efforts. When they do show up, they complain incessantly about how management makes everything a 0.5 no matter the list of features in the story, and why can't they get more than 29 hours a week so they can have insurance. But it's attitudes like that which keep them from getting raises on their yearly performance reviews. It's a good thing scrum was invented so we could finally measure the consistent low performance of you computer science nerds.
> No bonuses for higher velocity is the real reason no one takes it seriously.
Bonuses for higher velocity based on guessed story points would be an even bigger reason for not taking it seriously - or rather to overestimate everything in order to gain the impression of higher velocity and the bonus associated.
Non-developers might have to learn something about development so they can push back on inflated estimates, which honestly would be helpful to everyone.
If I quoted you $1,000 to unclog your kitchen sink trap, you'd call bullshit because you can probably find out how easy it is to do that. Likewise, if I quote you 13 points to add a generic error toast message because a POST went badly, you should call bullshit on that too.
that really is the truth behind storypoints, somebody wants a way to create pressure. Which is also why storypoints are so bad because now you are pressuring everybody, even the good workers, despite only wanting pressure on a couple people. And on top of that you are wasting the time of the good workers with the whole story point estimation dance.
The problem with your kitchen sink example is that you'd think that they've unclogged 7k kitchen sinks so that they can you give you a great estimate.
If we've built the same software before ....we wouldn't have to build anything we'd just use the previously built software.
Software isn't built like a kitchen but by exploring an infinite list of design choices and then choosing one way and implementing it ..hopefully without impacting existing architecture. And it seldom stays static - the name of the game is constant change and then add group dynamics to that.
A better example is to call a plumber and ask how much would it be to add a "rainbow spout to the horse-drawn wheelie-do" oh and there will be several other teams of plumbers there as well. I bet you get a few questions.
this is nonsensical. first of all more programming these days is hardly invegigative, it is literally plumbing. attach this service this queue. translate this request to this api. compile this code under a new version. put this thing in a container.
secondly, and I've done alot of this, its entirely possible to build useful estimates around greenfield projects like 'define a new language', even though there are lots of variables in play. one useful technique is to work backwards. 'if we dont have a working draft spec in 2 weeks then we can really start the parser, so we're gonna say that, and if we cant hit it, we know we're in trouble'
if your ability to assign semantics and use your experience to plan out the work stops at 'horse drawn weheelie-do', i wonder if this is the right profression for you.
if as a culture we just throw up our hands 'whelp, its all unknowable, we'll just do the best we can and thats you can ask for', then we cant really criticize our customers for being frustrated with us and not 'appreciating our brilliance and how hard this is'.
and the truth is, we can and have done better than that.
Oh come on. There are certainly a bunch of things which nobody on a team has done before in any given project, an error toast is not one of them. Almost every project is using previously built software for them, and the way they fit together is reasonably well known.
To your own point, the reports serve little value aside from a fabricated narrative that some companies like to build feel-goods around.
Discuss the complexities and needs. Break the work into small chunks. Define what progress means. Set expectations for making progress. Regularly and honestly review why you/the team are or aren’t meeting expectations. Rinse and repeat.
Perhaps this is over simplifying it, but these are the tried-and-true high notes in my experience. If at any point one of those steps isn’t feasible, then it’s a larger issue that implementation process likely isn’t going to solve, so the “to measure velocity or not” point seems moot.
The biggest sin of course is then trying to predict velocity, but the consequences of that usually just make people doing the reporting look silly for no reason. I think even the slow developers rarely get fired, and you also get nothing for clearing more story points than other developers.
No bonuses for higher velocity is the real reason no one takes it seriously.