How Much Documentation Should a Scrum Team Do?

I get this question invariably asked by almost every team that’s new to Scrum.

“Documentation that is just enough,” is the theoretical answer.

Almost always, the next question follows, “What’s just enough documentation?”

Just enough documentation is what serves the sprint purpose. Imagine the following scenario:

• Product: A Mobile iOS App in the Travel Niche
• Pretext: Version 1.0 of the App is already in the market and people are using it. It has generated a user base of about 15000 and many people have requested  different features via App’s support a feature option.
• Sprint Goal: Build and release version 1.1 of the already successful App. Version 1.1 should have 3 most demanded features by the end users. Out of 3 features, one feature required R&D and hence Scrum is a better choice.
• Sprint Duration: 2 weeks
• Team Size: 5
• Team Details: ScrumMaster (1), Product Owner (1) and Team members (3). Out of 3 team members, one is Graphic Designer, one is Software Developer and the 3rd one is App Support Executive.

Effective documentation in this case could be as follows:

1. User Stories for the 3 features
2. Photoshop PSD file with explanatory layer name and optionally a readme.txt file with bullets of specific instructions if any
3. Readable, modular, commented code that itself is self-explanatory with occasional in-code comments stating why a complex thing is done the way it is done
4. Updates in the App Support FAQs / Other Support Docs that are affected by introduction of these features

A Scrum team’s goal is to deliver value, fast. Above might act as just enough documentation for the needs. The good thing about Scrum is a specific ceremony called Sprint Retrospective which becomes instrumental in inspecting and adapting to what turns out as the right thing.

When we talk about documentation, often a question comes about the User Manual.

Let’s consider the same in the above scenario: Given it’s an iOS App, it won’t be a good idea to develop a User Manual for the same – The App’s UX should be so natural to the user that they don’t need to refer to the manual.

It is easy to agree to develop a user manual for an iOS app but in fact, that will be a disservice to the end users and the client itself – as you’re disregarding the manual-less experience that is possible to provide to the end user.

Or even better, provide the functionality built in app that enables the user to learn the App by seeing it in action. The need to documentation turned into a functionality!

Many people will say that if client demands, carry out the documentation. However, I do not buy into the idea that if your client requires XYZ documents to be created, you should carry them out without asking questions that provoke her to think – you should explain your client the value a particular activity will bring or the value that it will negatively impact. Sure, typically it is done by the Product Owner but as team members, if you decide to do something in which you don’t believe, you cannot deliver value.

Spirit of Scrum is not to negotiate but to collaborate – when you collaborate towards ONE goal, no one is superior to the other.

Sure in typical Business situations, you might have to do what might look like “anti-scrum” or not “scrum-friendly” – if you choose to do so, do it with awareness.