Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Scrum Documentation Best Practices

Posted on: 02 June '14

Documentation in an Agile environment has been a highly debated topic.  It seems the Agile Manifesto places more value on working software than on comprehensive documentation. In fact, one of the Agile principles states, “Simplicity – the art of maximizing the amount of work not done – is essential”.  But does this mean we shouldn’t write documentation in Agile?  Not at all. I believe there are three key practices to effective Agile documentation.

1. Minimize Artifacts
The first practice is to minimize documentation to just what’s needed to get the job done.  While solutions such as software must be maintained and need supporting documentation (either as commented code or external documentation), there is a tendency to create documents simply because “we’ve always written them”, whether they are ever read or not.  Creating those documents expends valuable sprint hours and is counter to delivering the highest value first.  Documentation effort should be treated like a requirement; it should be estimated and prioritized along with other work.  This means weighing the cost of documentation against the anticipated benefit.

2. Simplify Efforts
The second practice to effective Agile documentation is to simplify the document creation effort.  My philosophy for documentation is 1) do only what’s needed, 2) do it quickly, 3) do it as simply as possible to serve its purpose, and 4) move on.  For example, instead of spending two hours making everything line up perfectly in Visio, take five minutes to hand-draw the diagram on paper and scan it if it needs to be distributed.  Also, keep documentation as succinct as possible while still conveying the needed information.  Draft it, review it, get rid of the fluff and finish it.

3. Document Later
The third practice is to create the artifact at the proper time during the sprint.  Just as “big-requirements-up-front” (a waterfall practice) was proven to be less effective in most software development, so is documenting concepts or strategies too early, instead of waiting to document more stable features.  Documenting later typically reduces the effort caused by changes that inevitably occur.  However, if documentation is put off until the end of the project, you run the risk of undocumented software if resources are constrained or reassigned before documentation is completed. Many agilists prefer building time into each sprint for the necessary documentation. In these cases, the “Definition of Done” should specify what adequate documentation means.

So, in the spirit of effective Agile documentation, the bottom line is to document only if it fulfills a purpose, keep it simple, and do it when it makes the most sense. We’re always interested in what others think about Agile. Let me know your thoughts on this topic.