This article looks to discuss Demonstrating and Validating the Sprint. This article is part 1 of a 2 section discussion on Demonstrating and Validating the Sprint.
The Sprint Deliverables
A 59 Seconds Agile Training Video
Validating the Sprint for Scrum Masters
A 59 Seconds Agile Article
As organizations migrate to the Agile principles, there may be questions about how the organization can prove that there is value in using a new project approach. The Agile Scrum framework relies on providing value through iterative development. Traditional waterfall does not show value to the organization and market until all items scoped during requirements and design are delivered at the end of a project. Agile scrum’s focus on delivery of the highest priority features first, failing fast, and using a model of inspecting and adapt to adjust processes and features to course-correct.
Validating the Sprint: The Processes
The scrum master as the owner of the processes for Agile projects is a key team member in guiding the team to ensure that the group lives up to the Agile principles. It will be the scrum master who works with the product owners, stakeholders and team members to ensure that processes, ceremonies, and artifacts that the team has agreed to and that the right team members are utilized and engaged.
During the life of an Agile Scrum project, each sprint execution cycle is designed to produce features that are production ready. Complexities are broken down into manageable features and user stories that align with delivery cycles.
Validating the Sprint: The Ceremonies and Processes
While they may not be introduced into the production environment prior to bundling with other sprint deliveries, the importance is that there are steps during the inspect and adopt a model that focuses on the value delivered. More complex projects where there are multiple work streams may require the services of multiple scrum masters. Those areas of the process are:
- Sprint Planning
- The Sprint Review and
- Sprint Retrospective.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Validating the Sprint: Sprint Planning
At the start of a project, the product owner has the responsibility to work with stakeholders and the scrum team to define the features that will be delivered to meet the objectives of the product. Each sprint will have its own sprint planning meeting where the focus is to identify the features and user stories that are next in priority order along with tasks and estimates for delivery within a time-boxed window. The product owner will present the goal of a sprint. This goal may allow for the inclusion of additional features or necessitate moving features out of the original priority order in order to meet dependencies and reduce technical debt.
Validating the Sprint and the Product Backlog
The product backlog is the primary artifact used by the scrum team to plan a sprint. In most cases, it is the Scrum Master who facilitates the discussion and guides the team through the Agile processes. A sprint planning meeting should last from 1-4 hours and produce a sprint backlog deliverable that lists:
- The goal of the sprint,
- Features and user stories to be included,
- Validation of the acceptance criteria,
- The respective tasks,
- As well as the assignment of those tasks.
The sprint backlog is then presented back to the product owner so that they understand the commitment that the scrum team is making to deliver value to the defined goal.
The Agile Sprint Review
A 59 Seconds Agile Video Animation
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.