My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…
Story points are pointless, measure queues
141–150 of 300 posts
Re: Story points are pointless, measure queues
#142In one team, 3 points might be equivalent to 3 days work. In another it might be 1 day.
Re: Story points are pointless, measure queues
#143In that case, you absolutely always have an impossibly long queue. The things that don't get done keep going into technical debt, which as a rule doesn't decrease. Until at some point you declare technical bankruptcy.
If you reduce this to just the queue for the current sprint, that is generally a smaller size, the queue length is determined by ... the story points.
So to manage the queue without story points, your job is to break the stories into equal-sized tasks, so that the queue size has a meaning. However, you cannot break a story up that way (this requires estimation of task complexity -- the premise of the article and our own battle tested experience is we don't know how to do that) and even if you could you run into the infinite queue as I mentioned.
> I am certified to teach it as a SAFe Practice Consultant (SPC)
:sus:
Re: Story points are pointless, measure queues
#144Earlier quoted context omitted.
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…
> 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…
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.
Re: Story points are pointless, measure queues
#145Given the size of my scroll bar, I rate reading this article a 13. My PM has decided I shouldn't bother reading it, as the likely value isn't worth the effort, because whenever we take on a 13, it ends up dragging on for like 4 sprints, and preventing a lot of other higher value/lower effort stuff from getting done. Maybe at some point in the future, we'll break the article and have a few people on the team each read…
Totally get it. :-) I did include a helpful TLDR near the beginning with the highlights though.
Re: Story points are pointless, measure queues
#146Earlier quoted context omitted.
> 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…
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…
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.
Re: Story points are pointless, measure queues
#147Story points are primarily a social tool - senior management politics requires that something gets measured; story points make them happy and provide a quantitative way of communicating with the rest of the business. Until we come up with a way of measuring programmer productivity - which is not a queue - there is hard to improve on using story points.
Re: Story points are pointless, measure queues
#148Earlier quoted context omitted.
Totally get it. :-) I did include a helpful TLDR near the beginning with the highlights though.
I found the tldr really confusing and next-to-useless. It’s a really really long article and I just wanted to read about queuing since yeah story points can suck.
Re: Story points are pointless, measure queues
#149My personal experience with story points is that the number never really mattered, but the process of the team discussing how to rate the complexity of a task was very useful. In terms of having utility of estimating how long something will take, I personally have never been able to translate story points into a reliable indicator for that for many reasons (e.g team changing, domain changing, variability in operation…
This is my experience as well. Story points in and of themselves are worthless, but as an excuse to discuss the project as a team, they can have some value.
I liked story points when the team used them to get aligned on the work being done. I did not like story points when middle management had them on a chart they would review.
Re: Story points are pointless, measure queues
#150What stops management from committing Feature A to be delivered after 250 tasks are completed? Yes the fact and the reasons that the Feature A expands to 500 will be documented, but who will care about it? This will still be a "delay" from the management point of view.