I think one of the most frustrating things that a non-agile team would have to deal with when working with an agile team is the “backlog”. What does it mean when the mainstream team say to someone “we’ve added it to the backlog”?
We use an online project management tool called Pivotal Tracker to keep track of everything we do. We then divide everything we need to do into:
- what we are currently working on
- what we are going to work on in our next sprint
- what we are going to work on in the next 2-3 sprints
- the icebox (aka, all the things we currently know we need to get done, ever)
The icebox and backlog can contain many different types of work:
- things we need to do soon (like Zendesk requests)
- things we'd like to do (eg, reviews of content that need some love)
- things in the future (updates to content or new services that have a set date)
- things that are blocked (we are waiting for something to happen before we can do the work)
Right now there are at least 100 things (in Pivotal they are called stories) in our backlog. If each story in the backlog takes 1 day then that is a 100 days of work. However, each story can also spawn five new things to put in the backlog. For example, carrying out a review on content can result in making changes to several pieces of content. So 100 things is really just the tip of the iceberg - the bulk of work is yet unseen, lurking beneath the seemingly finite size of the backlog.
We can also be distracted from our 100 things in the backlog because of:
- maintenance (rate changes, downtime messages)
- emergency changes (eg, changes to the overseas passport smart answer because of political unrest in other countries)
- important changes that have a tight deadline
- launch of a new service that needs content updated before it can go live
- meetings and workshops with departments
- things that turn out to be more complicated than we first thought
- we need to wait for changes from other parts of GDS or from developers to make a change
- new work that comes in
- changes in legislation that affect our content
Sometimes what seems like a quick update from a departmental point of view won’t be from our perspective. This is because we are constantly evaluating how a change may affect other content. It could be seen like pulling on a thread, which can unravel a whole lot of other work. Or it could be that we had a story to review the content that a department has now requested to change. We might take that opportunity to bump a review up the priority queue because we'll have to work on it now anyway.
We will also review requested changes against requests that have been made before. This is easy to do because there is an audit trail on every piece of content. This catalogues all the changes we have made to that content, who requested changes and where we can revisit the original request. This is why it is important when people ask for changes that they state why it needs to change (eg, policy change). Otherwise, from our perspective, it’ll just seem like a contradiction from a previous request.
When we come to sprint planning - we have to evaluate all the competing requests against each other and prioritise against:
- what has the hardest deadline
- what has the most benefit to our users
- who has the best skills in the team and if they are available
- if its new content or going over already live content
- the complexity (eg, do we have to some research first rather than start work)
- how old is the request
This is where it can feel that a request has gone down a black hole. If a request is an editorial review for content that has been live and fact checked several times over then it probably won’t be high on the priority list, simply because there might be a lot of new content changes with tight deadlines. However, the older the request, the higher the priority list it will go. So nothing is ever truly lost, it just might take a bit of time to get to.
When things do take a while to work their way through the queue, we'll try to let you know when we've picked it up rather than just surprise you with a fact check request. This does get missed sometimes but bear with us as we try to get better at keeping you informed.
4 comments
Comment by Phil Wilson posted on
Really interesting, thanks! When you say "the older the request, the higher the priority list it will go", is that manual, or something pivotal gives you?
Comment by Roo Reynolds posted on
Hi Phil. It's pretty manual to be honest. We manually add them as they come, and we manually reorder them as necessary.
Comment by Dave Asombalonga posted on
Is there any reason that there is no mention of answering zendesk tickets on this the public gov.uk pivotal tracker? Are they logged elseware?
Comment by Liz posted on
Hi Dave,
We have a pivotal-zendesk integration so our zendesk tickets that need some prioritisation will be folded in with the other pivotal stories.
We also have a daily rota for quick changes that come through zendesk (eg, broken links etc) so those don't make it into our backlog and are taken care of on a daily basis.