Software Documentation in Scrum Projects

Dennis Crane

Scrum is one of the Agile methods of software development. It involves such things as sprint, roles, meetings, and artifacts. Every item is clearly defined, but it's up to organization how to blend them to get the best results.

To do your best as a technical writer in scrum team check out several must-know things below.

Work process in Scrum projects

Participate and collaborate with other team members

In Scrum approach, it's assumed that technical writers are members of development team thus they are "pigs" (in terms of "pigs-chickens" classification "pig" is a person who is committed to the project). Keep it in mind. For example, if the project is about to launch and sprint length is not chosen, participate in discussion so that your needs and your pace of work would be taken into account.

Set your personal deadlines

If you did not participate in sprint length negotiation, it's okay anyway. If product is released without built-in end-user documentation (it may be posted on wiki or product website) then you have some time after developers' deadline to finish your piece of work. In order to stay independent from such doubtful freedom it's recommended to set your own "writing cycle" if it's hard to keep rhythm of the team.

Keep it real

If it's impossible to accomplish your task for current sprint, it most likely means that you planned something wrong. Next time try to assign less things for one sprint. It seems trivial but nevertheless it works. So if you have something undone from last sprint, complete it first. That's what developers do as well.

Keep track of changes

Changes in customer's requirements is practically routine thing in scrum, and they affect technical writers. The best way to puzzle out sequence of product features to be documented is attending meetings and monitoring issues on bug tracker. A team of several tech writers can even delegate one of them to represent their interests on meetings.

Documentation structure in Scrum projects

Draft outline of help

Formalization suits technical writing, so create a structure of help. Include all known features, even those which developers are only planning to make. This way you will be able to see the overall future documentation. Then start filling sections with basic descriptions and update this information during each sprint. Instead of creating poems out of help just make sure that there is enough information for user to accomplish his task. Help authoring software often contains good aids for formalization, like topic management system in Dr.Explain. Besides flexible topic structure (creating sub-nodes, moving them up/down) there are topic statuses. For example, you can mark item as not started, completed, in progress, or waiting. They are highlighted with different colors so they can not be mixed up. If a section describes a feature that is only being developed, it can be removed from output by making it invisible.

Apply user stories

One of the differences between Waterfall and Agile (and thus Scrum) models is requirements. In case of Waterfall you get an unchangeable list of specifications which final product must match. In Scrum requirements have a form of user stories which you can use to make a draft of article. The best way to deliver a knowledge about program to user is to create a task-oriented help, like "to get this result you should do these actions". It's obvious that requirements in form of user stories fit such scheme perfectly.

Questions and feedbacks are not evil

Try to find out what users want in the beginning of work and ask for their reviews (and reviews of your colleagues) when you're done. If you know what users need in the first place, it will be easier to see what's essential for them and to do it first.

To sum up, there are two components of the successful Scrum technical writing:

  1. Technical writer is a member of developers team, he or she is fully enrolled in the process of creating and releasing end product. So feel free to consult other participants, customers and end users to get the best out of your knowledge about product features and deliver comprehensible and easy to use documentation.
  2. The work process is shaped by structuring help and setting timing and deadlines.

Remember these two main ideas, and you'll be surprised how actually exciting and gripping your activity can be.

Article Source:
You are permitted to reprint this text as long as it includes copyright notice and direct link to our web site.

See also