Documentation in Agile: How Much and When to Write It?

The agile methodology does not follow the phased approach like SDLC (Software Development Life Cycle) and therefore it requires very less documentation in order to accomplish the project completion. But Agile methodology at the same time cannot be misunderstood with no Documentation in Agile model, instead, we need only those details documented for the project which are actually required to run the project and nothing more than this. The following documentation approaches are recommended for the Agile methodology.

1. Working software over all-inclusive documentation:

The end goal of Agile methodology is to get the project working in very less time and with very minimal project documentation. Agile methodology is adaptable with the ongoing changes in the project requirements. Therefore, all-inclusive documentation is not required to build the software product, but only the key information that impacts the project such as user stories, end user experience, tasks and processes to accomplish the project, etc. is required and thus do not require the structured documentation as it is followed in the SDLC project methodology.

Documentation in Agile: How Much and When to Write It

2. Less project related artifact can be better:

The agile methodology does not require a complete library of the project documents but instead, it just requires less project-related artifacts i.e. the artifacts which are actually important. As we know, writing the detailed documents in the decided format takes time and it impacts the project end deliverables timelines for its various phases. In the Agile methodology, we can easily save this time by writing minimal documents as per the project need instead of writing all inclusive documents for various project phases as in the case of SDLC.

3. The balance between documentation and discussion:

In the Agile methodology, the prime focus has given to the discussion instead of documentation. The Scrum call set up by the scrum master to discuss the open issues daily and track down the status. Since all parties are present on the scrum call at the same time therefore, the issue resolution gets expedited instead of back and forth that happened when requirements are documented. In Agile methodology, the requirements can be changed at any point of time in case they are captured incorrectly. But, such flexibility is not available in SDLC and in order to deal with any last moment requirement change in SDLC it incurs lots of effort as well as time. Therefore, the Agile model keeps a balance between the documentation and discussion in order to fetch the best output for the project. Such measures make the project to run smoothly and the sprint can be completed within the planned timelines.

Documentation Criteria in Agile Methodology

While preparing the required project documents for the Agile Methodology, the following things should be kept in the mind.

  1. Essential: We should document only the essential details in the project document but not the detailed stories which may not be useful at all. The document should have good enough detail to run the project.
  2. Valuable: We should document only valuable information which are actually required now but not when we want it. In other words, we should be capturing details which are required in the near future but not all the details what we need at some alter point of time in the project. This is because the Agile model is adaptable to the requirement changes and therefore, we should only be worrying about the near future only for the project Documentation in Agile.
  3. Timely: We should not write document along with the planned date into phases but they should be done in a just-in-time (JIT) manner i.e. prepare the project document when we actually need them and make sure they are made available on time.

Process Description

In the Agile methodology, we should define the process from the end user perspective including the details about the inputs and outputs.  We can define the project processes by simply gathering the answers to the following questions.

  1. Who is the end user? We should know who is the end user of the software product. i.e. if the end user has the technical knowledge or not, age of the end user i.e. they fall under the adult category, veteran category, etc.
  2. What do the end users need? We should be clearly defining the expectation of the end users that defines the clear picture of the project requirements.
  3. How do you deliver it to the end user? Here, we should be providing the solution to the requirements of the end users in terms of look and feel of the product UI as desired by the end user, report desired by the end user, etc.
  4. How do you know when they’re ready for it? We should learn about the end user’s past experience and the way they deal with their existing software products. It provides an idea about their expectation for the new software product.
  5. How do you produce it? At this section, we should be defining about the required technologies, a book of work, and a modular approach to fulfill the end user’s requirements into solution.
  6. What inputs do you need to produce it? We should be defining a set of user inputs along with the expected outputs based on the end user’s requirements. Listing down the inputs, provide a crystal clear idea about the end user requirement in order to process these inputs into outputs. After all, we are building software product for the end users and not for us therefore, this step is very important and required to be documented diligently.

Conclusion

The documents for the projects in Agile methodology should be emergent. Whatever Documentation in Agile are created for the project development are useful for the entire team and therefore it is the responsibility of the whole team to maintain it at some centralized location such as SharePoint, etc. which is accessible to everyone in the project. The project documents created in Agile methodology should have a high return on the actual time invested in writing them as Agile model is very time sensitive.


⇓ Subscribe Us ⇓


If you are not regular reader of this website then highly recommends you to Sign up for our free email newsletter!! Sign up just providing your email address below:


 

Check email in your inbox for confirmation to get latest updates Software Testing for free.


  Happy Testing!!!
 

Leave a Comment

Share This Post