[cliff_badger]

Isn't the task itself time boxed by the points you assign to the story?

> "It is a 2 point story, why have you taken three weeks to complete it?"

[incognos]

Because sometimes you stumble on a graveyard and you end up cleaning out the corpses of developers past.

[bick_nyers]

Beautifully put.

[xwdv]

This is only a guideline, don’t treat it like a hard rule. There could easily be good reasons why a 2 point story took three weeks.

Also gotta stop the negative bias. People will want to complain easily if your 2 point story takes you three weeks, but no one will be singing praises if your 5 or 8 point story is done in a day.

[JohnBooty]

    There could easily be good reasons why a 2 point story took three weeks.

If it was because you were interrupted and given other priorities, that is totally valid.

If it was an estimation failure, that really needs to be looked at and learned from.

I find that this is typically a problem with management and/or process, not the engineer. We as an industry typically do not respect the time it takes for engineers to produce an accurate estimate. This time itself needs to be treated as a first-class concept and time needs to be allocated to it which, in practical terms, often means it needs its own task/card/story/ticket/whatever in the framework of one's choice.

There are nearly always unknowns (typically some kind of externality or legacy code) to explore before we really know how much time something will take.

[icedchai]

If you finish your 8 point story in a day, you should pace your work better. ;)

[icedchai]

Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.

[Sohcahtoa82]

My assumption was that if you're not performing sprints, you're not assigning points to stories either.

I don't know why I made that assumption.