Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Story points are pointless, measure queues

brightball.com

Post reply on HN
Print view View original

291–300 of 300 posts

Re: Story points are pointless, measure queues

#291

Post by tsimionescu »

steelframe wrote: post #288
tsimionescu wrote: post #278

Earlier quoted context omitted.

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

I did them too, with two different teams of 8-10 people, once for two years and the second time for about one year. We didn't lose anything when we gave up on points and simply went for time based estimates.

Re: Story points are pointless, measure queues

#292

Post by kqr »

vitus wrote: post #137
bsder wrote: post #19

Earlier quoted context omitted.

In addition, I like the whole "Full Queues Amplify Variability" chart. It's intuitively obvious, but I never realized it was that bad. I'm going to have to run that down and see if it's actually backed by real data. Too many business books are complete flimflam.

The shape is about right for the variance of the M/M/1 queue (what is an M/M/1/∞ queue??), but it's a little disingenuous since variance is a higher-order moment. Standard deviation is probably more sensible to think about here, since that brings it back down to the same scale as the queue length. > Thus the average number of customers in the system is ρ/(1 − ρ) and the variance of number of customers in the system i…

> what is an M/M/1/∞ queue??

Infinite queue length. M/M/1/k would be a system where once k items are enqueued, some work shedding policy takes over (either rejecting new work or often preferably dropping at the head of the queue.)

Re: Story points are pointless, measure queues

#293

Post by brightball »

tacitusarc wrote: post #282
brightball wrote: post #260

Earlier quoted context omitted.

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.

Oh, I agree on all points except that processes are inevitable in a sufficiently sized organization. Understanding how they affect people is critical to making them work.

I was just using sprints as an example here.

Re: Story points are pointless, measure queues

#294

Post by Viliam1234 »

Rinzler89 wrote: post #187
dilyevsky wrote: post #171

Earlier quoted context omitted.

They aren’t. I’ve seen this argument rehashed a thousand times - “we arent estimating time, just complexity so we can estimate how much we can do in a sprint. which is two weeks. wink wink”

Which is just time and effort estimations with extra steps and cargo culting.

Sadly, if you avoid the extra steps and say "I think this will require 10 working days", some manager will reply "are you absolutely 100% sure that it couldn't be done in 9 working days?".

For some reason, calling it "10 story points" does not provoke the same instinctive response.

Re: Story points are pointless, measure queues

#295

Post by Viliam1234 »

wewtyflakes wrote: post #50
ozim wrote: post #41

Earlier quoted context omitted.

So they are bad product managers and customers. Time until delivery for good managers and customers is a range. Can you estimate getting 10kg of potatoes from grocery store that is 35m driving roundtrip away? Can you say it will be exactly 40mins because you can pick up and pay in 5 mins? I don't, I can say it will take between 40mins and 2h. There are always things like card terminal stops working or you get stuck i…

I don't follow how we go from "they are bad product managers and customers" to... therefor time estimates are bad. I do not think it is unreasonable for our primary stakeholders to ultimately care about time. I also do not think it is unreasonable to give error bars in estimates like "this project is uncertain, therefor estimates will be variable".

The bad managers are those who ask you for an estimate and then take it as a commitment.

.

"How much time will this take?"

"Not sure; approximately 30 minutes, but could also be 20 or 40 minutes. If we are very lucky then 10 minutes, but if we are very unlucky, maybe an hour or more."

"Spare me the details, I just need one number for the report."

"Uhm, 40 minutes?"

"You just said that it would be approximately 30 minutes, didn't you?"

"Yeah, but I wanted to add some safety margin..."

"If we keep adding large safety margins to everything, then the project will take forever. As you said, some tasks are completed faster, some tasks are completed slower, on average it will cancel out. I need your best estimate."

"Uh, okay, then 30 minutes. On average."

...the next week...

"So, you guys told me this would take 30 minutes, but it actually took 35. I think we need to have a serious talk about your performance."

Re: Story points are pointless, measure queues

#296

Post by Viliam1234 »

ozim wrote: post #17
throw310822 wrote: post #14

Earlier quoted context omitted.

If they're not time, why use numbers? Use fruits: easy peasy, it's a lemon. A really tough story, a coconut. You can't add them in any case, because they're not time.

That is one of the complications - one thinks developers should be smart as in abstract thinking so they should understand (just like all the other numbers humanity made up): "numbers we call story points are not having property to add them and they are not convertible to time". * Properties of Whole Numbers: Whole numbers are closed under addition and multiplication. Zero is the additive identity element of the whol…

And this is how the entire math gets done in 5 simple JIRA tasks. :D

Re: Story points are pointless, measure queues

#297

Post by samus »

vannevar wrote: post #285
samus wrote: post #215

Earlier quoted context omitted.

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 th…

Story points are used to plan a sprint. They are a honest estimate of how much work and how difficult a task is going to be. If they are used by management, then it turns into a tool to excerpt undue pressure on the team.

> The team isn't judged externally by the story points they burn

Are you really sure about that? Never got a question from the customer why the team couldn't finish as many story points as in the last sprint? Or why during sprint planning the team hasn't committed to a given amount of story points?

There is indeed a learning process. Once the above questions get asked, it is not difficult to see why a team would start to inflate story points.

> The team itself should be the sole consumers of their own story points, so inflating them accomplishes nothing from their perspective.

As indicated by the comment I was replying to, this is not the world we live in.

Re: Story points are pointless, measure queues

#298

Post by fouc »

happytoexplain wrote: post #89
vannevar wrote: post #74

Earlier quoted context omitted.

>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 operational load outside of development work). If your measure of the utility of story points is how well they help you estimate time, then you're right, they're useless to you. If you…

>back-of-the-envelope way to estimate which bits of validated functionality you're going to be able to get into the codebase this sprint >help you estimate time How are these different?

Given that people are generally bad at giving accurate estimates, the story points is asking the question in a different way, it's asking "what's the likely complexity of implementing this?" rather than "how long would it take to implement this?", because people are likely to be too optimistic on the time estimate, and more likely to be accurate on the complexity estimate.

It is a multi-step estimating process to arrive at more accurate estimates:

1. estimate complexity via story points, filter out features that will be implemented according to the "complexity budget" 2. break the features down into sub-tasks 3. estimate the time it takes to do each task

Re: Story points are pointless, measure queues

#299

Post by rerdavies »

brightball wrote: post #238
rerdavies wrote: post #84

Earlier quoted context omitted.

Software does not exist in a vacuum. You are probably right in thinking that story points should not matter to you, as a developer; but they do matter to external stakeholders. Forecasting and management of expectations is necessary because software often has external real-world dependencies: available funding for a first release, marketing materials, hardware that can't be released without software, trade shows, dev…

> The corresponding abuse of process to combat that metric would be to hyper-decompose stories. You're right about that, but that's also one of the benefits to the approach. Inflating a point estimate is easy and there's no real audit trail for why the value is what it is. On the other hand, if a team creates tasks like "Commit the code" or "save the file" it's pretty easy to identify as fluff.

'save the file' is not fluff.

Re: Story points are pointless, measure queues

#300

Post by brightball »

tacitusarc wrote: post #281
brightball wrote: post #258

Earlier quoted context omitted.

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…

Personally, I’m a huge fan of the 37 Signals approach.

They do 6 weeks planned, 2 weeks unplanned as their regular cadence.

Post reply on HN