Hey that seems longer than 2 weeks

I’ve stumbled upon a style of estimation that I’ve seen be pretty successful. I’ll call it “2W+ Estimation”. I've mentioned it before, but without much detail.

There are two possible estimates given for any work that the team is about to take on: “more than 2 weeks” and “less than 2 weeks”.
An estimate is not provided at all if the work seems like less than 2 weeks. It is assumed to be less than 2 weeks. We only mention an estimate if we want to note that something seems longer than 2 weeks.
When something is bigger than 2 weeks of effort, we try to think of ways to change the scope to something deliverable in less than two weeks while accomplishing the same goals. Sometimes we talk about whether the high cost means it should be prioritized lower. Sometimes we agree it’s worth doing now anyway. Sometimes we break it down into valuable deliverable pieces, where each is smaller than 2 weeks.

It’s worth noting that there are 2 critical steps that we undertake afterward for any effort large or small: (1) break it down into thin vertical slices (2) check every day to make sure things are still tracking how we’d expect. Bigger-sized projects tend to be riskier and go off the rails more often. If one seems off the rails we might have to restart this process and reassess the remaining effort.

What’s so great about this estimation style?

It’s almost as fast as not estimating at all, but forces good conversations in higher risk scenarios.

It uses time not complexity (like story points) because (1) everybody already knows and understands time and (2) complexity is not any easier to estimate.

No overly precise estimates are ever given, so the estimates can’t be converted to precise calendar expectations. We don’t like the effects on our codebase or people of them being rushed with arbitrary deadlines.

Why 2 weeks?

I imagine a different time frame could work better in different scenarios. I even imagine a smaller time frame could work better for us.

How did we develop this?

We started by not estimating, and then smart people who found that too risky would pipe up pretty regularly and say “hey you know that’s pretty big right?”. “Pretty big” seemed to be generally agreed to be “greater than 2 weeks”.

Who might this not work well for?

Well you probably already know if you’re at the kind of company that would even be willing to try this. A lot of companies think spending more time on estimation gets better estimates, and that more precise estimates are worthwhile. We don’t, but different companies value different things and sometimes those values have good reasons.

The team needs to be willing and able to speak up when something is large because there’s no other mechanism than that kind of proactive candor.

This may not work for a team that does sprints where you're trying to pack as much work into a given timeframe as reasonable, especially if those sprints less than or equal to 2 weeks. We find sprints to be really weird, so we don't do them. T-Shirt sizes might be better for those kinds of teams, or something even more precise.

You still need to break stuff down well and reassess progress daily. But everyone should be doing that regardless of estimation technique.

Tags: estimation, practices, predictability, management

← Back home