Updating website content on a regular basis is a vital part of a functioning content lifecycle. That is why many companies look for a practical approach to optimising their content. At Swiss Post, we introduced content sprints for content optimisation. We adapted the Scrum framework – and the sprints as its core element – to our context. Read more below on how we went about that and what it takes to make a content sprint successful.
Regular “Maintenance” and Optimisation of Web Content
Content on websites requires regular “maintenance”. This is how we make sure our content is still up to date and relevant, both for the company and the users. Sometimes, a few sporadic changes here and there are enough. But if entire sections of a website need to be overhauled and optimised, it helps to take a more structured approach.
Swiss Post has more than a thousand content pages on its www.post.ch site. As part of a well-functioning content lifecycle, all of these need to be checked and updated on a regular basis. To explore whether the software development approach might also work for content optimisation at Swiss Post, we did a three-week content sprint zero.
Content Sprints: Elements from the Scrum Framework
In a content sprint, just like in Scrum, a team sets itself a certain amount of time to achieve a goal. The goal for our sprint zero was to have reviewed and updated 20 pages in the content management system (CMS) of Swiss Post. We took three weeks to do that.
Apart from the actual content update, the process also included an editorial review, an expert review and the entry into the CMS. Additional downstream steps were translation and definitive publishing. In addition, we also wanted to strengthen the editors’ UX writing skills in these sprints.
Our process was set, the steps had been defined and could be viewed by everyone at any time. In addition, we adopted the following elements from the Scrum framework:
Values: We defined principles for collaboration in our team.
Scrum Team: We defined roles and responsibilities.
Artefacts: We worked with backlogs, estimates, sprint goals and a “definition of done”.
Events: As well as the actual sprint, we also adopted events such as sprint planning, daily meetings and retrospectives.
1. Values: The Principles Our Work is Based On
Just like they do in Scrum, we also defined principles for collaboration for our content sprints. Transparency, commitment and autonomy are core principles.
Transparency: We want to be transparent at all times and openly communicate goals, progress and open tasks. That is why we use tools such as Miro, Microsoft Teams and Microsoft Sharepoint and take a Kanban approach to our work.
Commitment: We have a clearly defined goal and project members do their best to achieve this goal. We split the tasks and support each other.
Autonomy: As a team, we work independently. Team members complete their own tasks and set their own priorities.
2. Scrum Team: The Roles You Need
For our content sprint, we set up the following roles and accountabilities:
Editors:
Update pages based on defined criteria and input from the briefing
Structure content with existing modules
Content Scrum Master:
Makes sure that the team has the right framework to work in and sticks to the process
Organises and facilitates meetings
Checks editors’ texts and provides feedback
Acts as a content coach and helps with questions
We also identified the following stakeholders:
Product managers:
Set business goals in a briefing
Are available to editors for questions on content
Check whether changes to content are factually correct
Publishers:
Create the page in the CMS based on editors’ suggestion
Publish the page
Translators:
Translate the page into the respective target language
3. Artefacts: Collaboration tools
Just like in Scrum, we worked with a backlog including estimates, sprint goals and a definition of done. Our backlog consisted of around 30 pages which we had prioritised based on criteria such as relevance or urgency. Editors estimated the required time and planned a backlog that would fit into the sprint. Our goal was to update 20 pages and get them ready for translation or publishing (definition of done).
4. Events: We used these as an opportunity for exchange
Before we began sprint zero, we started with a general overview in a sprint planning session. We discussed the process, defined work packages and presented all the tools. We assigned texts in the backlog to editors based on their expertise, playing to their respective strengths.
Although the name suggests something different, we did not do the daily meetings every day, but three times a week. They allowed us to measure progress and provide updates. Since the content team had never worked with the Scrum method before, we also used the meetings to answer questions.
After having completed sprint zero, we did a retrospective to review it. We reflected on and recorded what went well and where we ran into problems. We identified opportunities and impediments and noted down what we want to do with them in the next sprint.
The content sprints have proven to be a valuable tool in the content lifecycle. We gained a lot of new experiences.
What We Learned in Sprint Zero
We shortened sentences, simplified the wording and clarified the message. We questioned page structures and replaced modules. After the three-week test, we had 21 optimised pages ready for translation and publishing.
The content sprints have proven to be a valuable tool in the content lifecycle. We gained a lot of new experiences. This is our takeaway from the test phase.
Content Sprints Require Focus
Updating websites takes time and focus. Editors need to be able to focus on this task to do a good job of it. Content sprints should not be a side job on top of their day-to-day work. They need time that they can dedicate to working through the backlog. The challenge is managing the trade-off between their day-to-day work and content editing. One way to go about that is to do sprints when there is usually a bit of a lull anyway. You could also just staff the project with more editors.
Sound Preparation is Key
The backlog needs to be prepared and prioritised diligently for the content sprint. That means:
The websites to be revised need to be available in handy templates.
Relevant experts need to be brought in. They should provide input in a briefing.
Files need to be in a location everyone has access to.
The sprint process must be documented clearly, roles and tools need to be ready to go and accessible to all. To make editors fit for the task, we provided SEO and UX writing training ahead of the sprint.
Content Scrum Master as a Potential Bottleneck
To help editors improve their UX writing skills, the Content Scrum Master checked the texts based on predefined criteria. At one point this became a bit of a bottleneck because many texts had to be checked at the same time. One way to overcome this bottleneck would be to move this responsibility to a different role and split it between several people. Another way would be to integrate the review into the editors’ role as soon as they are familiar enough with the subject.
And So It Begins ... Again
Our first test sprint demonstrated the potential of the Scrum format for content revision at Swiss Post. Three weeks was not quite enough time to make any final recommendations. We are using the feedback from sprint zero to make a few changes. Sprints 1 and 2 will show whether the approach works for Swiss Post in the long run.
The content sprint was an opportunity to test whether our adapted processes work. This has made it easier for us to decide how to organise content generation in the future. The editors had a steep learning curve, which they accomplished through comprehensive coaching.
Marijana Sladic
Digital Consultant, Die Schweizerische Post
