Add content into your definition of Done
This is an often-forgotten part of product delivery. I’ve worked with teams where the Definition of Done looked something along the lines of.
- Code is reviewed and merged
- UI changes are delivered according to design
- Automated tests pass
- Feature is released into a QA environment
- Story’s acceptance criteria have been met
- Story signed off by PO
While all of these are valid ways of designating a story or task as Done there is a glaring oversight that inevitably can creep up later in the project.
What about the content?
Content is the text, imagery, video, documents and copy which makes up your website, desktop, mobile or some other type of application. You cannot separate content from your production application, because without it your app can’t really exist.
Yet, in an effort to prepare & complete stories to close a sprint successfully, content may get overlooked. The goal of iterative sprints is to release working software with each release as close to your production output as possible. When test data or contrived examples are used as content placeholders the release increment is not as close to production ready as it could be.
The issues will stay hidden as your sprint will complete successfully. It only becomes apparent when real world content and data is used in the system later on. Suddenly designs break, validations are needed and new requirements emerge. Stories that we thought were done many sprints ago need to re-emerge or have bugs fixed. By this time the original developers working on it may have moved on or have lost the cadence and focus on these items.
So why does this happen? Let’s look at a couple of examples.
In one Scrum Team there may be a Business Analyst or QA Tester who will come up with acceptance criteria for stories. Inevitably these will be limited by the amount of time and information they have available. There will be a happy path and perhaps some exception criteria. Designers will make screens using ideal imagery and content.
Another Scrum team finishes their product release and hands off to another team to create content. In this case, having silo’d teams, you may find the Waterfall-Scrum (or “Scrummerfall”) methodology of delivery is being used in the project.
In both examples the main problem is content was not considered early on. That’s why ensuring production content has been used in your Definition of Done makes sure your team prioritises proper use of content in development — rather than retroactively once it hits user acceptance testing or is already in production… ugh!
I’m not suggesting that for development the Scrum team requires all of the production data the final product will require. In fact, with GDPR and some country’s personal data laws that would be an issue. It is about ensuring that the Scrum team are using content as close to production as possible.
Here’s some approaches your team can utilise to make sure production content has been used in the delivery of user stories and meet the Definition of Done.
1. Have customer or end user provided content
This may sound obvious but not having input from an end user means you will be missing valuable feedback on how they would anticipate using the system. If your team is only getting input from users before the product development starts or after it’s finished, you will be working with a lot of assumptions. The Scrum team should be getting valuable input every sprint.
For instance, I worked once on a project that required the address details of a new customer. The original criteria validated US zip codes, which are numeric. However this product was available to Canadian customers too and no one had checked what a Canadian address looked like — they use alphanumeric postcodes.
2. Identify content requirements as part of the story or user acceptance criteria
Take into account how different users of your system may input content. Ensure that you are working with real data and not just “Lorem ipsum” or randomly generated content. There should be a handful of examples that cover each use case scenario.
3. Use existing content
If it’s not a greenfield project there is likely to be plenty of content already existing, which can be identified and mapped to requirements.
4. Include a Content Strategist on your team
Have a member of the team who thinks about how screens and content will need to be built in production. They can actively work on tasks building content, ensuring it is being created correctly the first time.
When something comes up during content creation it can be decided to be a new requirement or a bug fix for the backlog.
By including production ready content earlier it removes the silos of different teams delivering a single product. For instance, where I have worked we included a Digital Marketer on the Scrum team in order to provide feedback to stories and actively build out content during sprints. This brought up potential issues a lot earlier during development, before the product went live.
By thinking of production content in a story’s Definition of Done, the team is more focused on delivering the value to the customer in that story, rather than just blindly following the technical criteria. For example, in a recent story to display events for a corporate website the team considered the differences in content by geographic regions. Some countries would have multiple time zones and displaying this was not part of the original criteria for that story.
While it may be impossible to take into account every conceivable piece of content that your software needs to handle, by following these approaches you can reduce risk and assumptions in your product delivery.
Here’s my improved Definition of Done.
- Code is reviewed and merged
- UI changes are delivered according to design
- Automated tests are passed
- Feature is released into a QA environment
- Story’s acceptance criteria have been met
- Production content has been used
- Story signed off by PO
Do you want to write for Serious Scrum or seriously discuss Scrum?
