5 Things You Should Never Say (or Do) During Sprint Reviews

 

One of the simplest Scrum activities to carry out is the Sprint Review. However, many teams frequently need to pay more attention to this crucial chance to evaluate how the work is progressing. From people's experience working with several groups of various degrees of experience, most teams consider the Sprint Review a demo, which is partially accurate but not wholly the event's goal. Teams should evaluate the work that has already been done, report progress, difficulties, and issues, and, most importantly, obtain input from the stakeholders if they want to benefit from the sprint review. Finding a Scrum master free course and enrolling in it is a good move because you can get a lot of insights from highly qualified mentors:

Prove that your work isn't finished:

Whether a team should highlight only finished work or mention unfinished work to indicate that a collective effort has been made is a topic of debate. According to my reasoning, while displaying incomplete work is consistent with the importance of transparency, the team may be exposed to more danger than gain due to misunderstandings about the project's current status. The completed functionality should be highlighted first, and any problems or obstacles that prevented other work from being finished as intended should be discussed afterward.

Say You Over planned or Under planned Your Work:

The plan should be viewed as something other than a forecast or prediction because a Scrum team develops a projection of what they think can be accomplished during a Sprint. The team should emphasize the value delivered rather than worrying about whether too much or too little work was planned. A helpful question is: Did the team's value fulfill the Product Owner's expectations?

Suggest you need to complete more points next sprint:

The Scrum team strives to give value, not points, as an addition. The number of narrative topics a team generates, and the actual value provided to the client or end-user may only sometimes be directly correlated. The wrong way to focus the team is to ask for or push for more points, which might result in point inflation that serves no one. The group should focus on finding the best method for delivering more excellent value through increased productivity, automation, and other innovation.

Say that you have nothing to display:

The team should keep the Sprint Review focused on the progress made and challenges faced in the unlikely but possible event that the team cannot complete any tangible functionality inside a sprint. It's okay if this sounds like a retrospective session; if the unit is in this position, it's crucial to talk about what went wrong and what needs to be done to better the results for the upcoming sprint.

Present slides rather than reviewing work items:

The Sprint Review is done for teams to show off a functioning product rather than discussing the product and what it could have been. The clients would benefit from viewing the product, even if it is not 100% complete, so resist the urge to talk just about metrics and present PowerPoint slides. While metrics are important, they are not what the consumers pay for. It is acceptable to display a screenshot of the inputs and outputs of a process if its execution needs a significant amount of time, such as when a process must run for several minutes or hours to finish.

Bottom Line:

Reviews of the sprints are not retrospectives. A sprint review highlights the team's dedication, including the product owner, designers, and developers. The sprint reviews are informal. Team members congregate around a desk for informal demos where they share their work for that iteration. It's an opportunity to inquire, test new features, and offer criticism. A key component of creating an agile team is sharing in success. If you have challenges learning things by yourself, getting access to free agile training online is advised. In today's world, the internet offers you many learning opportunities.