Should we estimate tasks during backlog grooming?

Question

I was just taken by surprise in a backlog grooming meeting when we assigned time estimates to BA, dev, and QA tasks...but the story is not yet scheduled in any sprint and we are not yet assigning resources to the tasks.

This feels backwards to me, since:

• I can estimate my own darn tasks, thankyouverymuch.
• We're going to review/revise the estimates during sprint planning anyway.
• Each task should be estimated by the person who's going to do the work. (developers are nonfungible)

Should we really be trying to estimate to the work-hours level of precision at this point?

This question's discussion says no, since the backlog is made of stories, not tasks. And this one addresses time scales. Both relevant, but I'd particularly like to address the topic of estimating unassigned tasks.

[Side note: <3 <3 <3 your comments and answers and I wish I could upvote most of them, but my account is too new :s ]

Answer 1

Should we really be trying to estimate to the work-hours level of precision at this point?

Hell no, but it happens all the time.

Partly it's because most places do SortaAgile. SortaAgile doesn't believe in story points. It doesn't believe that individuals have different velocities. And it certainly doesn't believe in team involvement.

Partly it's because Agile does a really bad job at answering a key business question: "when is this going to be done?". Well - that's not Agile's fault really. Developers need to have enough soft skills to push back on business to get clear scope and negotiate a tentative done date for that scope. You don't need detailed estimates for that, you need the ability to set expectations. Agile perhaps places more of that burden on developers since we're the ones pushing Agile, not project managers. Ideally, your project manager would be on board with Agile and competent. That is... uncommon though.

So push back where you can. But remember that estimation doesn't pay the bills - arguing with management doesn't pay the bills. Do what you can and then get back to making software.

Answer 2

It doesn't sounds like you're doing any kind of methodology that I'm familiar with. You wouldnt normally have tasks in a backlog. How do you prioritize a task? You can't complete a story without implementing all tasks so it makes no sense to have them in the backlog. Stories should follow INVEST

Should we really be trying to estimate to the work-hours level of precision at this point?

No, this should be deferred to the "last responsible moment". By the time you actually come round to implement it, things may have changed and you might not need to do it (and in fact it sounds like this is the case in your sprint planning). People usually recommend you do "just enough"

I can estimate my own darn tasks, thankyouverymuch.

Programmers are usually quite bad at estimating tasks. This is why people often use "ideal man hours" or just points.

Each task should be estimated by the person who's going to do the work. (developers are nonfungible)

While it is true that developers are non-fungible, Agile teams usually practice collective code ownership; it's one of the rules of XP. Just because the developers have different skills, it doesnt mean that anyone can't work on any particular task.

Sounds like you have a high Bus Factor.

Answer 3

It is a bad practice to do task level estimate in grooming session. The purpose of grooming session is to understand what needs to be done by elaborating the discussion and perfecting an acceptance criteria, so team can have clear vision and understanding what lies a head and what it would take them to get those stories done.

Once the team has a clear understanding of the stories then it can be estimated in points, not in hours, estimate must be done by complexity, what known and unknown. How to estimate in points is a whole different topic.