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
Donethat might need somescope hammeringor other un-sticking? - Which commitments need
shapingso 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!