Every single Sprint must result in a potentially-shippable increment of work. Furthermore, the increment must:
- Meet the "Definition of Done" defined by the team and acceptable to the Product Owner (representing the stakeholders).
- Be fully completable within a single iteration.
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!
Danger, Will Robinson!
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!