What is Agile Sprint Validation and what role doe the developers play within this process? Demonstrating the Sprint deliverables is an important part of the Scrum Framework.
Agile Sprint Validation: Demonstrating and Validating the Sprint
A 59 Seconds Agile Video Animation
Agile Sprint Validation for Developers
A 59 Seconds Agile Article
The key outputs of a sprint in Agile software development are the deliverables. These are standalone features of a product that work on their own. Each sprint creates one or more deliverables that get showcased at the sprint review meeting. However, just creating the deliverables isn’t enough. After developers create deliverables in the sprint, they must demonstrate and validate the deliverables. While these terms may not seem to mean much on their own, they represent vital parts of the Agile software development process.
Agile Sprint Validation: Demonstrate
The definition of demonstrating is to, “clearly show the existence or truth of something by giving proof or evidence.” In the context of Agile software development, demonstrating refers to showing the existence of deliverables. Also, the demonstration shows how each deliverable feature works. This takes place in the sprint review meeting, held at the end of every sprint.
So what is a developer’s role in the demonstration process? First and foremost, developers create the deliverables. Without developers, there would be no software to show off in a sprint review meeting. Analysts can only go so far as to create specifications for how software should behave. Quality assurance technicians can make sure that features match how they were designed. Without the developers, though, there is no role to turn specifications into working software.
Agile Sprint Validation: Creating the Deliverables
After developers have created the deliverables, it would seem that their role in the software development process is finished. However, they are still quite important in the demonstration phase. If questions come up in the sprint review meeting, developers are often most equipped to answer them. Other roles may know how the software was intended to behave. They may even be able to discuss what they’ve seen personally in testing. However, only developers who actively created the feature are properly able to address these concerns.
Agile Sprint Validation: Validate
The verb validate is defined as, “to check or prove the validity or accuracy of something.” While it may sound similar to demonstrate, there are specific differences. Within Agile software development, validate refers to proving that completed deliverables match the original software request. Where demonstration shows what the scrum team and developers have accomplished, validation confirms that it is what stakeholders wanted. This gives stakeholders the opportunity to confirm that the new deliverables are what they asked for. Like the process of demonstration, validation occurs within the sprint review meeting at the end of every sprint.
Validation is a vital step in Agile software development because of the gap between stakeholders and development. A request changes hands several times before development begins. Stakeholders give their request to the Product Owner, who must pass the request through any authorization steps in an organization. As such, misunderstandings can make the finished deliverable vastly different from what stakeholders expected. By giving stakeholders a chance to voice their approval or rejection, they aren’t forced to receive software that fails to accomplish what they wanted.
Agile Sprint Validation: Accept vs Reject
The core of the validation process is the acceptance or rejection of deliverables. For every deliverable that is included in a sprint review, stakeholders must decide to accept or reject the feature. This isn’t a time for fine-tuning and last minute adjustments, it is a single decision of whether the deliverable matches the request. If stakeholders have minor changes they would like to see in place, they can ask the developers to make these changes moving forward. If seeing the features in action changed stakeholders’ minds, they can put in new requests for those changes to be made later. A rejection is only applicable if the finished deliverable does not match what the stakeholders asked for. The Product Owner makes the final call on acceptance or rejection as the representative for the stakeholders.
Prev <— Continue Reading —> Next
Learn More: Successful Delivery in Scrum
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Prev <— Continue Reading —> Next
Learn More: Successful Delivery in Scrum
Demonstrating and Validating the Sprint
A 59 Seconds Agile Infographic
Prev <— Continue Reading —> Next
Learn More: Successful Delivery in Scrum
Prev <— Continue Reading —> Next
Learn More: Successful Delivery in Scrum
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: