Lesstimating

Summary: Spend a short amount of time estimating the dev-hrs/days for each User Story or task as a anchor for discussion/collaboration, but don't treat it like a commitment.

Context: Agile Product Development, Development Queue

Forces:

• the team wants to generate maximum value for the customer+business for time spent
• accurately predicting time-required for even a single small user story is difficult: developers are optimistic, and non-developers are worse

Wrong Solution/AntiPattern: there are many, including

• treating estimate as a commitment
• totaling team capacity, tracking velocity, etc.
• sprint planning estimate of how many "points" can be delivered in the next iteration
• make-believe units that can't be added, nor anchored to any reality (t-shirt-sizing, colors, etc.)

Bad Outcomes from Wrong Solutions:

• estimating becomes game-playing, and takes time and creates conflict
• accounting overhead of tracking points delivered, and making up reasons
• individual accountability, which reduces collaboration

Improved Solution:

• Yes, use time-units, in roughly powers-of-two: 0.5hrs, 1, 2, 5, 10, 20 (or 1, 2, 4, 8, 16...)
  • try hard to split any story with over 8hrs
• It's ok for a product manager to throw out a proposed estimate, as long as the team culture supports any dev to counter-propose. This is about sharing/converging a belief/bet, not gaming a metric.
• If the product manager "doesn't like" the estimate, the team can discuss whether reducing-scope can get closer to the PM's desired estimate. Trade-offs of technical debt should be honest.
• The team can also generate alternative Solutions to the Problem/Opportunity, some of which might be cheaper, or better in other ways.
• The team might conclude that the story doesn't need to be done at all, or at least not yet.
• If a dev realizes a story was under-estimated significantly, that's a worthy conversation during the next StandUp, or sooner. This could lead to de-scoping, canceling, etc.

In between Estimating and NoEstimates. Name from Clarke Ching, though he uses it in the context of Critical Chain planning.

For me, the biggest benefit of sizing & estimating is learning enough to decide to NOT do something. Cheaper than a Spike Solution.

The biggest reason I use estimates is to help catch differing unstated beliefs about how complicated something is, it triggers a conversation, which can lead to...

The second reason is to drop a story, or scope-reduce. "Oh, I didn't realize the idea was that hard/expensive. It's not worth it."

And I encourage using time for estimates, because it anchors the conversation in reality. Since we're just ball-parking, using a powers-of-2 kinda scale is reasonable.