[jackmaney]

> The thing is, people are actually really good at relative estimation, it's absolute estimation that we completely suck at. That's the idea behind estimating in points: you free yourself from trying to think "how long will this take me?", which you'll inevitably get wrong, to "is this harder or easier than this other thing" which almost always is pretty easy to do.

That sounds great on paper. However, every implementation of Agile that I've ever seen or heard of eventually translates points to time intervals ("How many points should this be?" "Well, a one day task is three points, so...").

[lostcolony]

Well, then, to give you a piece of anecdotal evidence; my experience where I currently am is that we never talk about how long it'll take, unless it's so small and trivial we can say "Give me an hour and I should have a first pass in place". Even then we're not saying it's ~done~, just that we're familiar enough with the code that we can get some prototypal code in place in a time frame. When actually estimating tasks, it's purely point based, and then those can and do vary with how much time they actually eat up, but tend to average out just fine.

[jackmaney]

"When actually estimating tasks, it's purely point based"

The problem is that project managers and other business units don't give two flying shits about points. They want to know when things will be done.

PM: "So, how long will it take you to have that new logging system implemented?"

Developer: "It's a five point feature."

PM: "So....two days, then?"

D: "Well, I dunno...it's five points."

PM: "Two days it is!" [puts deadline of two days from now into JIRA]

[kabdib]

We had three types of PMs:

- Middle management mover-and-shaker. Most recent technical contribution to a product: Some time in the last ice-age. Super power: secret meetings that lasted for hours, discussing how much all the devs were late, and who to blame.

- Underflunky. Ran daily stand-ups to gather status. Last technical contribution to a product: Never. Perpetually terrified. Super-power: "Since we need this done by the end of today, let's have a bunch of meetings about it. Are you available for an hour at 10, 2 and 5?"

- Fantastically technical PM. Last technical contribution to a product: Helped debug a gnarly problem over in the other building about ten minutes ago. Super-power: Writing intelligent specs that devs understood and that actually described shit that would work. Achilles heel: Incredibly over-worked and a burnout in five months.

We had one or two of the latter PMs on the last project I was on. They were great; every other PM did negative work.

I did get our underflunky PM to start calling our scrum meetings "Status".

[lostcolony]

'PM' - well, there's a problem. We don't have project managers. Product -owners-, yes.

But you have a point; a lot of places try to 'be agile', as something the devs do, without also including management. As a number of others in this thread even indicate. Management has to also change, or else there's a mismatch in expectations.

As a dev doing SCRUM, we report point totals, and allow the business unit to prioritize stories based on that, and based on the need for the feature. Point totals above 8 or so we try and break down into more stories. The only guarantee we give is that if we include it in a sprint, we will get it done in that sprint. We can estimate it at ~8 hours (~two days of a single dev's time; we build in slack, for meetings, context changes, dev tasks, and the unexpected), but we aren't guaranteeing that you'll have it in two days; it'll be the end of the sprint. Any more exact estimate is only for other devs, in case they're reliant on it being in place for something they're working on.

[tromobne8vb]

Oh, I wish it were like this everywhere.

We have Product Owners. And PMs. And Dev managers, and QA managers. It's a giant ball of red tape and regret.

At one point the official 'scrum coach' actually convinced everyone that he had a magic formula for converting points to hours and that he could take the pointed backlog and produce a project plan out of it to produce familiar reports for management.

Everyone says we are doing Scrum, even the agile coaching team. But its really just waterfall done using Rally.

[jackmaney]

Fine, "product owner" or "scrum master" or "person who schedules meetings and fiddles with the JIRA board". Whatever. I don't care what piece of jargon you want to substitute in.

Let me ask you this: why should any customer or business unit give a flying fuck about your "points"?

Customers and business units should have a strong voice in prioritization of tasks, yes. However, in the process of prioritization, an estimate of time for the task--be it your estimation or theirs--will be a factor. If all you tell them is a number of points, then guess what? They'll back into their own time estimations from your points.

[lostcolony]

So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story), and can turn them into time measurements them however they like if they want to; we're not committing to their estimate.

All we're committing to is to deliver what -we- choose to include in a sprint, will be delivered by the end of the sprint. We will choose what is in the sprint based on the prioritized backlog. How they prioritize those things doesn't actually matter to us. They think that 8 point story we pulled in is going to take us two days? Doesn't matter. They think that 8 point story we pulled in is going to take us two weeks? Doesn't matter. They're not the ones deciding how much we can take on in the sprint, nor are they the ones committing to get it done. All we are telling them by our pulling it in is that it will be done by the end of the sprint. And that's what I meant by management has to change; that reality has to be acceptable to them, that getting relative points, to tell them the approximate amount of work (or t-shirt sizes, or whatever) relative to other stories is all we can really tell them, and that we will pull in the prioritized stories based on what we think we can get done. If they don't trust us to do that, and want to micromanage, then -no- development methodology is going to help you, not agile, not waterfall, not -anything-, because you have systemic dysfunctionality.

[jackmaney]

> So what? Let them. They get estimates that are relative to each other (~this~ story will take longer than ~that~ story)

First, they'll ask how much longer ~that~ task will take to complete than ~this~ task. Then, they'll ask how long ~this~ task will take to complete. Then, they'll use this little trick called "math"[1].

> and can estimate them however they like if they want to; we're not committing to their estimate

Well, guess what? If you refuse to give deadlines, then they'll be established for you. I don't know about you, but I'd rather have a say in my deadlines (where possible).

[1]: http://dilbert.com/strip/2002-05-19

[couchand]

You're right, eventually you have to convert points to some notion of time, if only so that you know how much work you can do in a sprint. The idea is that you make that conversion based on past observation, using a velocity estimate that represents the past performance of the team and takes into account who's on vacation this week.

There also should be an open recognition that your actual velocity will vary somewhat between sprints. One goal is to reduce that variability by improving your estimation (with practice!), but you anticipate and prepare for the variability. That's why you have a backlog (in case you need more work) and why you develop units of work that are independent (in case you need to push one).

For all these reasons it's a mistake to think of an equivalence at the level of tasks such as one day is three points or something like that.

[jackmaney]

In every implementation of agile that I've ever seen or encountered, something like this occurs:

"Okay, this story for Feature X, how many points should we give it?"

"Well, it'll probably take N days, so, let's say, M points."

Eventually, for the sake of consistency, a rough translation between points and time intervals is established.

[couchand]

I've seen that happen, too, but I've also seen it work.