Basecamp created hill charts as a novel way to view project progress and outstanding risk. The goal is to give managers a feel for progress without having to ask, but it also addresses key communication issues caused by uncertainty in creative work.
Basecamp already published an concise and highly-visual explanation of hill charts for free. I won’t do it better and I don’t want to steal their content, so I recommend you at least scan their explanation before reading this article.
If you didn’t want to read it, here’s a short explanation without pictures.
They compare work to a hill. There’s two distinct phases, going up the hill and down it. Going up the hill is the phase of feeling out the work and validating the approach. The top of the hill is crossed after you’ve done enough work to be pretty sure all the unknowns have been uncovered and the rest is just executing known tasks.
The work that actually shows up on the hill chart, in their approach, is the major separable verticals of work that make up the larger project. Work is periodically positioned on the hill by the implementers based on their intuition.
The manager then can view where work is on the hill and how it has moved over time, including if any work was broken up into more segments. This allows the manager to get a feel for the progress of work by relative movement and position on the hill.
The separation of uphill and downhill is critical. It marks a qualitative change in the nature of remaining work. Work on the downside of the hill isn’t generally risky. Work that is stuck on the upside of the hill is risky. Any work that languishes there indicates developers might need unblocked.
The best part of all this is that it doesn’t require any synchronous communication or awkwardly trying talk across a context gap. As a developer, it can be hard to pull yourself out of the details to deliver a clear consice explanation of progress, especially when you’re still going up hill and may not have a good feel for progress yet yourself. As a manager without context of the work, it’s also hard to ask good questions that help the developer paint a clear picture. Effective standups are challenging. The forces pressure toward over-optimistic reports and problems slipping through due to miscommunication.
Hill charts are interesting enough I’m considering trying Basecamp just to try out this one feature. It feels like a potentially transformative approach to status reporting.