3 ms·

I've been one place that I thought was really good at software estimation. Their system was: Everything gets a T-shirt size. Roughly, "small" is no more than

I've been one place that I thought was really good at software estimation. Their system was: Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. Anything beyond that, assume the schedule could be unbounded. Figure out how to carve those into a series of no-larger-than-large projects that have independent value. If they form a series of iterations, don't make any assumptions about whether you'll ever even get around to anything but the first one or two. That just compromises your ability to treat them as independent projects, and that creates risk that you find yourself having to worry about sunk costs and writing down effort already expended when it eventually (and inevitably) turns out that you need to be shifting your attention in order to address some unforeseen business development. At the start of every quarter, the team would commit to what it would get done during that quarter. There were some guidelines on how many small, medium or large projects they can take on, but the overriding principle was that you should under-promise and over-deliver. Lots of slack (1/3 - 1/2) was left in everyone's schedule, in order to ensure ample time for all the small urgent things that inevitably pop up. There was also a log of technical debt items. If the team finished all their commitments before the end of the quarter, their reward was time to knock things off that list. Best reward ever, IMO.

SketchySeaBeast 8y ago
> Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. That's pretty much exactly what I've ended up using on past projects - a little more fine grained (start at a half day, went up to months), but that was my approach as well, and if I didn't know everything it went up a size.
- karthikb 8y ago
  Did you find much differentiation between half day and couple of days? Especially because some things that might take a couple days end up taking 30 mins (some efficient package already exists), and some half day things end up taking a couple days, so it comes out in a wash?
  - SketchySeaBeast 8y ago
    Half day items were strictly bound, well know problem, like a label change, or a piece of functionality I knew by heart to be that size. I found that those items usually helps balance out the larger item misses.
  - bunderbunder 8y ago
    The answer to that question depends heavily on the duration and nature of your planning iterations. If you're doing quarterly planning, the difference between half a day and a couple a days is meaningless, and there's not really any point in distinguishing among them. If you're doing 1-week sprints, the difference between half a day and a couple days is enormous, and the product planner might get some value out of distinguishing among them. If you're following a more kanban-y approach, the difference is perhaps meaningful, but not particularly actionable, so I think I (personally) still wouldn't bother to capture the distinction for planning purposes.
pwenzel 8y ago
The "small", "medium", "large" approach sounds a bit like the one used in Pivotal Tracker.

SketchySeaBeast 8y ago

> Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. That's pretty much exactly what I've ended up using on past projects - a little more fine grained (start at a half day, went up to months), but that was my approach as well, and if I didn't know everything it went up a size.

karthikb 8y ago
Did you find much differentiation between half day and couple of days? Especially because some things that might take a couple days end up taking 30 mins (some efficient package already exists), and some half day things end up taking a couple days, so it comes out in a wash?
- SketchySeaBeast 8y ago
  Half day items were strictly bound, well know problem, like a label change, or a piece of functionality I knew by heart to be that size. I found that those items usually helps balance out the larger item misses.
- bunderbunder 8y ago
  The answer to that question depends heavily on the duration and nature of your planning iterations. If you're doing quarterly planning, the difference between half a day and a couple a days is meaningless, and there's not really any point in distinguishing among them. If you're doing 1-week sprints, the difference between half a day and a couple days is enormous, and the product planner might get some value out of distinguishing among them. If you're following a more kanban-y approach, the difference is perhaps meaningful, but not particularly actionable, so I think I (personally) still wouldn't bother to capture the distinction for planning purposes.

pwenzel 8y ago

The "small", "medium", "large" approach sounds a bit like the one used in Pivotal Tracker.