Technical Writer in Scrum Team

Why not begin by framing the technical writing tasks which will be needed to create an increment of release quality? For example, those tasks which are specific to a particular Sprint might reasonably go on the relevant Sprint Backlog. Those which apply to all Sprint increments might reflect more general quality considerations which ought to be articulated in the Definition of Done.

It would then become a matter of ensuring that the Development Team has enough Developers with the appropriate skills to accomplish that work. In Scrum, a team should be encouraged to self-organize around the work which needs to be done as much as possible.

Thanks Ian. 

Actually I thought of couple of options but not sure which could be the better option to start with.

1) Creating documentation task against each user story and have this included in DoD. So, done user stories should also have documentation completed. But we have resource constraints at the moment and I don't see this option working because we have multiple products and multiple Sprints.

2) Creating separate user stories for documentation and get them sized and include in the regular Sprints. If we do so, does it really make sense to merge business user stories and documentation stories in same sprint. I'm not comfortable merging it because sizing documentation stories and business stories are completely different. Also ideally, documentation might need additional day or two to finalize the documentation once development completes. Where do we engage development team during this period?

3) Creating separate Sprints for documentation. In this case, same project will have development and documentation Sprints.

Could you please share your ideas?

Creating documentation tasks against each user story and including this in the DoD would be in line with my suggestion. But do you think:

• separate "user stories" for documentation, or
• a separate "sprint" for documentation

would represent the proper use of either user stories or sprints?

I appreciate your feedback Ian. As I said, we have a resource constraint at the moment. One tech writer can't be divided in 4-5 Sprints. I think I would go with separate project for documentation until I sort out the resource constraint issue and let the regular Sprints move ahead.

 I've just experienced a five-year "run" as a technical writer who is a member of a scrum team (along with QA and Dev people.) One way we addressed the "waste of waiting", or waiting for our time with a subject matter expert,  for technical writers was to define the feature documentation as part of the definition of done.  Our scrum team consists of four developers, two QA, and one technical writer.  Because we were in on all story storming sessions, we had our notes and recordings of the sessions and could start documentation on day one of the sprint.  We also were included in demos where would then understand and know of any changes.  The final hand-off from the developer to QA and Documentation would then clear up any missing bits of information and access to TFS for bug tracking gave the technical writer information between QA and Dev - also access to QA test cases where we could leverage each other's work.



I was successful at getting in a sprint team by being the technical writer who finally found an advocate with the ability to get me a chair at the table.  That took time and it also took my own personal time learning Scrum, Lean, and any other buzz word so I could be valuable as soon as I could.



I wonder why a person who has work experience in technical communication is left out of SCRUM/Agile teams.  Communication is essential to many parts of the process.

 

Our scrum team consists of four developers, two QA, and one technical writer.

What does the Scrum Guide have to say about the roles which constitute a Scrum Team?

I wonder why a person who has work experience in technical communication is left out of SCRUM/Agile teams.  Communication is essential to many parts of the process.

Why do you think people with certain skills are left out? Is it because of the absence of sub-roles in Scrum, and if so, can you see why sub-roles would be problematical?