Creating content in an Agile world

25 July 2023

I struggled to create good content in Agile timelines for a long time. Content strategies take time.

By the time you've crunched the numbers (or site analytics as those data people like to call them), understood the business goals, and done a little HCD to create a halfway decent strategy – weeks have passed.

And that's just planning. Add several more weeks to write and publish the actual content.

Agile is ALL about speed. Rapid delivery to market. Short sprints from user story to product release.

Content is about researching topics, complying with standards, and ensuring everything you write is consistent with content already on all your channels. Plus, it has to fit your brand guidelines and tone of voice standards. And it has to be user-centric.

Not the work of a single afternoon.


I work in a scrum team of 14 people. We work to 2-week sprints and ship something of value every week.

Some weeks go better than others – no surprises there.

My role in the team is Content Lead. I create all the content for our self-service portal and our app (and some other stuff, but that's irrelevant here). When I say all the content, I mean ALL.

I ensure the developers have signed-off content at their fingertips when they're ready to build – that's all the field labels, help text, error messages, confirmation pages, instructions, and general site content.

The content I produce has to fit our content strategy, agree with any other content on the same topic, be usable and accessible and be approved by our legal and compliance teams.

See why it takes more than two weeks?


How do I stay one step ahead of my scrum?

I work two, if not three, sprints ahead of my team.

I'm lucky. I work in a very organised team, so I know what's coming up. Four to six weeks before each feature is due for delivery, I work with our UX team to map out the customer journey and identify the information customers need to understand that feature.

From that mapping, I can tease out all the content needed and map it into a 'content skeleton' – a table detailing every bit of the new feature – for each feature.

I include formatting, links and even the names of the fields in the authoring view of the CMS to house each piece of content.

I can create this little beauty in my own time, use it for stakeholder sign-off and legal approval and have it ready for the developers when the sprint starts.


This skeleton of mine has lots of benefits:

And thanks to a good CMS that neatly separates content and development, I can manage my 'pure-content' pages in my own time. No sprints. I publish when I'm ready.