jhbrown | 6 months ago | on: Advanced Scheme Techniques (2004) [pdf]
jhbrown's comments
jhbrown | 3 years ago | on: Show HN: DoomCheck: A tool for probabilistically estimating project size
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 [email protected] and I'll respond directly!
jhbrown | 3 years ago | on: Show HN: DoomCheck: A tool for probabilistically estimating project size
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.
jhbrown | 3 years ago | on: Show HN: DoomCheck: A tool for probabilistically estimating project size
jhbrown | 3 years ago | on: Show HN: DoomCheck: A tool for probabilistically estimating project size
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!