Estimating Completion via Hill Charts
A better approach to guessing
In high school, I ventured out with two friends to hike on the Appalachian Trail which stretches from Georgia to Maine. The plan was to hike for 5 days, covering about 75 miles. The distance would have covered the entire section within Georgia. On Day 3 a massive mountain was expected to be the highlight of the trip. Looking at the map and using some rough calculations, I estimated we would eat lunch atop the mountain in a few hours. We’d heard from others that it was one of the state’s best views.
As you might guess, I was wrong. Ascending the mountain took twice as long as expected. Conditions were rough and visibility was poor. We were exhausted by the time we reached the top and our lunch was devoured hours before. A thick fog left us with mere inches of visibility. No view and no highlight. From the summit, we made fast work of the descent.
Estimating is hard.
When it comes to project based work, estimations for tasks and deliverables are even harder. With changing expectations and unknowns, predicting requirements to ‘get the job done’ can feel like an impossible task. The difficulty intensifies when you consider that progress is not linear. If the project lasts 10 days, it’s unlikely that you are 50% complete on Day 5.
Complexity is Misleading
If complexity is front loaded, it may have progress slowly at first but is now picking up speed. Building software often follows this trend. If you plan early, later development goes a lot faster.
When complexity is backloaded, the early days may be smooth sailing though the majority of the progress lies ahead. Hiring new team members often works like this. You may communicate with, pursue, and interview a large number of candidates, though in the end all the value is in the offer being excepted by a single candidate.
There are also certain tasks that create bottlenecks for progress. If you are 20% complete but may not have the 1 necessary piece of information to move on.
The Hill Chart
Imagine you are hiking. At the beginning of the day you start at the base of the mountain. Over the course of the day you plan to summit and walk to a destination on the other side. Unless you have hiked the mountain before, it’s unrealistic to predict how long it will take you to walk down the other side. Until you reach the summit, more information is still needed.
Projects work much the same way. There are tasks you’ve done 1000 times before and others tasks that require more clarity before estimating.
In order to clarify the process and help the team visualize where things stand, our thinking has evolved. Rather than tasks being perceived as equals, they’re plotted on a hill. Items on the left require more information and insight. Items atop the hill have a path forward that only lacks execution. Items on the right done done.
When work is plotted in this manner, the conversation changes. Instead of broad questions about completion percentages, a helpful dialogue can exist around the items that need to move up the hill.
At the beginning of a project, it’s customary for some tasks to be on the far left while a few start at the top of the hill. Throughout the project, tasks are regularly reorganized, discussed, and shifted. Since their place on the hill speaks to different constraints, discussion is allocated more appropriately. An incomplete item at the top of the hill is vastly different than an incomplete item on the left.
Learn more about Hill Charts from the masters at Basecamp.
Originally posted on morganjlopes.com
