Documentation in Agile

Increasing the Agile mindset and creating higher performing teams can pose quite a bit of a challenge even to the most experienced of agile coaches.

Will endeavor to set up a weekly post with a small collection of hints and tips and gotcha’s to avoid 🙂 

“Just Good Enough”

Being Agile doesn’t translate to no documentation. Instead, in Agile Scrum, documentation should be “Just Good Enough“. Traditionally, entire cottage industries are created through the need to document and audit everything. This is not necessarily so true in Agile. Stories and Tasks are documented just enough to cover the delivery of the feature. Once the feature is delivered, it is very rare for anyone to refer back to old stories and tasks.

Having too much documentation will run the risk of becoming mini-waterfall within your sprints. 

Epics and Feature Briefs

Agile Epic to Story

Epic and Feature briefs are small one-pagers that describe at a high level the epic or feature being developed and has sufficient information to allow for meaningful conversations to take place. If you are seeing mini-project initiation type of documents detailing each epic or feature, you are running the risk of over-documentation.

Avoid distributing risks and assumptions across these briefs. Instead have a central risk and assumptions area in your wiki/team space and link the relevant epic or feature Id there.

Documenting User Stories

Documenting user stories should follow the INVEST rule and focus on having sufficient information to allow a delivery team to have a conversation with the product owners and break the story down into technical tasks as part of their sprint planning. 

I will not explain INVEST here – there are many great articles on the web that can do that significantly better than I can 🙂 The main purpose here is to ensure that there is enough for that conversation to take place.

Maintaining Traceability

Gotcha #1: Technical teams may start breaking down their tasks as per the screen wireframes (instead of taking each story). This will result in a disconnect between the stories and the tasks. A screen wireframe may have multiple stories within it, but the team may have difficulty in assigning the right tasks to the right story.

The result will be a single story that will suddenly have a lot of tasks in it and other stories with zero tasks. If you see this, stop immediately, and re-focus the delivery team to work off the stories themselves and not the wireframes in isolation.

It is also useful for the team to have a holistic view of the wireframe screen they are delivering, and possibly superimpose the story cards over the screen. This gives them the overall view of the screen and expected behavior and still allow them to go into detail as required.

It is key to review the stories and tasks and ensure traceability between the “what/why” and the “how”.

Leave a Comment

Your email address will not be published. Required fields are marked *

*
*