Content and agile — how we're making it work for Style Manual

Working in agile and developing government content can sometimes seem like incompatible tasks. 

Two people working on the design for Style Manual content

Agile methods help us to get a complete piece of work done by the end of a sprint. They make sure we see rapid feedback on our product from users, which we can use to make improvements.

But the typical government content workflow usually involves some combination of:

  • Research
  • Drafting and redrafting
  • Peer review
  • Subject expert review
  • Taking in changes
  • Editing
  • Content critique (crit)
  • Sign offs at various levels
  • Taking in even more changes
  • Publishing

Getting from unwritten to ready for release can seem impossible if a 2-week sprint is the timeframe.

When we can't release and test our content early, we're not helping users. And we're being inefficient.

Earlier this year, our guidance team tested some methods for getting content done within sprints. They were simple but effective — we wrote, re-wrote and migrated 54 pages of content in 4 sprints.

We're now adapting these methods to the first-ever digital edition of Style Manual

Style Manual is the Australian Government’s authoritative source of rules and guidance on writing and editing. We’re now in beta stage for the updated edition, which will go live in 2020.

We have many dedicated users waiting for the new edition. We also have the usual constraints of needing to spend government funding wisely. So, we need to publish a lot of high-quality, evidence-based content in under a year. Failure to do so would mean we’d lose users’ confidence, not to mention overrun the budget we have for getting this work done.

Here’s an outline of the content delivery methods trialed by the guidance team — progress so far on Style Manual has shown they have scaled and are supporting a more complex product:

Break down content into an agile framework

If you’ve ever worked with a framework such as Scrum, you’ll be familiar with themes, epics and user stories.

We took these concepts and applied them to content:

  • Theme — a group of similar topics. In other words, a large subject area that might, for example, fill a book.
  • Epic — a specific topic within the theme such as a chapter within that book.
  • User story — 1 specific, complete idea within the topic.

User stories are familiar to anyone who has done content design. For our purpose, we defined them as 'the smallest complete piece of content that can be developed in one sprint and be valuable to the user'. In other words, 1 idea = 1 page.

This breakdown allowed us to do complete pages within sprints and to also stay focused on the larger goal.

Content basecamp

As much as possible, we worked on content as a group, coming together 2 to 3 times per week for 'content basecamp'. This was a workshop for getting content to the next stage in the production process.

Sticky notes on a large piece of paper

Caption: Content brainstorm — ideas for meeting the user story are generated on sticky notes.

Content basecamp could take 4 different formats over the sprint:

  • Content brainstorm — a free-flowing, unedited session for the team to generate as many ideas as possible for meeting a user story. We used sticky notes on a poster for each story.
  • Content structure — the team grouped and edited out ideas from the brainstorm. We then developed the heading structure and ordered the remaining sticky notes under each heading as the main points to be included. At this point, the page structure and content were clear. A content designer could turn it into a complete draft within a matter of hours.
  • Group writing — the team and subject experts worked on content writing together. It was our equivalent to the writers’ room for a TV show.
  • Content crit — the team, subject experts and product manager gave constructive feedback and finalised the content. Following this session, it was ready to publish and test with users.

Caption: Content structure: ideas are grouped and edited into main points, and page headings are finalised.

Subject experts embedded in the team

Getting subject experts who were invested in the content and available to the team was critical. Ideally, they were embedded in the team throughout the sprint. They needed to have both subject matter expertise and, where needed, the authority to sign off.

We onboarded them at least 2 weeks out from the sprint in which we would need them. We booked out their diaries and — if necessary — even interrupted meetings to bring them to content basecamp.

Style Manual is on track

We’re working with a content partner, Ethos CRS, on Style Manual and are adapting these methods to suit their business needs.

But using these methods has ensured Style Manual is on schedule to its first private beta release. By the end of November 2019, we will have published 33 pages of style rules and guidance. These include some complex topics and others that are new to Style Manual. As we’ve matured in our agile practice, we’ve also increased the amount of content we can do in 1 sprint.

Get involved in Style Manual private beta

If you have a email address, you can have access to the Style Manual private beta. Sign up to our mailing list to see the first content that has been created for this product in 17 years. You can also give us early feedback and get involved in user research.