Skip to content

Instantly share code, notes, and snippets.

@randomcamel

randomcamel/estimating.md

Last active February 14, 2026 02:32
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save randomcamel/d5b6d16d2ce47df1e6811c5321b42fe0 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save randomcamel/d5b6d16d2ce47df1e6811c5321b42fe0 to your computer and use it in GitHub Desktop.
Download ZIP
Doherty Software Estimation
Raw
estimating.md

  1. know how much roadmap-project work people can do in a week. commonly it's 40-60% of their time. call that PR (for Project Ratio).

  2. make a spreadsheet: [Story, Description, People, Weeks, Person-Weeks].

  3. break the work down into comprehensible pieces, where you feel confident saying things like "this will take 2 people, working full-time, 3 weeks to implement." in particular, break down milestones that deliver value; where, if the business told you to do something else, that would be okay, and the work done wasn't wasted.

  4. fill in your spreadsheet columns appropriately (say 2 people, 3 weeks, 6 Person-Weeks).

  5. sum up the Person-Weeks. ("People" and "Weeks" are for later.)

  6. Person-Weeks ÷ PR gives you the raw number of Person-Weeks involved (call it TPW). this assumes no technological pitfalls, infinitely parallelizable work,

  7. TPW ÷ # of people on the team gives you the minimum amount of time the project will take, as you've laid it out. call it TW.

  8. you know your people, their skills and challenges, and the environment you're working in. think about delays, known and unknown, like:

  • integrating with products or projects outside your influence.
  • delays in waiting for other teams.
  • staff fluctuations (attritions, planned and unplanned leaves of absence, re-orgs).
  • hazy or hand-waving areas in the implementation.

  1. based on your thinking in #8, and being pessimistic, pick a number from 3 to 10, and multiply that by TW.

  2. there you go.

"How much gets done in a Person-Week?", I hear you ask from the third row. And the answer is:

                        I don't know. You have to, if you want to succeed.

Go back to #8. If you have a team of 6 junior developers and 1 SRE, they're going to have a very different "velocity"—call it "productivity" if you're squeamish—than your team of 4 Staff Engineers who wrote the initial product a decade ago.

This really is the core of estimating and planning. Absent organizational overrides, don't commit to something you don't understand. Don't commit to something impossible. (I was once ordered to build something that violated the CAP theorem. It was a bad scene.) Bigger, more elaborate methods are, when they work, ways to gather and track the information of #1-#9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment