Benefits of using Wiki for Requirements Documentation

20 August 2013
Comments are off for this post

Recently, Atlassian shared the details on how they are doing agile requirements documention with Confluence.

Atlassian Tiiks

It also included a well summarized list of the benefits below.

1. One page, one source, one problem
Keeping it simple. The requirements page becomes the “landing page” for everything related to the set of problems within a particular epic. Having something that is the central go-to location saves your team members time in accessing this information and gives them a concise view.

2. A page enables you to be agile
One of the awesome things about using a simple page to collaborate on verses a dedicated requirements management tool is that you can be agile about your documentation! You don’t have to follow a format every time – do what you need, when you need it and be agile about it. In fact, I encourage you to customise the Requirements Blueprint as you learn what works for your team so you can model your processes easily. Chop and change as required.

3. Dive in for context and detail
We often forget how powerful a simple link can be. We embed a lot of links within our requirements landing page. It helps abstract out the complexity and progressively disclose the information as it is needed to the reader. Linking detailed resources my included such things as:

  • Customer interviews for background, validation or further context for the feature
  • Pages or blogs where similar ideas were proposed
  • Previous discussion or technical documentation and diagrams
  • Videos of product demos or other related content from external sources

4. Living Stories: Stay updated, track and report on progress
I see a lot of customers do this as well. Once the stories have been roughly thought out – we often use the JIRA integration features in Confluence to link the two. From the page you can easily create your backlog stories. These are automatically embedded with two-way syncing from JIRA. So you instantly get progress reports of how the story is tracking with your dev team, right from your requirements landing page. Learn more.

5. Use your collective team and organisational wisdom
Especially if you are in a large organisation – documenting requirements Confluence makes it easy for other people in different teams to contribute and make suggestions. In the Confluence team, I’ve been amazed at the amount of times someone else from another team jumps into the conversation with a comment providing great feedback, suggestions, or lessons learnt from similar projects. It really does help a large organisation feel like a small team.

6. Make them dynamic and engaging
Use diagramming tools like Gliffy or Balsamiq to better communicate the problems to your team or embed external images, videos and dynamic content.

7. Collaborate!
The most important aspect of all this is getting everyone involved. Never write a requirements document by yourself you should always have a developer with you and write it together. Share the page with the team and get feedback. Comment, ask questions, encourage others to contribute with thoughts and ideas. This is also a huge asset for a distributed team.

As for the details on how to do it, you can check out the full blog post at http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide