[MattGaiser]

> Of that, probably the formal estimation methods (replaced in Scrum by intuition for some reason)

This has benefits and downsides. One of the one hand, the development team getting to control the estimate helps to control the workload.

On the other, I agree. Why are we pulling estimates of effort out of thin air? Why are we being asked how long it will take to do work in sections of code we have never seen?

Planning could be far more accurate if we just got a proposed task list a day before planning.

[tragic]

> Why are we being asked how long it will take to do work in sections of code we have never seen?

It is common enough for those packs of estimation cards to include one with a question mark on it, to denote the "I can't estimate this sight unseen" scenario. The reason it's common is because often people are presented with stuff that isn't well-understood enough, and it's a very good idea not to pull a number out of one's rear in those situations. Don't be afraid to use that card (or do the equivalent and just say so).

If you are afraid because you will be marked as 'not a team player' or whatever, you have management culture problems that neither Scrum nor any other imaginable software development process will fix on its own. They will all end up feeding an idiotic garbage in/garbage out cycle of overpromising, crunch, burnout and general misery, with the superficial appearance of whatever process it was supposed to be.

[js8]

> One of the one hand, the development team getting to control the estimate helps to control the workload.

I think that's a kind of waterfall strawman. In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

[MattGaiser]

> In every other discipline, you would ask engineers for an estimate. It's insanity to do otherwise.

I studied engineering in university and profs had plenty of stories about bosses sending business analysts to look at similar projects, generating a time estimate from those projects, and then send that estimate to the engineers as their deadline for completing the project.

It being insane doesn't stop people.

[Scarblac]

That's a pet peeve of mine. A perfect estimate is one without bias. It can't be without variance because there is always uncertainty involved in what needs to be done exactly.

So if you take an estimate and turn it into a deadline, in the perfect case, the deadlines can only be made 50% of the time.

Of course, in practice there is bias, there are things you forgot to include in the estimate.

[sergeykish]

It is to inform Product Owner. Quickly estimate with "trivial", "small", "medium", "big" and move on. Wrong estimate should not hurt. Managers are not allowed.

[jay_kyburz]

>Planning could be far more accurate if we just got a proposed task list a day before planning.

Why don't you work that in to your process. It's called Agile for a reason.

[js8]

Why don't they put it into Agile books? They're called books for a reason.

Snark aside, that's the difficulty. The fix for everything in Agile is - instead of adopting some sensible practice (that could actually have been discussed in academic literature), have an argument about this with your team members, maybe they will get it.

It's a return to medieval times, where all the expertise was just the experience of the master.

[Supermancho]

> Why don't they put it into Agile books? They're called books for a reason.

Agile books are hilarious because they are trying to not be prescriptive about process, while being prescriptive about process. Within that dichotomy, is the assertion that you can create your own process. So, in fact, it is usually in those books that you can make your lists for your team.

In the end, Agile/Scrum are a bunch of hand-waving rituals, which is close to what ends up happening within every software development team everywhere anyway.

[jay_kyburz]

I think the value of Agile is that everybody is different, and every problem posses unique challenges. You don't want to just follow some process in a book and expect it to work with your unique group of developers and designers, or for the unique problem you are trying to solve.

You could start with something suggested in a book. But you need to be ready to adjust your process when you identify when something is not working.

[mathw]

If you have no idea what the task list is before the planning meeting I'd say you definitely need to get your process changed. That's astonishing.

[Scarblac]

I want to add that the tasks we get at the planning meeting are just titles of tickets, nothing more. Working out all the details is the responsibility of the dev working on the ticket during the sprint.

Still estimates are considered extremely important...