Technical documentation/translation in Scrum

Hi Gina

There are 3 roles in Scrum - Product Owner, Scrum Master, and Development Team. There is no express recognition of a Technical Writer role, or for that matter other common roles such as Business Analyst or Tester, and there are no role specializations within the Development Team - there are only developers.

The way a Scrum Team handles documentation is therefore up to them. There might be a Product Backlog Item for producing documentation, for example, and the Development Team would bring it into a Sprint Backlog and work on it at some point. Alternatively the production of documentation might be included in the Definition of Done, if that documentation is needed for each increment to be considered potentially releasable.

At an enterprise scale this model can become attenuated, as there are many roles and specializations. The situation you describe is a common one and the approach you have adopted (i.e. create a Scrum Team in which the "developers" are in fact tech writers) is sensible.

What you seem to need now is an enterprise view of Release Planning, and particularly of the "Release Train" in which the inputs of different teams (including tech writer teams) are brought together to create a Release. Frameworks such as SAFe, DAD, and DSDM have things to offer in this regard. If you haven't already done so, I suggest you take look at them for ideas. This is a significant topic in contemporary agile practice.

Thanks Ian!

I have never heard of a release train or the frameworks you are talking about, so I will definitely do some research.

Posted By Gina on 25 Jul 2013 02:21 AM
Hi all,

A short introduction
I work as a technical writer at a company with quite a few development teams (I believe the current count is 16). All these teams work with Scrum. Because of this, the releases are done on an almost daily basis. Until recently, the writers were part of the teams, but the documentation team grew along with the company and we became our own scrum team. This means we have our own sprint, but keep the release dates of the functionalities in mind to make sure we don't become the impediment (it's a challenge). We also have our own scrum board and process, as well as a definition of done.

So my questions are:
Do others work this way?
And, if so, how exactly do you integrate documentation into the release cycles of all the teams?

Then translation:
How is translation integrated into your process?
Is it part of your definition of done?

Thank you in advance for your replies.

Gina Ketelaars

Hi Gina,

Is there any specific reason why the documentation team needs to be its own team instead of having each documentation team members embedded with the engineers?

Hi Joshua,

We used to work with writers embedded in the teams, but the set up was such that one writer had to cater to three, four, sometimes five teams. It became unworkable. Plus during holidays or when someone fell ill, there were huge issues to solve. Of course, capacity is still something we struggle with, but at least now we can divide the work better and become each other's safety net.

Hi Gina,

Why does it become unworkable? Did you discuss it with the engineers during retrospectives?

We did. But being part of three to five teams and thus three to five retros, groomings (usually this one was twice a week), plannings and daily stand ups, was taking away too much time. Not attending these meetings, or just a few, resulted in not entirely being part of the teams. Plus, it is difficult to fully be a part of three teams anyway. We couldn't commit.

Now, with our own team, we can attend our own meetings and talk to the SMEs in our own time, outside of meetings. That bit works very well. Now the integration of the rest of our process...