FOI Team GitHub Gardening

Extracted from an internal blog post on how I was thinking about prioritising work at the start of 2018.


This year I was in work between Christmas and New Year, which is a great couple of days to do some tidying up and prep for the year ahead.

I posted about our roadmap process earlier in the year, and while it didn’t work out entirely as planned, the main ideas stuck.

The gist is that we set a higher-level goal each sprint and make that the focus.

Here’s what Q4 2017 looked like:

Q4 2017 FOI Team Roadmap

This has been working really well throughout the year by helping us keep a really clear vision of the work to prioritise during the sprints.

Now, the trickier bit is deciding exactly what work to do – and indeed what not to do – in that window.

We’ve Got Issues

A lot of issues, actually. 800+ in mysociety/alaveteli, ~200 in mysociety/alaveteli-professional, and plenty more in the theme repos for individual installs.

This makes it really difficult to differentiate between “we really should do this” and “yeah, that would be nice”.

I had been thinking I want to comb these issues and do something with them to make them go away. Maybe close them; maybe migrate them to some other repository, but I’d have to get through 2.5 a minute if I wanted to review them all in a single day. Lots of them are also valid issues or asks, so it doesn’t feel right to close them. Instead, I’ve decided that its a concrete reminder that there are always more things that could be done than you can actually do, and that what’s more important is having systems in place to keep pushing forward.

No Priorities?!

I really don’t want to assign priorities to issues because everything always seems to end up as “high”. Without constant attention, the “high” label sticks to the issue, even if our priorities change. As a team we’ve got a fairly good mental picture of what needs improvement and what users are asking about, so the main concern is making sure we’re juggling lots of high value work.

Feature Areas & Value

Instead I’ve started creating some labels around feature areas. What I hope is that we’ll get a good picture of areas of the product that have lots of discussion. This doesn’t necessarily imply priority, just that there are lots of known options to explore.

Alaveteli Pro is quite a good example of this right now.

Alaveteli Pro Feature Areas

The best combination of work to pick is where the result is of high value to our users and there are few unknowns with how we plan to solve the problem.

Our next main focus is improving the alpha version of batch. We know this is a high value area of the product because users have been repeatedly asking for it.

In the case of creating and managing batch requests we’ve already got 13 fairly concrete options for improvement, so both can easily be scheduled for a sprint.

Batch analysis on the other hand is high value, but we don’t have many open issues here. This implies one of two things:

  • We’ve already done a lot of the work, so the open issues might be an incremental gain.
  • We haven’t thought much about this at all, and need to think about this at a higher level before we come to sprint planning and try to dive in to code.

In this case, its the latter. We’ve scheduled this for later in our Q1 2018 roadmap to give us some time to get some feedback from users and figure out what job the feature is performing.

Milestones

I had been using GitHub Milestones in a similar way top the feature labels above, but I think a better fit is for milestones to be mapped to the main sprint goal.

The milestone view is nice in that you can move issues up and down to create a prioritised list, so it makes keeping a prioritised backlog achievable now that we’re dealing with a manageable subset of the total issues.

We also get an approximation of progress during the sprint through the milestone progress meters.

Alaveteli Pro Milestones

There’s definitely some overlap with Waffle here, so we’ll see how that goes. I think that it’ll work out like this:

  • The milestones are more a planning tool for figuring out what’s going to go in to the sprint for that focus area.
  • Once we start the sprint that focuses on the feature area, we push the issues through Waffle as its a better view of “what’s happening right now”. There are always a some other bits and bobs that go in to a sprint outside of the main focus which would clutter the milestone views.

Summary

So here’s an example of how we’ll take a bit of an unknown feature (lets say, “Batch Analysis” – the things a Pro does once they’ve received all the responses to their batch FOI request) to a sprint’s worth of work.

  • Quarterly Planning
    • Schedule a sprint to work on Batch Analysis
    • Create a corresponding milestone
  • During preceding sprints
    • Work with support teams (design, comms, sales) to get a better understanding of the problem
    • Add issues to the milestone that would solve the goal
    • Keep shuffling the prioritisation of issues in the milestone view
  • Just before the “Batch Analysis” sprint
    • Label all the tickets in the milestone with “2 - contender” so that they appear in our plucking list in Waffle for sprint planning
  • “Batch Analysis” Sprint Planning
    • Go through our usual sprint planning process of assigning remaining work in progress
    • Load up the new availability with highest priority items from the contender list now containing Batch Analysis issues
  • “Batch Analysis” Sprint Retrospective
    • See how much work got done
    • Close the milestone – if issues didn’t get completed this sprint, they should have to earn the right to get included in a future sprint. This might not always work if there are dependencies, but in general most of what we do isn’t urgent.

Process Schmocess

When you write this kind of thing down, it always comes across as being really rigid. In reality this is just a bit of a brain dump of what I’m aiming at, and very much a set of guidelines rather than concrete rules.

I think the main takeaways from our 2017 roadmapping improvements were:

  • Roadmaps should be about scheduling blocks of effort, rather than sequential completion of a checklist.
  • Being able to identify high-value, low-uncertainty work is more important than maintaining strict prioritisation.

This year I think the main thing to improve is reducing uncertainty in the sprint goals before we come to work on them. I don’t mean big design up front – just having some space to think about the things coming up so that when we get to them we’re not finding ourselves needing to spend most of the sprint exploring before we can actually ship some work.

Happy New Year!