Answering questions about Hill Charts

1

I got an email from a Shape Up adopter about hill charts. I thought these questions and answers might be of general interest so I’m publishing here.

Q: Who is the hill chart primarily for? (The team or management?)

The real answer is it’s a mirror for both the team AND management to see how they are doing.

It started in Basecamp being driven by management. We identified that projects die when people get stuck on some part, so I designed the hill chart as a way to see if something is stuck or not.

The unexpected side benefit for teams is, moving the dot on the hill became a way for them to feel progress. Like “I didn’t just hack at something today, I got that scope further uphill.” This is especially true when they get a scope over the hill. That’s a “phew … we’re getting somewhere” moment for the team.

Basically, we are factoring the project down so instead of ONE win at the end of the project, we get a win every time a scope is solved. I think from that POV you can imagine how that is beneficial for both parties.

Q: How often does leadership check the hill chart?

Depends on the project… maximum weekly, and sometimes daily. There is no penalty to check (because you don’t have to nag anybody) so as often as you like according to the uncertainty you have about the work.

I have a way of thinking about this I find really helpful: I think of this as uncertainty about the WORK not the team. I’m checking in because I don’t trust the WORK. I don’t trust it’s defined properly, scoped properly, or that we understood it fully when we decided to do it.

With this point of view, if I spot a problem on the hill … like a scope isn’t moving … my first instinct is there is a problem with the WORK not the team. So then I approach them and I’m like “something is wrong with how we are scoping this. or something is unexpected with how this has to be implemented. Let’s look at it together.”

Q: Do teams update the hill chart every day?

I have a shtick about this. Work is not a crystal. It’s not made up of perfectly arranged equal sized units. It’s lumpy and organic.

For that reason, we might see three dots move on the hill in one day. Then radio silence for three days. Then something hard moves a quarter uphill.

My rule of thumb is, if I don’t see anything moving after about 3 days, something is wrong or stuck.

4. Is it uncommon to have scopes move but no to-do items on them?

If you have scopes with no to-dos, you have achieved the first level of hill zen. It’s the scopes that move, not the to-dos. The to-dos are just a mechanism for not forgetting implementation details about the scopes.

9 Likes
2

@rjs I have a question. How QA fits into Hill Chart or how they use it? E.g. If the item on the Hill Chart is close to finish, is this a trigger for QA to start testing it?

3

I recommend tracking QA separately. That way the Hill Chart is just about the core part of the work that the team has understood.

This assumes that QA is for the edges, and the core team takes responsibility for basic quality.

2 Likes
4

Any thoughts on this @rjs ? The Problem with Hill Charts — Jordan Koschei
Interesting feature suggestions too.

5

Thoughtful post. Thanks for sharing.

Hill Charts make an explicit trade-off: they show uncertainty at the cost of not showing “difficulty.” This stems from our experience at Basecamp that if something is difficult, it can still get done, but if something has no solution in sight, it may never get done.

The suggestion of changing the shape of the hill to indicate where the difficulty lies is understandable. We decided not to do something like that for two reasons. 1) The differences in difficulty that the poster pointed not only vary per-project, they vary per-scope. That means you would have to have a different hill for every scope, and you couldn’t plot them together on one graph. 2) You don’t know what’s hard until you start, so you would need to independently manipulate both the location of the scope on the hill and the shape of the hill as the work progresses. That introduces a level of complexity in both the UI and interaction that we don’t think is worthwhile considering the explicit trade-off I mentioned above.

6

Very insightful. Thank you.