Scrum Documentation: Process & Example

An error occurred trying to load this video.

Try refreshing the page, or contact customer support.

Coming up next: Epic in Agile: Definition & Example

You're on a roll. Keep up the good work!

Take Quiz Watch Next Lesson
 Replay
Your next lesson will play in 10 seconds
  • 0:03 Basis of Scrum Documentation
  • 1:46 Examples of Documentation
  • 4:02 Characteristics of…
  • 5:24 Lesson Summary
Add to Add to Add to

Want to watch this again later?

Log in or sign up to add this lesson to a Custom Course.

Login or Sign up

Timeline
Autoplay
Autoplay
Lesson Transcript
Instructor: Stephen Meyer

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

Scrum is an alternative to the different aspects of traditional project methodology, including extensive documentation. Rather than a lack of documentation, the goal is to document only what is necessary. Learn the process of Scrum documentation in this lesson.

Basis of Scrum Documentation

Lynn and her team have been using Scrum to implement Agile for the past year. The team has gained familiarity and started to tailor the different processes to best suit them. One aspect that has continued to be an area of debate is documentation. Lynn is trying to find the balance between her team not wanting too much documentation and the company's stakeholders not wanting too little. She is confident that the balance can be found in Scrum.

Scrum is the most popular form of Agile, which is an alternative to traditional project methodologies. The basis of Agile involves valuing different project components over others. This is an acknowledgment that trade-offs exist within a project and that everything cannot be done to its fullest extent. Two Agile values in particular influence what is needed for Scrum documentation.

The first Agile value that influences Scrum documentation is an emphasis on individuals and interactions over processes and tools. The goal is for the different individuals involved with a project to reach a common understanding of what's needed. Lynn's team accomplishes this through conversation and collaboration, rather than through team members independently reviewing documentation written by one or two people.

Instead of focusing on producing documentation, a valuable project produces a tangible result. This is the second Agile value, which involves putting time and effort toward creating working software rather than comprehensive documentation. Any work or tasks Lynn and her team complete are done instead of something else. Instead of spending time documenting everything that could be involved with the project, the focus is placed on producing working software, which accomplishes the purpose of the project.

Examples of Documentation

Once Lynn helps everyone understand the basis of Scrum documentation, she moves into examples of the different forms it can take. The forms of Scrum documentation usually focus on one of three things. The first involves what needs to be produced by the project. The second revolves around how these things are produced. The third includes verifying that what's needed has been produced.

The first form of documentation, focused on what needs to be produced by the project, is relatively standard between different teams practicing Scrum. The typical form is a user story, which details desired functionality for a specific user. In Scrum, these are written by the product owner, who is the individual requesting the project. If Lynn's team was working on a file-sharing portal, an example would be: 'As an authenticated user I am able to upload documents so that other users can access them.' User stories are high-level requirements but also contain low-level requirements, known as acceptance criteria. These detail actions and results that accomplish the user story. For the file-sharing user story, an acceptance criteria might be: 'When I click Browse, I am able to select a file from my computer.' User stories and acceptance criteria are the primary form of requirements documentation in Scrum.

In addition to documenting what should be produced by a project, it is also important to document how these things are produced. This sort of documentation is usually called technical documentation. Unlike requirements documentation, technical documentation does not have a common form in Scrum. Some teams write tasks for the technical side of user stories. Others keep a formal document of technical specifications. Lynn's team uses both treatments depending on the project they are completing.

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

Register for a free trial

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
Free 5-day trial

Earning College Credit

Did you know… We have over 160 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 free for 5 days!
Create An Account
Support