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.
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.
<– Continue Reading –>
Our Book Recommendations
We found these books great for finding out more information on Agile Scrum:
Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)
Introductory Offer: Free Course
Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)
What is this course?
This ‘Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)’ provides an in-depth understanding of the Agile Scrum Developer roles and responsibilities
You will explore the Agile Scrum project life-cycle, including how an Agile User Story is created, to how we know when it is ‘done’
This course is aimed at those with or without prior knowledge and experience of the Agile values and principles
During this course you will learn the tools needed to succeed as an Agile Scrum Developer
What will you learn?
You will gain an in-depth understanding of the Agile Scrum Developer roles and responsibilities, and you will be able to
- Fully understand the role of the Agile Scrum Developer
- Understand the roles involved in an Agile project
- Create an effective Product Backlog
- Effectively participate in Scrum Meetings such as the Daily Stand-up, Sprint Review and Retrospective
- Identify the roles involves in the Scrum Team
What topics are covered within this course
You will cover the following topics during this course:
- An Introduction to Agile Project Management (Developer)
- The 12 Agile Principles (Developer)
- Introduction to Scrum (Developer)
- Scrum Project Roles (Developer)
- The Agile Project Life-cycle (Developer)
- Acceptance Criteria and the Prioritised Product Backlog (Developer)
- Initiating an Agile Project (Developer)
- Forming the Scrum Team (Developer)
- Epics and Personas (Developer)
- User Stories and Tasks (Developer)
- Implementation of Scrum (Developer)
- The Daily Scrum (Developer)
- The Product Backlog (Developer)
- Scrum Charts (Developer)
- Review and Retrospective (Developer)
- Validating a Sprint (Developer)
- Retrospective Sprint (Developer)
- Releasing the Product (Developer)
- The Communication Plan (Developer)
- Formal Business Sign-off (Developer)