I’ve said it before: the docs need to be on the team’s Definition of Done (DoD). But in practical terms, what does this mean? Where do they fit? How does the team decide?
Many others have gone into more depth about what the DoD actually is, but I think the guidance from the Scrum Alliance will be the most helpful as we explore how to include the docs. If you’re not even sure what the DoD is, I strongly recommend you read that first and then come back.
Why include the docs on the DoD at all?
You've hired a technical writer to create documentation for your product. Great!
Why?
This is a serious question. Did your customers explicitly ask for it? Did you want to lighten the load of your support staff? Does your competitor have docs? Do you simply believe that documentation is an important feature of a good product?
Whatever your reason, you didn't hire a new person – and subtract another salary from your bottom line – for no reason. There's a business reason for it. And that business reason tells you why the docs need to be on the DoD.
Your customers asked for docs: Docs need to be on the DoD because your customers expect their request to be fulfilled and will be very upset to see it missed. If you miss docs delivery, what reason will you give? Your team didn't feel like it? It wasn't prioritized? Seriously, tell me the reason you'll give the customer. Go ahead. I'll wait.
You want to lighten the load for your support staff: Docs need to be on the DoD so you don’t waste your team members’ valuable time – and the valuable money that time represents – on questions that a website or a piece of paper can handle just as effectively.
Your competitors offers docs: Docs need to be on the DoD to either meet or exceed the expectations set by that competitor. If your competitor releases docs well after software releases, then releasing docs alongside the software helps you stand out. If your competitor releases docs alongside the software, releasing docs after the software makes you look lazy and disorganized by comparison.
These aren’t the only reasons you might want or need docs, but there’s definitely a reason you’re planning for them. Whatever that reason, knowing the business case will help justify the docs’ place on DoD when the time comes.
Applying the methodology
Now that you know why you need to include the docs on the DoD, let’s figure out where on the DoD they belong. Let's think about it in the terms the Scrum Alliance suggests:
There are various factors which influence whether a given activity belongs in the DoD for a feature, a sprint or a release. Ultimately, the decision rests on the answer to the following three questions:
1. Can we do this activity for each feature? If not, then
2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release!
Additionally:
It is important to note that the generic nature of the definition of done has some limitations. Not all value-added activities will be applicable to each feature since the definition of done is intended to be a comprehensive checklist. The team has to consciously decide the applicability of value-added activities on a feature-by-feature basis. For example, following user experience guidelines for a feature that provides integration point (eg: web service) to another system is not applicable to that particular feature; however, for other features within the system that do interface with a human being, those user experience guidelines must be followed.
This paragraph in particular goes back to why you should put the docs on the DoD at all. Documentation is clearly a value-added activity, and whether it applies to every single feature or sprint, it's crucial to the release and can often be applied to features and releases as well. Let's take a look at some of the ways documentation fits in.
"Can we do this activity for each feature?"
On the documentation level, the answer is a yes. Although you may not need documentation for every single feature, any user-facing features (or user-facing elements of back-end features) require documentation. Similar to the UX example from the second Scrum Alliance quote above, documentation may not be required on every single feature, but for features that do have a user-facing component, documentation must be completed.
(Remember, “user-facing” is a relative term. For the docs, the “user” is the docs audience. This could be anyone from a developer to an end user; it all depends on who your docs target.)
"Can we do this activity for each sprint?"
Once again, this is a yes for documentation. To be clear, documentation won’t necessarily need to happen for every single sprint. Especially at the beginning of a project, when much of a sprint is about building out the underlying architecture, docs might not be necessary at all. However, as the team begins to build out user-facing functionality, you’ll likely need at least a small amount of documentation each sprint.
Additionally, although there may not be topics required for a given sprint, that doesn’t necessarily mean there’s no docs work at all. The technical writer may still have documentation work to complete, such as setting up their information architecture or user-testing the docs to find the best options for content delivery. Work with your writer to confirm what work, if any, needs to be done each sprint and make sure that it’s reflected on the DoD.
"We have to do this activity for our release!"
Yes! Documentation is absolutely required for the release. And to be frank, it's much easier to provide docs for a release if they’ve been built over the course of the creation of a feature rather than all at once at the end. (Tech Beacon has a great article about this.) By adding the writer to every step of the process, baking them into it, you'll get a higher quality documentation product as well as all the other benefits of having a tech writer on your team.
If you want high-quality documentation for your product, you absolutely must add the documentation to your team's DoD. The change itself is small, but the effects are enormous in terms of your ability to deliver a complete product that delights your customers.
Want to learn more about docs in Agile? Check out my eBook, “The 12 Principles of Agile Documentation.” Learn how the original 12 Agile principles apply to documentation, how to change your thinking to accommodate documentation, and the benefits you can get from bringing the docs into the fold.
