There are estimates and there are commitments.

Estimations attempt to gather and communicate risk while Commitments are guarantees.

Commitments are rare and virtually non-existent. In general a functioning Engineering org does not provide Commitments until they're so far along on a project as to make the Commitment virtually useless to the rest of the organization.

Estimation Types

All estimates, be they 30/60/90's (Tripartite) or T-Shirts are always given in individual engineer time. Not team time. If something cannot be fit into one of these two structures then it needs to be further broken down for estimation to be of any value to the business.

• 30/60/90's allow for engineers to communicate both an educated guess around a project's duration and the confidence they have in that educated guess. 30/60/90's require detailed product documentation and communal buy in to the vision of the changes being made.

  <aside> 🛠 For the purposes of estimation. 1 Day is 6 Hours

  </aside>

  • The first number is the 30% confidence estimate. This estimate will materialize only if every assumption the estimator had comes true and nothing goes even remotely wrong. If Engineers are routinely hitting their 30% confidence estimates they're sandbagging their estimates.
  • The second number is the 60% confidence estimate. This estimate will generally materialize if about half of the estimator's assumptions prove to be true and Murphy takes a day or two off during the project. If Engineers are routinely hitting their 60% confidence estimates then they're pretty good estimators.
  • The third number is the 90% confidence estimate. This estimate will generally materialize if everything goes wrong; the code gets deleted halfway through, the database breaks and needs repair and suddenly sharks can fly. Despite the tolerance for bad things happening, these are still not commitments. If Engineers are routinely hitting their 90% confidence estimates then something is seriously wrong with the Engineering org.

• T-Shirts - T-Shirt sizing is all about providing rough direction to the rest of the business. The estimates themselves are almost certainly gibberish but can be used to compare distinct product directions against each other with some semblance of understanding implementation costs.

  • Hours to Days - The thing being estimated is probably less than a week's work but more than an hour's.
  • Days to Weeks - The thing being estimated is probably less than a month's work but more than a day's.
  • Weeks to Months - The thing being estimated is probably less than a quarter's work but definitely more than a week's.
  • I have no idea - The thing being estimated is so complex and/or massive that it is impossible for the Estimator to provide even a T-Shirt size