Copyright

Agile Documentation: Methodology, Requirements & Examples

Instructor: Stephen Meyer

Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.

Agile seeks an alternative to an overemphasis on documentation by traditional project methodologies, but it still places some value on documentation. Learn about Agile documentation, including its methodology and requirements, and see examples.

Defining Agile

Luke has recently been hired as a project manager at a new company looking to change the way they do project management. He has been hired because he is experienced with Agile, an approach that is incremental and iterative, breaking down the primary project components of scope and timeline to complete smaller portions of work in more frequent, repeated cycles. The goal is to be more flexible and responsive to change.

Agile attempts to be an alternative to traditional methodologies of project management. These are typically linear and require each phase of the project, such as requirements documentation, to be complete before another phase, such as development, can begin. This can make traditional methodologies inefficient and document-heavy, things that Agile tries to remedy.

The executives at Luke's new company are mostly onboard, but they're concerned that since Agile is known to be not very documentation heavy, it will not involve documentation at all. Luke assures them that Agile does still involve documentation.

In fact, in the Agile Manifesto, which details the foundational principles of Agile, comprehensive documentation is explicitly identified as something of value. However, there is even greater value placed on working software. When a tradeoff exists, a finished, useable product is deemed more important than large amounts of documentation, but ideally a balance of both can be achieved.

Documentation Methodology

In helping his new company understand Agile documentation, Luke first focuses on the methodology, or how documentation is approached in Agile. The incremental and iterative approach used in Agile management is also applied to documentation. Using an incremental approach, documentation is completed in smaller amounts, rather than all at once. Using an approach that is also iterative, the process of working on documentation is ongoing and repeated throughout the project.

The thinking behind this methodology is simple: the most valuable documentation is for what is actually built. Luke further explains this using the Agile concept of minimum viable product (MVP), which involves enough of a finished product to provide value and get user feedback. In general, the goal is to find the point that maximizes the tradeoff between the value of the product and the effort involved to produce it. This same 'just enough' concept is applied to documentation.

Traditional methodologies that complete all documentation at once in the beginning of the project must cover everything that could be done within the project. Rarely is everything from this original process completed. In addition, there are requirements that come out during the project as stakeholders learn more. For the items that are not completed, the time spent documenting them is wasted. The items that come out during the project are simply not known at the beginning. Documentation is most valuable when it is done in smaller amounts and repeated throughout the project.

Requirements and Examples

The last thing that Luke reviews with his new company to help them understand Agile documentation is what its requirements consist of. He uses one of their recent projects as an example. One of the last projects the company worked on was an internal employee portal. The main constraint was a hard deadline, which was one of the reasons the end-product looked fairly different than what was originally documented for requirements. This would not have been the case with Agile - let's see why by going over the two main kinds of documentation it relies on.

User Stories / Acceptance Criteria

In Agile, the requirements that are highest priority are defined and documented first so that the team can work on these first. The primary form of requirements is user stories, which are a brief, high-level description of desired functionality for a specific user. The structure involves describing a user, their desired functionality, and the reason the functionality is needed. User stories are accompanied by acceptance criteria, which measure whether the user story has been accomplished by detailing specific actions and results.

For the employee portal, the highest priority was the home page. The primary component of this page was the company calendar, which shows upcoming company events. As a user story, Luke would have documented this as: 'As an employee I want to view a calendar of the current month with events so that I know what is upcoming.' The acceptance criteria that would accompany it would be, 'When I view the home page, I see a calendar for the current month.' Another would be, 'When I click a calendar date, I see a popup window with the specific events from the selected day.'

To unlock this lesson you must be a Study.com Member.
Create your account

Register to view this lesson

Are you a student or a teacher?

Unlock Your Education

See for yourself why 30 million people use Study.com

Become a Study.com member and start learning now.
Become a Member  Back
What teachers are saying about Study.com
Try it risk-free for 30 days

Earning College Credit

Did you know… We have over 200 college courses that prepare you to earn credit by exam that is accepted by over 1,500 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

Create an account to start this course today
Try it risk-free for 30 days!
Create an account
Support