Pain is temporary, failure lasts forever

Lean, agile living for the running mother of Peter


A manual

Not having written a handbook or educational material for many years, starting up with a manual was hard. My final effort at my current position will be giving ground for a user manual.

But my first question was: which space does user documentation have during an agile project, for example if you're using scrum?

I believe it is important to include the people formulating the user manual in the team and the user manual should be part of the iteration increment. And the reason is this:
  1. You have failed a product increment if there is no useable software delivered.
  2. You have failed a product increment if the result cannot be used by the users.
And how can the users find the new stuff and how do they know how to use it without documentation. Of course you have the delivery notes but should a user collect all the delivery notes and try to find their way?

I'm currently thinking about the best form for a user manual in an agile project. One solution is of course a wiki: just add new pages and specify which version this applies to. Or something. But how does this work in an offline setting? For example, technicians in the fields. And not everyone loves reading on the screen: they like something to hold. Otherwise there wouldn't be so many books on for example Microsoft Word. As with everything else in an agile project you need to go back to the users and their user stories: which process do they want to follow when they get updated or learn about the application?

So, I'll be doing a classic Microsoft Word document with pictures and lists. And I'll continue thinking about how to deliver user manuals in agile projects.

Labels: , ,


Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home