At the Government Digital Service (GDS), we divide our work up into 3-month missions. We’ll give a multi-disciplinary team of about 10 people a particular problem to solve or a high-level idea of a piece of value to deliver within 3 months. We vary scope as we go, with time and resources being fixed. We build our understanding as we go, and change our approach as necessary to deliver the most value in the timebox. We’ll generally plan work to increase our understanding of what the right thing to do.
As Product Manager, my role is to make sure that we’re solving the right problems, and that we’re getting the most value from the work we do.
At the start of a mission, I set some clear overall goals for that quarter. Be upfront about what you’re not working on, so that everyone’s clear.
Work back from the end state you want to get to at the end of the quarter – e.g. migrating from one supplier to another, or launching a new feature that successfully meets its goals – and think about the things that will need to happen to get there. This will generate some milestones. You can start to build a high-level plan of what’s coming up in the quarter by mapping when you think you can hit these milestones. Do this with your delivery manager and tech lead, so that it’s sensible. It’ll change as you go, and that’s fine. I like to do this with post-its on a wall in the team’s space.
Within this structure, I like to work in weekly sprints. This means that you plan the detail of your work a week ahead. I like to run sprints from mid-week to mid-week, so that everyone knows what they’re doing on Mondays and Fridays, and those days can be kept free of meetings.
I run planning with the whole team – which is really important to build a shared understanding of the problems everyone is working on, across the disciplines. A day or two before the planning session, I’ll have a series of conversations to decide on the most valuable work to be done in that sprint. Some of these will be with my tech lead and delivery manager, others will be with the different specialisms in the team (e.g. user research, performance analysis or content design). The goal is always to check in with the big picture aims for the quarter, dive into any thorny questions we need to think about, or work to review in detail together, and then agree on what do work on in the upcoming sprint. Often this will be something already mapped out at high level, and now we start to consider the detail, but sometimes it’ll be something new.
These pre-planning conversations are a lot of fun, and a chance to think deeply about each of the disciplines in my team. They align us on goals and scope for the week – so we’re thinking carefully about how much is responsible to try and take on. In most quarterly mission teams I’ve been on, we’ve found estimating doesn’t work too well, as there’s lots of uncertainty inherent in a mission, and with a newly-formed team it takes a while to understand your velocity. So we rely more on gut feel, experience and the ability to iterate week-on-week if we felt a given sprint had too much work or not enough.
Once these conversations have finished, I’ll leave the different team members to write up cards to describe the work. I have a standard format I want cards written to – they need to have a ‘What’ and a ‘Why’ that anyone in the team could understand. But I don’t need to write the cards myself – it’s good practice for people to be able to communicate about their work, and it saves me time. If someone is struggling with writing cards to this standard, I’ll take the time to pair with them to iron this out.
The goal of writing these cards is to inform a robust planning conversation. Going into the team’s weekly planning session, we want clear goals and alignment on the big picture from each of the specialisms. The goal of planning is to think through the complexity of the work as a team, to really flesh out the detail of the cards – adding acceptance criteria, or thinking about how we might tackle a thorny technical challenge. But it’s also to build a shared understanding of what the other disciplines are working on – in a time-efficient way.
Ideally I’ll introduce some goals for the sprint, covering each of the specialisms. Probably tied in to the milestones for the quarter, that get us to our goals.
Once I’ve introduced the overall goals, and we’ve nuanced them if we need to, then we go into talking through the individual cards. I usually invite other people to introduce their own cards, and then I make sure that there’s a good quality converstaion on each card – making sure that by the end of the discussion we understand the value we’re trying to deliver, and have thought about the approach we want to take.
So this session is about sense checking, challenging, thinking about approach – but isn’t proscriptive about approach. The person who decides to work on the card takes the lead on that, calling on others for support if needed. Planning is very useful for being proscriptive in defining quality, and in adding acceptance criteria to a card. As with planning overall, making sure we know what we need to do is more important than how – the how is worked out in the ground.