9

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 ]

Improve this question
5
  • 2
    Yeah. Nice cargo cult agile process you have there, but without the pesky self organising teams. Also sounds like putting this much effort into the backlog isn't very lean.
    – Nathan Cooper
    Mar 16, 2015 at 19:56
  • 1
    Agreed with @NathanCooper. What methodology are you supposed to be doing? Were you expert enough in your chosen methodology to customise it?
    – Dave Hillier
    Mar 16, 2015 at 20:27
  • @daveHillier exactly. Also "agile" isn't a particular methodology. Was it meant to be scrum for example?
    – Nathan Cooper
    Mar 16, 2015 at 21:02
  • Well it might have been meant to be Scrum. Certainly not XP. I think the best word to sum up our methodology at this point would be "Rally".
    – gws
    Mar 16, 2015 at 21:15
  • 1
    The problem is that if you can't estimate, then you can't decide the sprint commitments. At that point command and control management has murdered agile and is wearing its skin as a trophy. The core of agile is trusting good people to get on with it and the involvement and engagement of the team in delivery, not whiteboards, chairless meetings or jargon
    – Nathan Cooper
    Mar 16, 2015 at 21:50

3 Answers 3

Reset to default
11

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.

Improve this answer
2
  • 3
    Good advice overall.
    – Robert Harvey
    Mar 16, 2015 at 19:59
  • "get back to making software" -- indeed. And I try. By nature this organization is process-happy, though, so there will always be someone who wants the defect template updated with a new checkbox or something. Ah, well.
    – gws
    Mar 16, 2015 at 21:50
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.

Improve this answer
2
  • Tasks are part of stories, since we're using Rally. So they're indirectly in the backlog.
    – gws
    Mar 16, 2015 at 21:08
  • As a complete seat-of-the-pants estimate I'd say our bus factor on this project is around 10.
    – gws
    Mar 16, 2015 at 21:13
2

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.