Hacker News new | ask | show | jobs
by tweetle_beetle 1246 days ago
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?

1 comments

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.