Demonstrating And Validating The Sprint For Product Owners

Agile promotes an insect and adapt process where feedback from the users and customers is sought continuously rather than waiting until the end before validating the product and making improvements. It’s important to keep the quality of the product in development, and the only way to do that is to check on it every now and then as well as exposing it to users and customers. This article discusses a few different ways the Product Owner can validate their product to know that they are on the right track.

Sprint Review

When it comes to Scrum, time boxes ensure that feedback on the product is taken consistently: if the Sprint is for two weeks, then everyone knows they meet every two weeks. Even though feedback is welcome anytime from anyone, the best place to do that is in the Sprint Review.

The Sprint Review happens at the end of every Sprint and every Sprint should produce a potentially releasable product increment. The Scrum Team, the customers, and other key stakeholders should collaborate to inspect each increment and adapt the Product Backlog as needed.

Instead of presenting charts, reports, or slides, the Scrum Team demonstrates what was done. If the Product Backlog Items are in user story format, the team could opt to form a narrative so that the flow will be logical and easy to follow. Typically the developer that completed the work would demonstrate the functionality. The Product Owner should facilitate the Sprint Review since this is a meeting that will involve key stakeholders.

The Sprint Review is for the Scrum Team to get user feedback and openly discuss what can be done to improve the product. Although feedback is welcome, the Product Owner is not obliged to accept every change request, especially if it doesn’t fit their Product Vision. Nevertheless, inputs from the Sprint Review can add Product Backlog Items for future Sprints.

Developing and Testing Product Backlog Item’s

Because the Sprint Review is for demonstrating the product and getting feedback, it’s important to note that Product Backlog Items should have been developed and tested prior to the ceremony. Testing Product Backlog Item’s during the Sprint Review can use up a lot of time as well as look unprofessional to customers and users present at the meeting.

The developers should work with the Product Owner on validating the features developed as soon as they’re done. The Scrum Team should think of collaborating together to achieve the Sprint Goal and to meet the Definition of Done instead of rushing to a deadline.

A good practice would be to have an internal run-through of the Product Backlog Items in the Sprint Backlog. This would serve as preparation for the Sprint Review, as well as a venue for the Product Owner to validate the acceptance criteria for each Product Backlog Item.

Usability Testing

A great way to validate the product is to conduct usability testing. Usually held in a testing lab set up by the development team, usability testing allows target users to interact with a low fidelity paper prototype or a working software that represents the product. The tester navigates their way around the product on their own without the development team explaining the features. The raw reactions of the user are vital inputs to the product and are representative of how the general public would also receive the product when it’s released.

It is possible to use the Sprint Review meeting for a usability testing session. The controlled environment of usability testing can miss some other factors in validating the Sprint. Getting a closer view of how users would actually use the product would be in a production environment.

<– Continue Reading –>

Our Book Recommendations

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