In Scrum, a basic principle is to deliver working software at the end of the sprint. For a webapplication, it is often obvious what this entails. Other than the functionality to be delivered, it also includes such things as text labels, error messages, help texts and user documentation. But for content-oriented websites (such as company sites), this is more challenging. After all, many websites feature sections for news, maybe a portfolio of projects or customers, a profile and a list of services or products.
Traditionally, many (smaller) webdesign shops approach these projects by first completing the website with dummy content ('lorum ipsum'). During the project, the customer is involved and reviews the website-in-progress periodically. At the end, the customer receives a login for their Content Management System and starts writing content, adding services, setting up the portfolio or populating the product catalogues. This is where things start going wrong:
- New websites get stuck in 'content writing' limbo: We, and most of our customers, often underestimate how much time it takes to write good content for a website. It not only involves the writing of texts, but also includes gathering of pictures, services and other information. It is not uncommon for a website to go live many months after the site was actually delivered by our team, simply because the customer could not find sufficient time to write or provide all the required content. This is obviously undesirable, as most websites are important means to attract new customers, generate revenue and build a network. Plainly speaking, money is lost by keeping the new website in limbo for so long;
- While writing content, problems are identified: The simple act of writing real content is very good way to test, identify problems, oversights and improvements in the design and set-up of a website. As a result, customers often start making change requests when they run into these bottlenecks. Because the development team has finished the website and started work on other projects, changes often take more time. There is also not always budget available for - often meaningful and useful - changes;
This approach feels like building a nice, good looking, heavily tuned car for your customer, handing them the key to the ignition and seeing them drive their shiny new car into a pond. It doesn't feel right.
The Scrum Way (and why it's hard)
While developing our own new website at NowOnline, we decided to take another approach. Instead of writing the content after the fact, we decided to add it to our Definition of Done. With the product owner, we decided to write content that fitted with the theme of the sprint. So, for the first sprint we focused on writing about NowOnline and some of our projects to populate our profile pages and our portfolio. Because populating our entireportfolio would take a lot of time, we decided that, for the sprint, it would be sufficient to begin with 10 of our most important projects. That way, we could review and test that part of our site in the first spring.
Several things really surprised us:
- We failed the first sprint: We failed the first sprint completely. In part because writing the content turned out to be far more time-consuming than we had estimated. On the upside, we did finish a lot of content that we could use in the coming sprints;
- Content allows testing of the site's concept: The most important benefit, at least in my eyes, is that writing the content helps us test a website's concept. We actually discovered that some parts of the concept, although very cool in the visual designs, did not work out well with real content. The initial design actually made it hard for us to update the site, because it required large, high quality pictures that are hard to come by. We also noticed that the initial design required too much content in a page to 'look good'. Third, we discovered that some of the real titles that we had written for our portfolio items did not fit the actual page! In our visual designs, the designer had always used short titles because they looked good. So, in the third sprint we changed the website's design to address these issues. As a result, we are now much happier with the usability and the way the content works with the layout;
- Functionality is really done: Because content is written as part of the sprint, that sprint's functionality is truly finished when the sprint is completed. This decreases the risk of a 'content writing' limbo that a website often gets stuck in. It's also more rewarding for the team and the product owner. It also allows a product owner to go live with a least a part of the website;
- Rewarding for the team: Instead of testing with generic 'lorum ipsum' content, the team is able to test the sprint's functionality with actual content (that looks a lot better). This is very rewarding;
- Add writers to the team:If your budget allows it, I would strongly advise adding any writers that are also contracted to the team. That way, they can work with the team to write content and optimize the website for that content;
Persuading your customer
Writing good content is very difficult. But it is also very important if you want to get the message of the website across. Some customers hire professional writers to help them out, while others write the content themselves or ask us to write it for them. Either way, I would strongly advise to write the website's content as part of the sprints. It may take some effort to persuade your customer (or product owner) to invest the budget, time and discipline. But in the end, they are better off. Instead of having a website that is stuck in limbo for a long time, they actually get to launch their website very quickly after the sprints are done, maybe even after every sprint. This avoids the problems that I mentioned above. But it also presents an interesting challenge, even to experienced Scrum Teams :)