151–160 of 300 posts
Don’t the tasks in queues have the same issues with the tasks from story points do? What if the tasks are not defined well enough? So some tasks in the queue might take a day to complete, another could take months?
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…
>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…
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 something to go off of, so it's pretty easy to see why they latch onto story points and velocity.. those are numbers that their teams are already producing!
I do agree with you that this is a misuse of velocity and story points, but I don't think it's possible to keep such things from being used (abused?) by upper managers above your team
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 were never meant for forecasting. To do that you can use Monte Carlo analysis https://observablehq.com/@danielfrey/monte-carlo-simulation-...
Earlier quoted context omitted.
Points are about uncertainty, they're the difference between: - 3-4 weeks - 3-9 weeks Product managers can get their head around that.
Why not just say that then? It’ll take 3-9 weeks. You can then just add all the min and max and get a full range.
They do not equate to hours and cannot be boxed by management expectations.
Management can separately track actuals (hours), but that really should never concern the team.
Earlier quoted context omitted.
I just don't get what the new terminology is for. Like how is this helping anybody? Manhours = story points Task = story Subtask = sprint Upcoming tasks = backlog Task turn around time = ?? Project goal(s) = epic(s) I'm probably not even doing this right, but what are we doing here anyway?! It gets real fun when the project involves software/firmware + mechanical engineering (think machines, robotics, etc), gotta lov…
The idea was to not use direct measures of time to estimate because someone above you will start assuming those estimates are promises and then life gets unpleasant. Story points, much as I personally dislike them, were invented for developer defense.
I remember learning in school (way before the hocus pocus fancy new words came out) that the development of an Intel CPU cost around 1000 man-years.
I don't understand how expressing this as "it took 1000 kilo-story points" or whatever would bring any advantage whatsoever.
Earlier quoted context omitted.
I agree - just countless times I have to beat that up into peoples head and even people who I would consider smart "points time". After the sprint you can kind of infer the time but it should not be guideline for next estimations unless these are tasks like "fix typos".
I continue to treat story points as a measure of time, despite being told repeatedly they're definitely not time. I will continue doing this until someone can explain to me, in a way I can understand, what they actually are that is not time.
Story points aren't time (as OP states). They're relative complexity, and uncertainty (hence the fibbonacci sequence building uncertainty in to larger numbers). And stories should be able to sized as big numbers. I've never been on a team comfortable with more than a 7, at least not since my first agile experience where we all took an agile/scrum training together for a few days. We'd frequently give things like 21 o…
I haven't done story points estimating in years, but at the time, an 8 was rarely acceptable, a 13 surely was not. Estimates that high were basically saying "this story is too big or too poorly defined to estimate accurately" and we'd try to break it down into several stories of 5 points or less. The vast majority of our stories were 2, 3, or 5 points.
How big your points are make no sense at all outside your own team. It is a relative measurement. 8 could mean 8 lines of code, 8 rest endpoints, 8 database columns or 8 interviews with customers. It certainly should not mean 8 days.
Earlier quoted context omitted.
Same way that throughput and latency is different. You can use it to predict what the team can deliver in a quarter for example. But difficult to give ETAs to individual stakeholders.
if you are at a point where you employ such a factory throughput thinking for information workers then you're misusing information workers in my opinion. Focusing on a throughput metric is just as nonsensical as focusing on how many lines of code somebody creates, in fact, it's really astonishingly similar in how nonsensical it is. Bug reports, issues and features are not just lumps of coal that you need somebody wit…