Whereas the [[Discovered Work]] pattern helps us *make progress*, Hill Charts help us *show progress* or conversely, *surface risk*. They do so effectively by plotting well defined units of work, called scopes, along a hill. The term "Hill Chart" is a double entendre. With gravity at play it's denoting the initial difficulty of moving work up a hill and then easily rolling it down the other side to completion. With statistics at play, the shape of a probability distribution reminds us of the tail risk of the unknowns of the yet-to-be-completed work. ![[hill-chart-1.png]] ### Figuring Things Out A team starts working on a [[Fixed Time Variable Scope]] project with a clean slate, nothing is written down. The team will initially make their best guesses individually in choosing where to focus their time, usually encouraged to work on what they perceive as the "[[Do The Hard Stuff First|hard stuff]]" first. All discovered work at this point should go into a single category called "Unscoped". For the first few days the team will be working on the project and the only progress to show is an increasing number of things in the Unscoped category. This is okay, as the discovered work increases, themes will begin to take shape. As [[Draw Clean Lines|clean lines]] are drawn around the themes according to the [[Integrate One Slice]] principle, they become named scopes. ### Making It Happen Each scope within the project is tracked on a hill. All scopes start at very left, at the bottom of the hill. The work in the Unscoped category of to-dos is sorted into the scopes and further categorized as a "Must Have" or a "Nice To Have". Any newly discovered work is always added to a scope and similarly categorized. By default we determine work in a scope as a Must Have, and prefix nice-to-haves with a `~`. Once scopes have been defined there are a couple of ways to approach completing the work. 1. Getting all scopes up the hill first - our recommended approach, except in the case of plotting unrelated scopes on the same hill, such as in the case of tracking small batch projects assigned to one team each as a scope 2. Completing scopes one a time - when there are multiple people working on a project with multiple scopes we recommend collaboration on the same scope until it's over the hill As the team makes progress on a scope, either by discovering more work or by completing discovered work, they update the scope on the hill. Scopes can move forward or backward on a hill depending on whether the team believes they're progressing or regressing. As the team discovers work a scope moves up the hill. A scope reaches the top of the hill when the team believes they've discovered everything that remains to be done in order to complete it. At this point, the scope should move down the hill to completion. A scope is completed when all of the must haves are completed. Nice-to-haves can be left over and prioritized once all scopes in a project are completed. The leadership or management team should have visibility into the current state of the scopes on the hill and the history of changes that have made make to their states on the hill. We recommend they give teams at least a few days after kicking off a project to discover enough work to show scopes on a hill and start tracking progress. They only need to [[One Level Deeper|dig deeper]] if they notice scopes not moving in accordance with the project [[Appetite]]. By being diligent, the leadership team can surface risk to a project early and help the team to adjust and make [[Trade Offs]] to get things back on track. ### Analogies Up Hill | Down Hill ------------ | ------------ Figuring Things Out | Making It Happen Unknown | Known Discovery | Execution Learning | Doing Supply Side | Demand Side Mapping The Trails | Choosing One Path Hard | "Easy" ### Problems Difficult problems are being discovered too late into a project or too close to a deadline and resulting in [[Tech Debt]] instead of [[Trade Offs]]. It is difficult is understand the status of a teams current work and [[Seeing Progress|See Progress]] of their higher level objectives at a glance. Leadership may be perceiving a lack of [[Transparency]] as a lack of progress. We're making progress by [[Discovered Work|discovering work]] but aren't exactly sure how to [[Showing Progress|Show Progress]] without showing lists of things we're not committing to doing. ### Observations While reporting status via a hill chart is by definition subjective, team members are able to easily discern between whether they are "Figuring Things Out" or "Making It Happen" ### Claims This pattern can help teams ease up on some of the burdens of [[Transparency|Radical Transparency]] by distilling progress into higher levels, which results in less distraction and interruption and more autonomy and trust for high performing teams. ### Avoid Using too few columns in a project management tool like [[Trello]] or [[JIRA]] to track scopes on a "hill". Based on empirical data we've collected from over a year of tracking projects on Hill Charts, we've found that a scope moves an average of almost 9 times in a 4 week project before being completed. Having work within a project tracked in a "grab bag" scope. This is similar to leaving work in the Unscoped category. If it doesn't fit within the existing scopes then consider redefining them or whether that work fits into the project at all. Choosing scopes according to arbitrary buckets that aren't related to work that can be shipped. For example, "design" and "engineering" are not scopes. Choosing scopes that separate critically dependent components of the product. For example, "front end" and "back end" are not not scopes. Having teams that are interfaced rather than integrated working on dependent projects at the same. For example, if there is an API team who considers the mobile team to be their customer, and therefore provides business value by shipping APIs, then the mobile team should not start [[Fixed Time Variable Scope]] projects that depend on work that the API team has not shipped. ### Parent Patterns If hill charts are going to be used to show progress in engineering, design, or other creative work then [[Discovered Work]] should be implemented first. ### Related Patterns While mostly used to track creative projects requiring engineering and design, you can also use the Hill Charts pattern to track team goals at a higher level, such as in [[Objectives and Key Results]]. ### Tools #### Project Management [[Basecamp]] - the originators of the Hill Chart, the key feature being able to see the progress of scopes on the hill over time. In contrast to most agile methodologies which track velocities across projects for estimation purposes, this allows you to track velocities within a project to surface risk. #### Hill Chart Specific There are a few tools dedicated entirely to Hill Charts such as - [Hillchart.app](https://hillchart.app) - [Hillia.app](https://www.hillia.app) #### Other People have also built hill charts for use in other applications such as this [Figma Template](https://www.figma.com/file/QdJ9rNzKUZVdsb1DZiCC2M/Hill-chart-template?node-id=0%3A1) and via an [API](https://hill-chart-api.now.sh/api?s=Test/20,Some%20Thing/60) ### Further Reading - [Work is Like a Hill](https://basecamp.com/shapeup/3.4-chapter-13#work-is-like-a-hill) - [[Convexity Bias]] ### Categories #pattern #progress #risk #transparency #trust #trade-offs #reporting #scope ![[✉️ Subscribe For Updates#^subscribe]]