Demo, Review, and Retro - How to run successfully
Hello all,
First time posting here. I have been struggling with one of my teams for a year now. It's a highly toxic environment with extremely high turnover and tight deadlines. The issue I'm having is with demo, review, and retro. I try to show KPIs and numbers to help the team see what we committed to and what we accomplished, but I think I've run into what is described here: "If you don’t get buy-in on what you’re measuring, your team will resist those estimates and morale will drop. Low morale means an unhappier, less productive team, as well as predictive metrics that are even less useful over a period of time."
We didn't really have buy in from the team on what metrics to present. I was just kinda told what to show, and also suggested things to show. I think I've really not done a stellar job in my first year as a scrum master. I want to get better and I want to help heal the team the best I can from my position (if possible).
What metrics do you show? How do you run demo/review/retro? How do you handle a toxic team with low morale?
In Scrum the tight deadline is the end of the Sprint and the commitments are to a Product Goal, a Sprint Goal, and a Definition of Done. The deadlines and commitments you are alluding to appear to be something else and the Scrum Values are absent to the point of toxicity.
The right metrics and measures are those which establish maximum transparency over problems such as these, and which incentivize the higher-ups to create, communicate, and reinforce a sense of urgency for change.
How do you run demo/review/retro?
First, I do not run anything. I am a Scrum Master that allows the team to self-manage and self-organize. Second, the Scrum Guide does not list a "demo" as one of the events. Third, none of the events mentioned in the Scrum Guide list presenting metrics as part of the event.
I coach the team to focus the events based upon the descriptions in the Scrum Guide. I help them understand how that focus will benefit them. That is my responsibility as a Scrum Master.
Based upon what you have said, I would venture a guess that very little that is provided in the Scrum Guide is present in your organization except for some of the phrases and terms.
If you want to restore some confidence and order into the team, try listening to them. Ask them what they feel would be useful as a metric and why. Help them get the information that they need to feel like they are being productive and appreciated.
@Ian mentions the Product Goal and Sprint Goal. Those are the commitments that the team needs to focus on meeting. Each Sprint should have a different Sprint Goal that represents the reason that the Sprint is happening. "Finish all of the stories we pulled in" is not a valid Sprint Goal. "Provide the stakeholders the ability to retrieve information from previous years" could be but even it needs some work. The accomplishment of the Sprint Goals is what provides value to the stakeholders and is an indicator of how successful the Scrum Team can be. Finishing a bunch of stories in 2 days means nothing. That is a KPI that can be easily manipulated and provide no value. The goal of Scrum is to provide continuous incremental value to the stakeholders while getting their feedback to make adjustments on the work that will be done. That is the purpose of the Sprint Review.
The Sprint Retrospective is for the Scrum Team to focus internally. How did the team succeed as a team and is there anything learned that could be used to improve? Enter "retro ideas" into your favorite search engine and check out some of the suggestions. They are not about presenting KPIs. They are about discovering how the team feels they are working as a unit and soliciting ideas for improvements.