What is Scrum Sprint Validation and what role doe the developers play within this process? Demonstrating the Sprint deliverables is an important part of the Scrum Framework.
Demonstrating and Validating the Sprint
A 59 Seconds Agile Video Animation
Scrum Sprint Validation for Developers – Part 2
A 59 Seconds Agile Article
Scrum Sprint Validation: Accepted Deliverables
If a deliverable is accepted, developers have successfully finished work on that specific feature. They can then move forward with other work in the product backlog for the next sprint. Even if stakeholders requested minor tweaks and design changes, developers can incorporate that into future deliverables. However, anything that is less important than the highest priority tasks in the product backlog will be postponed until later. Revisiting features that technically work, if not quite how the stakeholders envisioned, may give less value to stakeholders than new features that have not yet been created.
Scrum Sprint Validation: Rejected Deliverables
If a deliverable is rejected, it still requires some work to be finished. From this point, the Scrum team and developers in particular can go in a few different directions. A rejected deliverable is evaluated based on priority like any other task in the backlog. Typically, rejected items are usually scheduled to be worked on immediately. This is common for a few important reasons. Most importantly, this code is still fresh in the minds of developers who worked on it. Instead of having to come back to an issue weeks or months later, they resume work almost immediately. This reduces inefficiency, and addresses the issues that caused rejection quickly. Another benefit is guaranteed value in fixing these deliverables. Where new development has the potential to be accepted or rejected, fixing a rejected deliverable is almost certain to yield an accepted deliverable.
Rejected items that fall lower on the priority scale are inserted into the product backlog at the appropriate point. If the Product Owner defines the rejected deliverable as less important than new development, then the overhead of research is worth the delay. The entire goal of Agile is delivering valuable features to stakeholders. Developers create the software, but it is not their responsibility to determine what is most valuable, and what to work on.
Scrum Sprint Validation: Deliverable Confusion
Occasionally, there could be confusion on how certain features are intended to work. In these cases, stakeholders may be hesitant to accept a deliverable that is indeed what they requested. To remedy this, developers may be required to explain how a feature is working as designed. The software is intended to be intuitive and straightforward, but some features need explanation. Developers know best how software features work and can address stakeholder concerns most directly.
When deliverables are frequently rejected, the Scrum team needs to re-evaluate their process. There could be a problem in the intermediate steps between stakeholders and developers. Stakeholders give general requests of what they want the software to be capable of. The Product Owner and analyst roles on the Scrum team turn these requests into user stories and individual tasks for development. If deliverables are rejected, the issue could be in how tasks are created from stakeholder requests. With all roles working together properly, developers should be able to successfully create deliverables, and rejection should be rare.
Scrum Sprint Validation: Deliverables
Clearly, developers have an important role in software development, and in demonstrating and validating specifically. Even if many consider development finished after deliverables are created, there is often much more work involved for developers. Their understanding of software features and expertise in fixing problems with deliverables make developers valuable through to the end of Agile software development.
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
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: