Most tools on the market offer little or no support for the important Scrum events Sprint Review and Retrospective. With simple examples we would like to show you in this article how Azure DevOps can provide great added value for your organization with small enhancements.
With each Sprint, a potentially useable product increment is delivered. This means that at the end of each sprint, the team has produced a developed, tested and usable piece of software.
A Sprint Review is held at the end of each sprint. During this meeting the Scrum Team shows what they have achieved during the sprint. Typically, this is in the form of a demo of the new features. This is an informal meeting, not a status meeting. The presentation of the increment is intended to generate feedback and encourage collaboration. A sprint review is a natural outcome of the sprint. Participants in a Sprint Review usually include the Product Owner, the Scrum Team, the Scrum Master, management, customers, and developers from other projects.
During the Sprint Review, the project is evaluated against the Sprint goal set during the Sprint Planning Meeting. Ideally, the team will have completed each sprint backlog item that was brought into the sprint. However, it is more important that the overall goal of the sprint has been achieved.
Azure DevOps offers many ways to support this meeting:
It makes sense to first look again at the sprint goal set at the beginning of the sprint in order to be able to evaluate the achievement of this goal during the review meeting. A good way to store this directly in Azure DevOps is the free add-on Sprint Goal.
Next, the burndown chart can be viewed to get an idea of whether the work planned for the sprint has been completed or if there is still some work to be done. These open topics in the form of stories can then be moved back to the product backlog, for example, and scheduled for the next sprint if necessary.
After the general overview of the sprint performance, the team demonstrates the sprint results. Different modes can be useful here - either the team goes over the Sprint Backlog Items (User Stories) 1:1 and shows their implementation, or the team focuses on the core functionality in general, which may combine several stories in the form of features (red continuous box, details per User Story dashed box).
In any case, it is important to document for each story whether the definition of done is met and the story is formally approved by the product owner. Ideally, the product owner has already seen the implemented functions before the official review date. The status of approved and tested user stories is thus set to Closed during the meeting, and any new requirements that arise are recorded in the product backlog.
If user stories planned for the sprint have not been completed or the expectations of implemented stories have not been met, they will be moved back to the product backlog, where they can be revised and scheduled for a next sprint.
Retrospectives aim at the continuous improvement of team cooperation. Typically, this meeting also takes place on the last day of the sprint, after the Sprint Review. Each team member has the opportunity to give feedback during the retrospective. The discussion within the team should lead to an improvement in the efficiency, productivity, quality and satisfaction of the team. The results of this meeting are therefore essential for the agile principle of a self-organized team.
We recommend above all to carry out retrospectives on site. If this is not or at least not always possible, Azure DevOps offers the helpful add-on Retrospectives. The agenda of a retrospective recommended by us corresponds to the thematic blocks Set the stage, Gather Data, Generate Insights, Decide what to do and Close the retrospective, as outlined by the PMI (see: https://retromat.org/en/?id=3-93-55-100-16).
Introduction by the Scrum Master / Product Owner.
Collect and document feedback on the following questions:
Grouping the collected feedback.
Definition of a weighting of the collected (grouped) feedback.
Definition of action measures to improve the issues found by directly creating action measures (e.g. in the form of a user story for the next sprint) from the grouped feedback items.
The measures identified directly in the retrospective and created as items can be tracked in the reporting dashboard by tagging, for example.
It is not always possible to conduct interactive workshops under ideal conditions onsite. If it is not possible to gather all participants in one place, Azure DevOps supports the successful execution of sprint reviews and retrospectives. For the Scrum Master especially small, free extensions offer a real added value. They allow reviews to be structured, conducted in a goal-oriented manner and documented.
Retrospectives can also be supported digitally. The shown add-on helps the team with reflection and documentation and thus forms the basis for continuous improvement.
In the next article in our DevOps blog article series we will show how projects with multiple development teams can work together successfully on a product.
