Why content deserves a place in your agile development process
May 09, 2017
Despite all the talk about its importance, every day countless websites are going live with no decent content. It seems that when it comes to agile working, content is often an afterthought. Or even worse: totally absent. We can’t possibly be happy continuing like this, can we?
Content is your bottleneck
Fi-na-lly! Your organisation is getting a new website. Your team throws itself into the ins and outs of selecting the right system and the right agency. It’s going to be agile. The planning’s tight, but it will be okay. Get the technical details sorted out first, and then tackle the content. The biggest slice of the budget typically goes on IT, which is logical, because no IT environment means no website. With a bit of luck, once the Content Management System is in place, some more money will be found to fill the empty shell with content. At which point, you are likely already too late. The work involved in content creation and content migration is nearly always bigger than you thought, and by leaving it until later, content is now the bottleneck in your project. Looked at from the technical side, you’re ready to go live. In terms of content? Absolutely not. Yet this is an easy problem to avoid.
A content specialist in your team
Start by including a content specialist. Decide per project if he or she should be part of the scale group or the scope group within the team, a decision that depends on where the site’s centre of gravity lies – some sites are simply more content-driven than others. But the most important thing is that this person is involved from day one. Because content creation is not normally required right at the start of a project, it’s tempting to only involve the content specialist further down the line. But the extra investment now will repay itself in saved time and money later, as considering content now will give you an earlier and better idea of what will be needed and when.
Connect UX and content
Before the developers start building a website, someone first figures out precisely what they are going to build. This is usually a UX designer, who plots the website in wireframes. Connect this person to the content specialist right from the start. The content of the website and its functionality are inseparable from each other. There’s no point placing a call-to-action button, for example, if there’s no text to go with it. And there’s no point having call-to-action text if there’s no button to enable it.
Your UX/ content duo will also prove invaluable during the user testing phase. Whereas the UX specialist will have a good eye for the user experience as a whole, the content specialist will focus on the details of copy and images.
Content as part of your definition of ‘done’
When there’s no real content yet available, it’s common to use dummy text and images to fill the CMS. But rather than lorum ipsum and pictures of cats, wouldn’t it be better to test real user stories and give a demo the client? Use real content and you know that content and functionality are reinforcing each other. Think of a fill-in field with not quite enough space for the text. Or an image that doesn’t scale properly.
When a sprint is nearly finished, however, problems like those have to go to the backlog. Yet these kinds of problems can be discovered and solved before you deliver the final functionality. You could even decide to treat a user story as not finished until the content is there. Add this to the definition of done for the story and attach points to the work involved in your backlog refinement process. With client demonstrations in particular, it’s not unusual for many of the comments to be about the written text, rather than the written code. Often these comments are dealt with by saying ‘it’s just content, we’ll fix that later.’ Writing code is something that is generally too complicated for most people to have an opinion about; but everyone has an opinion about text, even though this is just as much a specialism.
Content sprint
The team delivers new functionalities in each sprint. One time it’s a homepage, or part of a homepage; another time it’s a product page, and the time after that another type of page. As long as there is only one version of each page, your team’s content specialist should be able to handle it. With a homepage, for example, you only have to create the content once. But this is very different when it comes to product pages, as every product has its own page. This creates a problem if you have dozens, hundreds or even thousands of pages all needing content. For bulk work like this, it’s a good idea to create a separate content sprint, or maybe even several, and set up a parallel team that can focus entirely on content creation and migration.
Ideal situation
If you follow the advice above, content should never be a bottleneck. And even in the worst case scenario, you will have insight into what you still need to do in terms of content, which must be better than things are now, isn’t it?
