Shape Up Forum

Hillcharts Without Basecamp (Tracking Knowns vs Unknonws)

Hi all,

I’m wondering for those of you who aren’t using Basecamp as a tool in your company, what are you using (if anything) to replicated Hillcharts? I.e. how are you tracking you getting your team to track/identify their knowns vs unknowns? Curious to hear what people have MacGyver’d together or if you aren’t doing anything, do you feel like you’re missing anything?

At our company (we use Azure DevOps - which is kinda hate), on our KanBan board, I’ve replaces to typical status columns - To Do, In Progress, Done, etc - with “Has Unknowns” & “No Unknowns”. I’m finding it’s better than nothing, but definitely missing seeing a sense of progress for when things are in either of those states. It’s hard to tell if things are stuck there or moving slowly without asking someone.

Looking forward to hearing what others have tried! :slight_smile:

1 Like

At Trafi we’re adopting Shape Up gradually and really wanted to give hill charts and scopes a go without moving to Basecamp. Requirements that we had for hill charts:

  1. All scopes on one hill
  2. Allow for precise placement of scopes
  3. Easy way to see change history
  4. Easy access to the hill chart for everyone
  5. A simple tool

Easiest approach we though of was having a physical whiteboard dedicated to the hill chart. Though, it does not have change history (unless you take pictures) and it is not available for remote workers.

To overcome the above shortcomings we though of using an “online whiteboard”. And it turns out that we already have a tool like this used by our company - Figma (any online design tool would do). It easily matches all of our requirements :raised_hands: The only drawback is that we had to sync scope names between two places, though, we knew this is inevitable without actually using Basecamp.

You can see (and copy) our template for a hill chart in Figma here :wink:

We were really happy about our trial on hill charts with Figma and are planning to try out Basecamp for our next cycle.

Good luck! :four_leaf_clover:


Thanks so much for sharing your Figma project! That’s really cool.

Funnily enough, also used Figma to create our own Hill Charts (yours is better haha), but in the end the team didn’t like double-handling items across 2 tools, so we stopped using that. That might be a little unique on my end, as I’ve got a dev team that’s fairly adverse from using any new/additional tools to what they currently use. With that said, our front-end devs are looking into using Figma, to perhaps we’ll try use it for Hill Charts again if the rest of the team starts using Figma for other things anyway.

Hey @Aylon, I’m actually working on a standalone app for this:

It covers all of @Nutas points above:

  1. Create one or more hills
  2. Each hill lets you add and move scopes
  3. Update points (and optionally provide a written update alongside the point update)
  4. Collaborate as a team and/or share and embed hills publicly
  5. That’s all it does – just hill charts, super simple!

We use Notion at work, so the embed feature is great: just paste the hill link into a Notion page, and the hill appears in an iframe:

Here’s a public link to an example hill to give you an idea of what it looks like.

Would you be interested in trying it out? Also curious, what are you using to manage projects instead of Basecamp?


That’s really cool, thanks for sharing! I’d love to check this out and have a play.

So we use Azure DevOps to manage our projects for dev work. I’m 90% sure that our devs would be very resistant to having to work across more than one two to manage their tasks. When you embed the hillchart into Notion, does it let people edit the scopes and everything from within notion or do they have to click through to your app to make the changes there and come back to Notion to see the update?

We also use MS Teams, so possibly we could embed this into a tab on Teams. Would be interested in trying to find out. Please let me know what you need me to do :slight_smile: Thanks!


Very cool. Thanks @conarro for sharing.

1 Like

Looks nice! I’ve just entered my details for early access :wink:

1 Like

Here’s a little write up of what I’ve cobbled together and how its been working for me.

For a bit of context, we’re a small technology-focused charity and most of the projects I work on are funded by grants. At the start of last year we were awarded some funding for a project that will run over 3 years, but won’t consume the whole team’s time over that period. For various reasons, its not a project that we can just work on in, say, Q1 of each year – there’s a fair amount of doing a bit of work, waiting on some external factors, then picking it up again. The team for this project is small – me (product manager / developer), a developer and a partnerships manager. We bring in a few colleagues with other skills from time to time (design, marketing/copywriting, data analysis), but essentially I’m talking about a team of 3.

What this means for me as someone looking after the project progress is that I want to see what we’ve committed to in each year, and how all that’s progressing. Each commitment is pretty high level – more like an unshaped raw idea. For this project, we’ve also set a budget (or appetite) for each commitment.

Here’s what I ended up with:

We primarily use GitHub for task tracking, so I wanted something that would align with our existing workflows as much as possible. This “dashboard” is just a static HTML page generated from data pulled in through the GitHub API.

Each line in the table is a GitHub issue. The spent/budget is parsed out of the issue description, and the hill chart progress is driven by the columns in a Project associated with the repository.

The Project is set up with 5 columns (To do, Figuring it out, We know what to do, Getting it done, and Done) that corespond to positions on the hill. For people who’ve read Shape Up, they’re more akin to Raw Idea, Shaping, Shaped, Assigned to cycle, Done.

I don’t actually use the project board view at all. Its easier to manage the progress via the sidebar of each issue.

The budgets are pretty loose, but serve as a rough appetite for us. They’re updated manually by editing the issue description and parsed out for the dashboard.

Each Year corresponds to a GitHub Milestone. Again, I don’t really use these in GitHub – its just a nice way of grouping the commitments allocated in each year. Any issues without a milestone are grouped under Unassigned. These are things we want to work on over the project, but haven’t yet decided which year we’ll attempt them in. This will grow over the course of the project as we get more raw ideas from users.

As we shape the raw ideas (Figuring it out column) I update the issue description until there’s a pitch we’re happy with and ready to allocate (We know what to do column).

This has been really nice to be able to just scan for a point on the hill to answer questions like:

  • Which commitments can I assign for development this sprint?
  • Which commitments have we assigned for development that haven’t moved to Done that might need some scope hammering or other un-sticking?
  • Which commitments need shaping so that we can make use of some upcoming development availability?

Of course, this isn’t quite the use that Ryan intended. We don’t use hill charts in-cycle to track the work at that level – though we do work in much the same fashion as the product teams do as described in Shape Up. Still, I’ve found having language around uphill and downhill work to be a great level up in thinking about “progress”, and the hill charts have helped visualise that even on the macro level.

Happy to answer any questions!


We use GitHub for pretty much everything in our team so I threw together a super basic API that renders an SVG based on the parameters that we’ve been trying for a while now:


It lacks the nice GUI to update it but can be updated and embedded in our GitHub issues.

1 Like

Nice! I actually started with a similar thing (parameter-based, ran on Glitch), but the lack of updates was bothering me. That’s why I started building

1 Like

We are using GitHub with their boards and we do 2 things.

  • Our main board has To Discuss column (Unknowns) and To Do (Knowns) and then the regular one like In Progress and Done.
  • When the feature is bigger, we either create a separate board for it and put link to the main board and there we manage it the same way To Discuss (Unknowns) To Do (Knowns). Or we handle it directly in PR’s and we track things To Do and to figure out there.

The hill chart is a great idea, but for me, the most important takeaway from this is to recognize that ideas has some evolution from unknown to known and if the team is onboarded with this idea, then frankly doesn’t matter that much that we don’t have actual hill chart.


I also wanted to try out hill charts but unfortunately, I couldn’t use Basecamp.

I created a tool for you to track progress of your projects using hillcharts called Hillia.

Here’s a readonly example (you can have a shareable link for your projects to display hillcharts on tv and stuff).

1 Like

Awesome work, @jmei !!

I’ve been loving using Hillia in conjunction with Jira to help provide visibility to a range of stakeholders on Pitches’ overall progress (in terms of Known/Unknown) throughout the cycle and it’s been especially well received by those folks that needed to be educated/warmed up to our “new” ShapeUp process.


If anyone knows about any other tools out there for Hill Charts without Basecamp please post them, I’m keeping an index of them here.

1 Like

Hey, thanks for the feedback. I’ve been asked privately to provide more info on the homepage of Hillia, just a quick reminder that it’s totally free.

Here’s what it looks like by the way:


What is the y-axis on a Hill Chart?

It’s simply a metaphor for an actual hill. It makes choosing the placement of a scope easier for the team (are we still going up the hill? have we figured everything out? Are we just getting it done and bringing it home now?)

True. Given it resembles a normal distribution curve, people sometimes get confused if the y-axis is incoherent. The y-axis should be described as “up” and “down”. That’s it!

I’m working on Jira plugin for tracking unknowns on issue level, and later on on various summary levels. My team is remote, and if there is one thing that I hate is to interrupt people to ask how it’s going. This will be enough for our use case.
Here is the screenshot of app in development. If someone is interested, I can send you a link to install it and to test it. Just let me know. This works in Jira Cloud only, not in Data Center version. It works both in issue panel view, and in backlog view. I’m planning to make this app available to public once testing is done.

1 Like