Story points are pointless, measure queues • Hacker News Board

Re: Story points are pointless, measure queues

#281

Post by tacitusarc » Thu, Jul 18, 2024, 3:08 PM UTC

brightball wrote: post #258

tacitusarc wrote: post #245

Earlier quoted context omitted.

So this may not be fair, but you lost me quite a bit with the positive take on SAFe, which is the worst, most unproductive experience of any process I’ve had. I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.

Alright, comment part 2 since I have a little more time now. First, the SAFe explanation. I've been a software developer for a little over 22 years. My first experience managing a team was 12 years ago and I shifted to it full time in 2018. My entire motivation for doing this was living through environments that were painful and unproductive for everyone involved. I found Reinertsen during a lot of reading when I was…

The fundamental assumption here is that you are in such a fantastically stable environment that you can spend days planning the next 8-12 weeks, and then that plan is actually reliable.

My experience was that maybe 20-40 percent of the plan ended up working (blocked by external factors, shifting market landscape, missed or unexpected work coming up), and then there was a huge amount replanning and time wasted.

I just cannot reconcile that 8-12 week cycles is in any way conducive to agile development.

Re: Story points are pointless, measure queues

#282

Post by tacitusarc » Thu, Jul 18, 2024, 3:18 PM UTC

brightball wrote: post #260

tacitusarc wrote: post #245

Earlier quoted context omitted.

So this may not be fair, but you lost me quite a bit with the positive take on SAFe, which is the worst, most unproductive experience of any process I’ve had. I also do not understand the queues and capacity issue. I have never been in an environment where we do not have so much work that we cannot meaningfully see past the end of the queue. I don’t necessarily view that as a bad thing.

Finally, Queues and Capacity. There will always be something else to do, that is definitely true. In this context we are talking about taking a chunk of that and trying to create an expectation of when it can be ready. In a Sprint, for example, you take a slice of work from that queue, a few stories with the goal of trying to get it completed in the next couple of weeks (hopefully). That creates a new queue for the s…

Yeah that helps. I thinks sprints are a bad approach to work, so probably some fundamental disagreement there.

I also strongly believe that all processes are downstream from people, team culture, and organizational incentives. If you don’t get those right, your processes won’t matter, and if you do get those right, your processes won’t matter very much.

I guess I’m not your target audience. That’s ok.

Re: Story points are pointless, measure queues

#283

Post by tracker1 » Thu, Jul 18, 2024, 4:46 PM UTC

... but $OTHER_TEAM is going through 20% more points each sprint than your team.

I hate story points, in fact I hate most automated issue trackers, generally speaking. I don't mind that there's a backlog and that features should have some details. But I'm now stuck in an org where we're doing SAFe/PI planning 6+ months ahead of where the devs will actually do the work, and designs that likely won't represent the true solution in practice among dozens of teams in a very large company.

It's kind of insane.

Re: Story points are pointless, measure queues

#284

Post by vannevar » Thu, Jul 18, 2024, 6:21 PM UTC

tsimionescu wrote: post #277

vannevar wrote: post #265

Earlier quoted context omitted.

>My experience is that story points get a bad rep because they don't mean anything unless you use them as an explicit proxy for time. So when you shop for clothes, Small/Medium/Large are useless? You require precise measurements for every item, and they have to be exactly the same size across manufacturers, or else sizes have no utility for you? The reality is that a Large can be large on you in different ways, even…

Of course small/medium/large mean something, they are an approximation of size/dimensions. But story points, adherents claim, are not a measure of time at all! They are not "an approximation of time", they are, so it is claimed, supposed to be unrelated to time, but to "complexity". And while I agree that a task can be large either because you know what must be done and there is a lot of work or because you're not su…

Story points are also "an approximation of size/dimensions." If my team has consistently deployed 25-35 story points per sprint for the last three sprints, it's reasonable for me to assume that next sprint they will also be able to complete about 30 story points of work. By contrast, knowing that they worked a combined total of 300 hours on average doesn't help me at all. And accounting for uncertainty is important, which is one reason a Fibonacci sequence is commonly used. The general rule is to go up one in the sequence if the team is uncertain. The whole purpose of story points is to avoid having to track things like uncertainty separately. It's like the Markov assumption, the information to get to the current point estimate is baked in. It is useful (essential, even) to incorporate fuzzy concepts like perceived complexity or uncertainty without bogging the team down trying to measure them precisely and explicitly.

Re: Story points are pointless, measure queues

#285

Post by vannevar » Thu, Jul 18, 2024, 6:33 PM UTC

samus wrote: post #215

bluefirebrand wrote: post #152

Earlier quoted context omitted.

> No one outside the scrum team should care about story points, and they certainly shouldn't be used to generate reports. Velocity is for the team's benefit, as a tool to help manage workload and schedule These two sentences are somewhat in conflict imo. Workload and schedule is tied into capacity planning and resourcing, which happens at a higher level than the scrum team. The people having those conversations need…

Apart from the impact on team motivation and the incentive to inflate estimates, another problem with that approach is that the story points might not correspond cleanly with how much time was actually spent on the task. Story points are anyways an example of multidimensional data squeezed into one dimensions and in the process losing valuable information. Are there teams out there that correct the story points based…

>Apart from the impact on team motivation and the incentive to inflate estimates...

Why would story points affect team motivation, and why would a team have any incentive to inflate estimates? The team isn't judged externally by the story points they burn, they're judged by the software they deliver. The team itself should be the sole consumers of their own story points, so inflating them accomplishes nothing from their perspective.

>...story points might not correspond cleanly with how much time was actually spent on the task.

If something turns out to be easier than expected, then the team should take that as a lesson for the next time they see something similar. This happens all the time, it's the kind of thing to bring up in the retrospective. I tell my teams that every sprint has two products: the validated software that gets produced, and the team that produced it. The team generally gets better as the project goes on, as they learn more about the project and their own capabilities.

Re: Story points are pointless, measure queues

#286

Post by andirk » Thu, Jul 18, 2024, 7:13 PM UTC

egeozcan wrote: post #227

andirk wrote: post #96

Earlier quoted context omitted.

Much like one huge difference between string "42" and the number 42 is that the latter can have math done to it. If you want to avoid the arithmetic, label tasks with words like "simple", "small", "quick", or my favorite "Won't fix".

> Much like one huge difference between string "42" and the number 42 is that the latter can have math done to it I actually agree with your comment but this part made me laugh out loud because JavaScript :) ("42" - 1 === 41 but "42" + 1 === "421")

Good ol overloading of the + operator at work there

Re: Story points are pointless, measure queues

#287

Post by tsimionescu » Thu, Jul 18, 2024, 7:14 PM UTC

vannevar wrote: post #284

tsimionescu wrote: post #277

Earlier quoted context omitted.

Of course small/medium/large mean something, they are an approximation of size/dimensions. But story points, adherents claim, are not a measure of time at all! They are not "an approximation of time", they are, so it is claimed, supposed to be unrelated to time, but to "complexity". And while I agree that a task can be large either because you know what must be done and there is a lot of work or because you're not su…

Story points are also "an approximation of size/dimensions." If my team has consistently deployed 25-35 story points per sprint for the last three sprints, it's reasonable for me to assume that next sprint they will also be able to complete about 30 story points of work. By contrast, knowing that they worked a combined total of 300 hours on average doesn't help me at all. And accounting for uncertainty is important,…

> If my team has consistently deployed 25-35 story points per sprint for the last three sprints, it's reasonable for me to assume that next sprint they will also be able to complete about 30 story points of work.

And if the last few sprints they've completed between 5 and 30 points, do you believe they'll complete around 17.5 points next sprint?

Now, if the team is good at estimating (which they are if they get consistent results between sprints), they can tell you of them telling you feature X is 8 points, Y is 5 points, Z is 15 points, and you concluding that they will finish X, Y, and Z next sprint. But, they can exactly as well tell you that X will take around 3 days, Y will take around 2 days, and Z will take around 5 days, and you can have the same conclusion.

Re: Story points are pointless, measure queues

#288

Post by steelframe » Thu, Jul 18, 2024, 9:58 PM UTC

tsimionescu wrote: post #278

steelframe wrote: post #270

Earlier quoted context omitted.

Then it would be how long they might take relative to each other. To give a specific time you would have to know the stage of development for the product, the health and ease-of-use of the CI/CD pipeline, the current interviewing burden of the team, the rate at which production incidents are occurring, the number and length of meetings that the team members are in, etc., etc., etc. More junior developers generally wo…

> To give a specific time you would have to know the stage of development for the product, the health and ease-of-use of the CI/CD pipeline, the current interviewing burden of the team, the rate at which production incidents are occurring, the number and length of meetings that the team members are in, etc., etc., etc. This is a strawman. When asked to estimate a task, people essentially always think in terms of "how…

I did story points with a team of 12 over a two-year period of time, and it worked.

Re: Story points are pointless, measure queues

#289

Post by vannevar » Fri, Jul 19, 2024, 3:18 AM UTC

tsimionescu wrote: post #287

vannevar wrote: post #284

Earlier quoted context omitted.

Story points are also "an approximation of size/dimensions." If my team has consistently deployed 25-35 story points per sprint for the last three sprints, it's reasonable for me to assume that next sprint they will also be able to complete about 30 story points of work. By contrast, knowing that they worked a combined total of 300 hours on average doesn't help me at all. And accounting for uncertainty is important,…

> If my team has consistently deployed 25-35 story points per sprint for the last three sprints, it's reasonable for me to assume that next sprint they will also be able to complete about 30 story points of work. And if the last few sprints they've completed between 5 and 30 points, do you believe they'll complete around 17.5 points next sprint? Now, if the team is good at estimating (which they are if they get consi…

>And if the last few sprints they've completed between 5 and 30 points, do you believe they'll complete around 17.5 points next sprint?

I don't know, what did the team figure out in retro? Was the big difference a real underestimation, or was there some kind of unforeseen blocker? I've never seen that big a variation, but anything's possible.

If it makes you feel better to measure team velocity in something you call "days" instead of story points and it works for your team, more power to you. But don't fool yourself that you're talking about actual days. At best you're talking about "probable days", and how many days it actually takes will depend on a lot of things, including unknowns and who takes the story (are "Bob-days" the same as "Carol-days"?). So you'll end up with a measure of days that is very team- and uncertainty-dependent, and at that point it's better to just use story points and admit that it's not a universal measure and doesn't need to be. Not to mention that by using days you'll invite confusion between calendar time and time-on-task.

Re: Story points are pointless, measure queues

#290

Post by aryehof » Fri, Jul 19, 2024, 4:12 AM UTC

gregors wrote: post #264

convolvatron wrote: post #221

Earlier quoted context omitted.

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…

I'm a big fan of evidence base scheduling by Joel Spolsky [0]. Story points hold very little value in estimation, the discussion that occurs however, is extremely useful. [0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

I rarely see EBS in use. Why do you think it is not more widely used?