Performance & Load Testing

Resources Center

Traditional Vs AGILE documentation

It is said that Agile document is ‘just barely good enough’ and is produced ‘just in time’ and with ‘just the optimally right amount of content’. Less documentation and time spent in it saves project cost however this shouldn’t come at the cost of increased project risk of not documenting essentials. In this article we will notice how Agile and lean philosophies have shaped the documentation practices too and how those are different from the ones as observed in Traditional approach.

What are the documents created in waterfall (and other traditional) methods?

  • Project charter: Gives information about the scope, objectives and participants in a project.
  • Vision statement: It’s a 1-2 page document that focuses on the plan or main vision behind a particular project.
  • BRD: It’s an acronym for business requirement document. It focuses on questions like ‘what’ to deliver? ‘How’ to delivery? & ‘When’ to deliver?
  • Functional requirements: It consists of a list of all functional requirements for the software being developed.
  • Non-functional requirements: All the nonfunctional requirements like performance, usability, security, etc. are enlisted in this document.
  • Project plan: Contains the entire project schedule and plan. The document enlists the different resources that are working on a project and
  • Architecture & design: Describes at high-level the outline of the software and includes its major components. It also includes the list of drivers that can impact the architecture.
  • Wireframes: It’s a blueprint that gives skeletal framework of a website.
  • Test plan: Contains the test strategy, methodology, approach and list of test cases as will be covered while undergoing the testing cycle.
  • Deployment and maintenance plan: Talks about the deployment schedule, the team members who would be assisting the developers in deployment cycle. The approach that the team members will follow and risks.

How AGILE documentation is different?

Light documentation: In Agile stakeholders try to keep the documents light and low in terms of content. Teams don’t beat around the bush and try to cover all essential points in smaller content. The document is nimble and stakeholders keep in mind the rule of ‘too little documentation and you are in trouble, too much of documentation and you are overloaded’.

Evolving document: As the team progresses into sprints, the requirements and thus the documents keep updating and evolving. Every stakeholder is responsible for appropriate documentation for that project and in daily scrums; any changes to documents get discussed. Also since the frequency of updates is very high, a document management system is used to manage the various versions of the documents.

Document communicates: Communication is an essential key when it comes to managing projects involving cross boundary teams. In such scenarios documents play a key role and are used to track communication. In a lot of AGILE projects, the same concept is followed and laid a huge emphasis on.

Documentation throughout the cycle: In traditional methodologies a lot of time in the initial part of the cycle is invested into documentation and large documents are created. In AGILE documentation and changes on the same keep happening throughout the cycle. Thus agile projects can focus on implementation and delivery right from the beginning of the cycle.

User manuals: Agile doesn’t produce documents like requirements documents or design documents. However it does produce documents like user manual, operations manual, etc. The focus is not on producing ‘to-be-built’ document but on creating ‘as-built’ document.

Document ownership: In Agile the ownership of document lies with not just the project / test manager but it lies with every team member. In sprints as and when different tasks are identified for the team members, document related tasks can be assigned to them.

Thus Agile brings in a lot of differences when it comes to the documentation strategies. These strategies are further built upon the agile principles and inculcate a feeling of collective responsibility (on documentation), continuous improvement and focus on end product. Creating user manuals instead of requirement documents shows Agile team’s focus on serving the end product and its customer even while building documents that are essential to manage the projects. Collective ownership can inculcate a feeling of responsibility amongst the team members and can help each get more clarity on the project and the timelines. Agile thus brings a lot of improvements in the documentation methodologies and saves a lot of time when compared with the traditional approaches.

Learn more about QTest
Agile Software Security

More Blog