DEV Community

Discussion on: Tradeoffs Of Time Estimates

Collapse
 
eljayadobe profile image
Eljay-Adobe

I've found that time estimates for stories are too easily converted into commitments by those who should know better.

So instead of making time estimates, I've been happier with shirt size estimates, with a simple association of effort.

  • XS - an hour or two
  • S - a day or two
  • M - about a week
  • L - about a sprint
  • XL - epic: multiple sprints
  • XXL - epicly epic: multiple cycles

As things get bigger, it becomes fuzzier. For XXL, our (release) cycles are about 13 sprints.

So for the Product Owner considering the Product Backlog, knowing if something is XL of "3-ish sprints" versus "12-ish sprints" may make a big difference.

But here's where too big is just too big: some XL that may seem 3-ish sprints may easily turn out to be harder than expected, and turn into 12-ish sprints. And some XL that may seem 12-ish sprints may turn out to be easier than expected and be done in 3-ish sprints.

The problem is that the feature is just too darn big, and if possible ought to be broken up into several smaller features.

(The above is for stories. Time estimates for tasks should be done in hours, and ideally of a scope that is possible to get one-or-two done every day. Plan the work; work the plan.)