It’s not only software that benefits from being delivered in sprints. Digital officer Charlotte Brewer discusses the practicalities of “content sprinting”.
Sprinting – an act or short spell of running at full speed. That’s the traditional definition. Since the times of the Ancient Greeks, the sprint has been seen as the pinnacle of the athletic world. And in the last decade or so, it’s also become popular in the world of work.
Software teams have been taking up ‘Agile’ practices that quickly deliver lots of small but functional improvements. Sprinting is fundamental to this. Like the sporting version, sprinting involves a lot of effort over a short space of time.
In the Digital Comms team, we’ve started to adopt this approach in the way we deliver new content. Our newly–formed content team has now completed five sprints since we started this new way of working in October.
How our sprints work
Our content projects come in via our project board. The board agrees on priorities and establishes which project the content team will work on in the next sprint.
The board decides the length of a sprint. These can be three, eight or 13 days. Then it’s over to the content team, who follow this process:
- Plan the sprint
- Do the work with daily stand–ups
- Conduct sprint review and sprint retrospective
Plan the sprint
The content team and project sponsor meet to plan the sprint. We produce a backlog of tasks to complete during the sprint. This won’t necessarily be everything we need to do to complete a project but will aim to deliver significant benefits.
Using sprints means we can produce something great in a really short amount of time. What’s brilliant is it also allows us to gain feedback and iterate. This means we can go back to something in a later sprint and make it even better, without wasting weeks on something that might not even work.
In a recent sprint, we looked at our students’ top tasks. These came to us as a list of ‘FAQs’ from the Student Information Service. We wanted to then identify content on the website that might answer these questions and do further research in what information students want.
Together with the sponsor, we broke the scope down into key elements:
- Find out what content exists that answers students’ questions
- Find out how many people are interacting with this content
- Arrange user testing sessions
Then we could then start to break these down into tasks.
This planning session went well but these sessions can feel like a long slog. They can last several hours. In the first few sprints we did they also seemed unproductive. Initially, we didn’t invite the project sponsor, and when we did there was a lot of waiting for them to turn up. There was also a lot of talking and not much planning.
However, the agile nature of sprinting, with retrospectives held at the end of each sprint, has allowed us to adapt and tweak the format of these meetings.
The last couple have still been long but have been much more productive. We’ve had clear goals and a clear list of tasks that we can start doing straight after the meeting.
Do the work with daily stand–ups
Once we have a list of tasks, we can get on with the work. And I’ll talk about how we work once the sprint has started in my next blog post.