Try my estimation tool.

Quick History

At the time I created it I was struggling with the accuracy of the estimates I was doing. I was either underestimating because of optimism bias, or over estimating because I offset my bias too much.

The solution as startlingly effective. I used someone else’s ideas and built a basic tool and changed my behavior. That first version was enough to vastly improve my estimating ability, and give me a tool to help other team members think about their own. When I’ve been able to check estimate vs actual all but once I’ve been within on standard deviation of the mean (the “likely range” in that tool’s results).

A few years later I needed to estimate costs in addition to hours. So I created a second version which added cost projections to the process. That helped in a few scenarios, but honestly not as much as I’d hoped. Still, I learned stuff, therefore making it a useful exercise. Mostly it got to me fix some old bugs, and add scatter plot graphs to deal with complex outputs.

Those versions were driven purely by hour range estimates. They were extremely useful in helping me improve my estimates, if limited in estimating approach.

Time To Add New Approaches

Now I work on a team that estimates with Fibonacci story points and t-shirt sizing. I need my tool to support those approaches.

So over the last few weeks I’ve done more updates and upgrades. I now have a new version that will let you estimate using either of those techniques. It automatically converts those estimates to day ranges and runs the same simulations as it did before.

New Options

My experience is that teams using Fibonacci estimates, story points, or t-shirt sizing are usually estimating in days. Calendar time, or business days, are often what matters to product teams or in house teams.

Consultants track billable hours. In house teams hit a deadline.

To give users control over the conversion between the raw inputs and the day ranges the tool offers two modes. Which mode is best depends on what you’re doing, how you team works, and how well you track productivity now.

The first is a simple points to days conversion that takes maps the Fibonacci number to a number of days. It is labeled “Calendar Days” and lets users control the mapping. This approach is better for long-term estimation covering months or more.

The second mode is for teams that are good at measuring their velocity for agile methodologies. This mode let’s users specify a number of points per sprint, and the length of a sprint. It uses those factors to determine the number of points per day, and converts from there. This approach is better for shorter term estimate cover a few sprints.

Other Updates

While I was doing those updates I addressed a few other long standing issues. Older versions lacked feedback that a simulation was running. I also fixed several accessibility issues, improved test coverage, and added line item results summaries. The ReadMe file is now far more complete with better descriptions of process and more instructions.

Importantly, I changed the behavior for under-run estimates. Previously 50% of the time when the simulated value was outside the range provided it would pick a number below the specified range. Now that happens only 25% of the time, the other 75% generate numbers above the range. It also uses a calculation similar to the existing overestimate approach – the lower your confidence the wider a range it uses. This greatly reduces the number of 0 hour/day tasks in the simulations. It also changes the typical graph shape a bit to long-tail more on the high side. I think that is likely more realistic for most projects.

Welcome Our New AI Overlords

To accelerate the updates I used Copilot to help draft and review the code. AI coding still feels like cheating, but it is far faster. The code new is a bit sloppier in spots than I’d like and required several rounds of revisions at times. However, the AI added a lot of speed and reduced research level for new features. That saved time meant I added polishes I’ve been thinking about for years, but never took the time to do.

For example the tool now outlines scatter plots using a kernel density estimate curve. I added save buttons for the images, and there are print styles that make it easy to print into a PDF. Hopefully all those changes will make it easier to share the results. I only bothered to make those changes because AI made it easy to add them.

That process was aided by having had a reasonably good structure to the code I wrote in earlier editions. And I did check all the new work, but keeping tabs on 200 lines of new code from one prompt is a challenging exercise at times. The code base needs some additional refactors still to deal with some of the bloat it picked up. I don’t care that Claude and Copilot assure me all cleanup already been handled, the 2000 line index.js tells me otherwise.

You can find the full code my estimation tool on Github. If you have suggestions, please open an issue there and we can discuss it.

Five years later I still use it for project estimates. But I have grown tired of its interface weaknesses and needed to add cost estimation to keep it useful. So I recently heavily revised the tool and posted an updated version (the old version is still available here).

The interface is still very utilitarian ( pull requests welcome), but this version makes it make easier to adjust the tasks. Much more importantly it now also estimates costs, not just time.

The new version is faster than the previous. And it adjusts the graph type based on the range of possible outcomes.

Each task now includes inputs for min and max time, confidence, and hourly cost of that task. So if different people at different bill rates are part of the project it can still give you useful numbers.

The histograms broke down when faced with too many bars. So I settled on an XY scatter approach to help visualize the broader range that the cost estimator made normal.

Please give it a try, I’m always open to feedback, suggestions, and pull requests.

Costs Estimates

For this version I added the ability to include a unit cost for each task. The first tool worked just fine when you were estimating the tasks for one person who had one billing rate (or where hourly costs aren’t important). In practice teams need to be to able to do an estimate across all work streams, and different roles will have different billing rates.

This version includes a rate for each task and a graph of projected project costs.

Why I Created A Project Estimator

I wrote the original when I was struggling with project managers who would take any estimate you gave them as a range, pick a number, and promise the client (and themselves) we would hit it. To them an estimate was a promise – one that had to be kept. That lead me to badly overestimate projects so that the lowest end of my range would be a safe number – but that’s just a different form of bad estimation.

I had a good amount of experience providing estimates, and had read a lot on the topic. I knew there were teams that did better and I wanted to help our team improve.

The original tool was loosely inspired by one Joel Spolsky described ten years earlier. He has several important ideas on his process regardless of your project methodology. But his idea of using Monte Carlo simulations had stuck with me since that article had been new. After failing to find a tool that included it, I wrote my own.

Are the Project Estimates Any Good?

Fundamentally the simulations are only as good as the estimates provided. For any project I have been able to compare my simulated project estimates to final hours my work fell within one standard deviation of the median.

The confidence measure helps more than I expected. Originally, I added the measure of confidence because I needed something to determine how often the simulator should assume people are just plain wrong – and by how much. While I could have hard coded a solution I did not know how to pick good values. I knew that my confidence varies by the task. I also knew the less confident I am the more I am likely to be wildly off. So decide to make confidence an estimator provided variable, and use that to pick the size of overruns.

For every 10% you reduce the confidence, the simulation will allow the upper bound of the estimate to increase by the size or the entered upper bound. On a task you estimate at 7-10 hours, a 90% confident estimate will allow overruns up to 20 hours (just in the 10% of times that aren’t in the 7-10 range), and 30 hours for an 80% estimate.

That extra box also immediately helped me feel comfortable with my estimates. Knowing that the simulator would offset optimism bias for me I could stop trying to do that myself. My estimates can use tighter ranges trusting the software to offset expected bias.

A Value of the Graphs in Project Estimates

The graph has turned out to be the most important feature. Initially I included it because I wanted to play with D3 and have something more impressive than numbers to show. What I discovered was a reminder of the importance of data visualizations – even simple ones.

As I said before I created this tool when working with project managers who simplified all estimate ranges to a single number and held everyone to that number. The first time I presented numbers from the simulator those project managers picked the median and complained I made it too hard. The median was better than what we had before, but not enough to treat as a promise.

When I started presenting the graph those same people immediately started to change how they talked about the project. By visualizing the impact of uncertainty over several tasks they could see that the project might run far over my estimate – or far under. The more uncertainty, the longer the tail on the graph.

Suddenly they were comfortable talking about risks from overruns, finding ways to help clients understand the possible risks, and being understanding when a task proved harder than expected.

The graphs tell the story, and empowers the team to have an honest and productive about project estimates.

Estimate your own project timeline.

Any time I start to work with a new project manager on time estimates I try to make sure they understand any estimate is – at best – an educated guess, not a promise. I’ve learned to give ranges to imply inaccuracy and round up to offset my bias as a developer to underestimate (I recently noticed I’m frequently doing that too well and badly overestimating but that’s another story). However, that still led to greater faith in the estimates than they deserve.

A few months ago I was asked about this topic by a program manager I really enjoy working with and who was trying to work with me to find a better solution for our projects together. One of the articles I sent her was an old one from Joel Spolsky written in 2007. Re-reading the article I again drawn to his discussion of using Monte Carlo simulations to help come up with estimates about project duration. While he argues it helps increase accuracy, I mostly think it helps emphasis their lack of accuracy.

And since I’m a developer I wrote a simple tool to create project estimates that simulates how long a list of tasks might take ( code on GitHub and pull requests are welcome). It’s nothing fancy, just a simple JavaScript tool that allows you to enter some tasks and estimates (or upload a CSV file) and run the simulation as many number of times you’d like.

Currently the purpose of it is more to encourage people to understand risk levels and ranges than to provide a figure to hang your hat on. Since estimates are bad, the tool is inherently garbage in garbage out. But I’m finding helpful in explaining to PMs about the fuzziness of the estimates. By showing a range of outcomes – including some that are very high (it assumes that your high-end estimate could be as low as ⅓ the total time needed on a task) – and providing a simple visualization of the data, it helps make it clear that estimates can be wrong, and added up error can blow a budget.

Please take some time to play around the tool and let me know what you think. It’s extremely rough at the moment, but if people find it useful I could polish some edges and add features.