Demonstrating and Validating the Sprint for Developers

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.

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.

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.

59 Seconds Agile - Demonstrating and Validating the Sprint

59 Seconds Agile – Demonstrating and Validating the Sprint

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.

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

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

Share
Translate »