If User documentation is part of the definition of done and there is no technical writer in the scrum team, how the situation is dealt?
Should the dev team create user documentation still
or
wait for the technical writer to be on the scrum team and let them take care of it
or
form a separate team of tech writers
or
let it be undone until the last development sprint?
In Scrum, the ideal would be to have all skills needed to deliver the product on the team. If part of your product includes user documentation, then that skill should be on the team as well. Note that it is the skill, not the job title. So, this raises the question: can your team write the documents?
If the answer is yes and the DoD contains that item, I would say that the team should do the work for each backlog item.
If the answer is No, you don't have that skill, then that raises other questions. For example, is user documentation actually required for the product to be done? Is there a reason that the skill can't be on your team (either add the team member or with cross-training)? If you don't have the skill and can't add it and it is required, then you clearly need some stop-gap measure for the short-term, but I would strive to resolve the gap as soon as possible.
the dev team create user documentation still
The reason for this is, that the team should be wholly responsible for the delivery of the sprint commitment. If part of this work includes technical writing, the team should complete this during the sprint.
There is no harm with the team asking for help from other more experienced writers outside the team and having learning workshops etc, but they are responsible.
During the Sprint Reviews, if there is a continual pattern of poor quality documentation the Scrum Master should work with management to solve this problem by bringing in someone into the team, upskilling the team or tweaking the team's backlog so that they do work better suited to them.
The development team is responsible for producing the product. All of the product. Period.
So either the development team needs to do what's described in the definition of done, or the whole Scrum team needs to rewrite the definition of done to not include the user manual.
Every single Sprint must result in a potentially-shippable increment of work. Furthermore, the increment must:
If documentation is part of your Definition of Done, then the only possible answer is that the Development Team is responsible for integrating documentation in each and every delivered increment of work. Whether that work is done internally to the team or "tossed over the wall" is irrelevant. The Scrum Team as a whole is still responsible for ensuring that all aspects of the Definition of Done are included in the product increment.
If documentation is part of your Definition of Done, and the team does not include it along with every increment, then by definition the work is incomplete. All work is either done or not-done, and since the increment doesn't meet the Definition of Done then you have effectively delivered nothing of value for the Sprint. Your current velocity will be zero, and your retrospective will likely focus on the colossal process fail that just occurred.
You can (and should) raise this issue as a process question for the team. Depending on business and team requirements, the team may decide to:
Make the product more self-documenting.
If it's a software product, you should be doing this anyway through comments, clear APIs, good naming conventions, and other effective programming techniques designed to enhance readability. You should also be writing BDD or acceptance tests in clear business language to create executable and self-documenting code!
Add the effort of writing documentation to each user story accepted into each Sprint.
The team should be doing this anyway! Whether you have dedicated tech writers on the team or not, the work still needs to get done, and must be included in your estimates for each Product Backlog Item.
Escalate the lack of a technical writer resource via the Scrum Master.
The Scrum Master should be helping the team to clear identified blockers. If this is preventing the team from meeting its goals, then it should be raised as a resource or process constraint with management.
Ensure the Product Owner is including documentation stories on the Product Backlog.
If the documentation can't (or won't) be included in each story as part of the Definition of Done, then the Product Owner must track the work as a Product Backlog Item and prioritize it accordingly. "No invisible work, ever!"
Furthermore, it's up to the Product Owner to ensure that team resources are allocated to the things that matter. If documentation matters, then the work (and the resources the work consumes) should be clearly visible on the Product Backlog.
Work the Product Owner (and by extension, the business) to exclude documentation from the Definition of Done.
This is an anti-pattern, and generally a bad idea. Nevertheless, if there's value in delivering product increments without the documentation, having a working product may be more valuable than waiting on the documentation to have a potentially-shippable increment. However, this must be explicit and reflected properly within the Definition of Done!
Laziness, lack of interest, or resource constraints regarding documentation are not in themselves sufficient justifications for excluding documentation work from your Definition of Done. In fact, even though the Agile Manifesto says:
Working software over comprehensive documentation
it simply means that the former is more important than the latter, rather than that there's no value in writing or maintaining documentation. Don't ever use "agile" as an excuse to deliver an undocumented (and therefore likely unusable or unmaintainable) system!
... whereas, I would dissent with nvoigt and say, "it's really up to the business." If they need documentation as part of the deliverable, and the team does not feel that they now possess the resources needed to satisfy that requirement, then an appropriate person needs to be added to the team, or placed under the team's direction for the purposes of this project.
I would consider this to be a management issue which should be discussed with the appropriate managers and stakeholders, promptly.
