Just something I was thinking about... while setting a range for tasks instead of a simple single estimate is a improvement, my intuition is that tasks should be described by a log-normal curve (https://en.wikipedia.org/wiki/Log-normal_distribution).
It's very deceptive to say a task will take 4 hours. It's much better to estimate it'll take 2-8 hours, as you do. I think it's another step more realistic to say it's a log-normal curve... then you can get a prediction like:
1% - complete in 15 minutes
5% - complete in 1 hour
10% - complete in 2 hours
50% - complete in 4 hours
80% - complete in 8 hours
90% - complete in 16 hours
95% - complete in 32 hours
99% - complete in 64 hours
99.5% - complete in 128 hours
...
...and so on. This mimics how task duration actually works in real life, in my opinion. The average completion time wouldn't vary that much, but the tails are treated very differently. With this you'd be able to sum up the probability of the the deviation from that average over many tasks.
You're exactly right! Under the hood, DoomCheck actually uses a log-logistic distribution -- https://en.wikipedia.org/wiki/Log-logistic_distribution -- which it fits using the range endpoints as 10% and 75% respectively. Then it does a Markov simulation to combine them across the whole project.
I really like this tool (text-based, yes!), thank you for creating this! I'm working on creating estimates at work and it is a real struggle. Creating estimates with a range and probability is awesome because it reflects the uncertainty inherent in any estimate.
It would be nice if the system showed its work somehow. In addition to giving me comfort as the estimator, it's nice to show the person on the receiving side the my inputs and help them understand process being applied. I looked for some docs on this, but I couldn't find anything. At the very least, it would make a great blog post!
Another bit of feedback while I'm here. I tried using {1-2d} for days and {budget 10d} for budget. It seemed to work for estimates, but not for the budget. Looked for docs on the syntax, but I couldn't find it and it all the examples in the quickstart use hours.
P.S. I'd love to talk to you about how I'd like to use this if you're looking for more feedback / collaboration. This has legs!
Thanks for the kind words, I'm very glad you like this!
It would be neat to be able to "show work", but I'm not entirely sure how to achieve that in a way that adds enlightenment instead of confusion in the main workflow. A blog post about how it works under the hood would definitely be a good thing, though, you're absolutely right.
The "d" suffix in estimates exist only to keep older plans valid -- it meant "8 hours", but since not everyone agrees that's the length of a day, I removed it from the documentation pretty early -- before budget and spent tags even existed, so they never had it at all. We all pretty much agree on what an hour is, so that's the one true unit for now, anyhow.
I'd love to chat more -- hit me at info@doomcheck.com and I'll respond directly!
This is a really interesting idea, but in my experience there is already lots of fragmentation of tools in project management in any team or organisation.
A standalone tool which is most effective if used regularly, but requires manually updating data which likely has an external source of truth is a very hard sell. This is a shame as one tool which does one job well is generally a good thing.
I guess integrations are a non-starter as few mainstream tools store time estimates as a range?
One of the recurring problems my early users have had is the need to move data back and forth between DoomCheck and their organizational system, most commonly Jira. So you're right about that being a problem.
Integrations aren't an impossibility, but they do require some serious design work (see next paragraph.) My current focus is to get people who are not already-invested in some other system to use DoomCheck as a standalone system so I can make sure the fundamentals are solid and usable.
As food for thought, here's a sketch of a design for Jira integration:
To begin with, we have to address a conceptual difference between DoomCheck and Jira. DoomCheck is document-centric, and encourages many small estimates. You can easily write "Purchase laptop {0.5-1h}, install Ubuntu {1-10h}, check out monorepo and build codebase {1-4h}". In Jira, every issue or sub-task is heavyweight; it would be pretty ugly to try to create a sub-task for every estimate in the preceding sentence.
So my current notional design is to associate Markdown document sections with Jira issues and sub-tasks. The descriptive text within a given DoomCheck markdown section would go in the corresponding Jira issue/sub-task description -- fortunately Jira now supports Markdown formatting so no translation should be needed.
Results of DoomCheck's analyses would go in two places. First, when an analysis was run or rerun, the latest probability graphs would get added to each Jira issue in a comment. Second, key values (e.g. the 10%, 50%, and 75% hours-to-complete estimates) could get written directly into custom fields, optionally with one of them getting written directly into the Jira native estimation field.
This approach would allow for two-way information flow between DoomCheck and Jira. One notional workflow might be:
1. Estimate your project in DoomCheck.
2. Push button to create and populate a new project in Jira from your DoomCheck plan.
3. Push button occasionally to make DoomCheck pull updated information from Jira, re-estimate everything, and push resulting graphs and numbers back to Jira.
I'm glossing over a lot of details here, of course, but hopefully that gives you a rough idea of how it might work for one very popular PM tool.
At a prior startup of mine, we needed to set prices for a series of 12-month, fixed-price, fixed-deliverable contracts. Since most tools typically used for planning software projects are terribly bad at helping you make good estimates, we did a lot of reading and then implemented an internal tool that produced really useful estimates.
Lately I’ve reimplemented those tools as broadly-available SaaS. It’s fully functional, albeit with rough edges, so I’m hoping to get people to kick the tires and give me feedback! The tool is called DoomCheck -- as checking to see if your project is doomed. DoomCheck is up and running at doomcheck.com, where you can play with a temporary plan right from the landing page, no signup required.
Please give it a try, and let me know what you think! I would absolutely love questions and feedback here and/or through the feedback or contact links on the site. Honestly, any way you can get it to me, I’ll take it.
If you’d like to know more before you dive in, here’s a bit more on what makes DoomCheck different and better than the usual suspects for project estimation:
- When you estimate work, you use two values to define a range, e.g. “{1-4h}”, rather than just a single-value guess. Ranges let you express uncertainty and risk -- a familiar task might be {1-1.5h}, and something new might be {20-60h}. (Factors of 3-4 uncertainty are not uncommon in software tasks.)
- When DoomCheck renders a project, it combines your individual work estimates to produce probability-of-completion graphs based on hours worked. It computes the full probability range for each section and subsection and subsection of your plan. This enables you to interactively explore your project in Graph View to look for particular problem areas.
- You write a project plan as plain text (an extended Markdown format) rather than each task being its own page and requiring multiple clicks to create, edit, or even just visit. This makes it very easy to put in lots of fine-grained estimates, and to restructure the plan at will. It also lets you make the project plan a true narrative rather than a bag of nested checklists.
- You can add labor budgets to your sections and subsections by writing, e.g., “{budget 12h}”. Then you can filter for sections that have low probability of on-budget completion using the slider in Graph View.
- You can also use DoomCheck to track ongoing projects. You can close work estimates with a closed tag, e.g. “{1-4h closed}”, and you can optionally also record labor like this: {spent 1.25h} The Progress graph shows the time-history of the project as the project plan evolves. (You’ll need to sign up for a (free) account to track project history, since you have to be able to save the plan to accrue that history.)
Thanks for reading this far, and I hope you try out, and like, DoomCheck!
It's very deceptive to say a task will take 4 hours. It's much better to estimate it'll take 2-8 hours, as you do. I think it's another step more realistic to say it's a log-normal curve... then you can get a prediction like:
...and so on. This mimics how task duration actually works in real life, in my opinion. The average completion time wouldn't vary that much, but the tails are treated very differently. With this you'd be able to sum up the probability of the the deviation from that average over many tasks.