[wpietri]

Story points shouldn't get converted back to resource time. They're just a way of ballparking estimates sufficient to let product managers make broad choices, and to help teams keep from getting excessive amounts of worked crammed into an iteration.

So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours. I think that's not a great idea for all sorts of reasons, but if you're in a culture that values output over outcome, you may not have a choice, and clearly plenty of projects succeed with GANTT charts and whatnot.

[lowq]

In our process, we've been consistently told that a weight of 8 corresponds to a two week (10d) sprint, and that 80% of our time should be spent on scrum tasks. Then, if any developer closes more than 8 points in a sprint, we are told that we aren't estimating properly. They have all but equated 1 point to 1 day, but the scrum master consistently denies that weight corresponds to time.

I'm new to this. Are we agile?

[wpietri]

I mean, that all sounds very Scrum to me in that uses agile words while sounding very top-down, awkward, and constrained.

To me, the agile movement, at least initially, was about empowering teams to get things done for users. I came out of the Extreme Programming end of things, which had a dozen practices to start with. But the people behind it said that they offered that set of practices as a place to start. From there, teams were supposed to use the short feedback loops to inspect and adapt.

So in my opinion, that is not agile. However, as I've written about elsewhere [1], I think the Agile movement got taken over by something that was more marketable to executives with a top-down orientation.

So in short, I think what they're saying sounds like bunk to me. The way I used points was as purely relative estimates. Point velocity per iteration was a measured quantity, used mainly to make sure the team didn't oversubscribe an iteration. E.g., if the team did 10 last week, this week we'd take on 10. If we thought we might get done early, we could always pull another card in.

But alas, it sounds like you're trapped in what I think of as mini-waterfall, where people who have waterfall biases have broken their big thing down into two-week-sized waterfall lumps.

For what it's worth, I long ago stopped doing estimates entirely except in special circumstances. I now prefer the Kanban-style approach where there's a backlog of modestly sized units of work and the team has a limit of the number of things that can be in progress at once (my starting point is half of the number of team members). You then release each thing as it's done.

[1] E.g., https://williampietri.com/writing/2011/agiles-second-chasm-a...

[nikau]

> So don't use them as an intermediate unit. If you want hours, just ask for estimates in hours

But then you aren't doing Agile!

The whole thing is just stupid terminology for existing things and distils down to "make a todo list and work through it"

[wpietri]

That may be what you have experienced it as, but that is not what it is. There are more things, Horatio.