Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
Stephen has worked as a Project Manager and is PMP certified, as well as certified by the Scrum Alliance.
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 desiring to not document too much and the stakeholders in the company desiring that the documentation is not 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 acknowledgement that tradeoffs 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 is needed. Lynn's team accomplishes this through conversation and collaboration, rather than through team members independently reviewing documentation written by one or two individuals. Documentation can be valuable, but it is not product of a project.
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, accomplishing the purpose of the project.
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 is 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 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 often referred to as 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.
The last form of documentation is verification that what is needed has been produced. This is related to testing that is done for each user story. Testing documentation involves specific test cases that can be grouped in test plans. These are typical for most project methodologies, but unique to Scrum is that these are primarily taken straight from acceptance criteria. The testing documentation is often reviewed with the Product Owner to obtain confirmation that user stories are complete as requested.
After Lynn's team understands how Agile values influence Scrum documentation and the different forms of documentation, the last thing she covers is the characteristics of Scrum documentation. The team may use different forms of documentation at different points but the characteristics should be consistent. Scrum documentation should be efficient, a priority, and completed throughout the duration of a project.
Scrum documentation should be efficient, as well as a priority. Setting aside time to complete documentation is a tradeoff. It is time that could be spent on project work. When being completed, it is important that the documentation is a priority. Not only that, but it should be done efficiently. The documentation should cover only what is needed, no more and no less. Not only that, but it should not take significant time to create or significant time to review for comprehension.
In addition to being efficient and a priority, Scrum documentation must be completed throughout the duration of a project. Unique to Scrum is the breakdown of the project timeline into shorter, repeated cycles, known as sprints. Documentation should be completed in cycles as well. This is in contrast to traditional methodologies that complete documentation all at once prior to a project starting. In Scrum, as the sprints progress and the team completes user stories, they learn and identify areas of change, which should be incorporated into new documentation.
The basis of Scrum documentation comes from Agile values. Rather than being bound to rigid processes, individuals have conversations and collaborate to reach a common understand. The focus is on producing working software rather than working documentation. The specific forms in Scrum include requirements documentation that can take the form of user stories and acceptance criteria, technical documentation that can be written as tasks or a formal specification document, and testing documentation that can be written as test plans or test cases. Whatever documentation is deemed necessary, it should only be done if it is a priority and should be done efficiently. Additionally, it should be done throughout the project in a cycle similar to the project's sprints.
To unlock this lesson you must be a Study.com Member.
Create your account
Did you know… We have over 95 college courses that prepare you to earn credit by exam that is accepted by over 2,000 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
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.
Back To CourseAgile & Scrum Training
9 chapters | 131 lessons
Next LessonEpic in Agile: Definition & Example