Skip to main content

Quarterly Team Reviews and Retrospectives

Last post 05:40 pm September 14, 2019 by Daniel Wilhite
7 replies
08:40 pm September 11, 2019

As quarters come and go, I thought it would be a nice idea for the team to reflect on some recent successes and open up opportunity to perform actions we don't typically do on a Sprint by Sprint basis. Take for example fully reviewing the Definition of Done. But I'd also like to provide the teams opportunity to try out some ambitious ideas and take some innovative risks.

I don't imagine I'm the only one out there. What are some strategies other like-minded folks have tried? Any tips or key learnings? The goal isn't to just review team performance and predictability variances, but to re-recognize individual achievements and the like.

I've worked at a few companies who do this in very different ways. Some do surveys and others show multi-Sprint metrics. I like the idea of surveys but they have caveats and feed better into an annual review.

So yeah ... anyone doing activities like this and how's it going for you? I want this to be fun. Thanks in advance!

09:29 pm September 11, 2019

Perhaps a review of Kaizens over the past 3 months?   The Team can discuss what worked, what experiments failed, and potentially stimulate conversation around additional ideas for improvement.

Also, such a checkpoint serves as a good opportunity for the Scrum Team to reflect and see the incremental changes they've taken to get to a better place than where they were 3 months ago.   Sometimes, that isn't easy to see when the changes are small.

03:14 am September 12, 2019

Take for example fully reviewing the Definition of Done.

There’s something right there. Not just reviewing the DoD itself, but also why it isn’t being “fully” reviewed every Sprint, the technical debt that incurs as a result of any deficit, and how inspection and adaptation of the DoD can perhaps become timelier.

09:41 am September 12, 2019

There’s something right there. Not just reviewing the DoD itself, but also why it isn’t being “fully” reviewed every Sprint, the technical debt that incurs as a result of any deficit, and how inspection and adaptation of the DoD can perhaps become timelier.


04:00 pm September 12, 2019

Not to say it hasn't been considered at each Sprint end, it just hasn't been warranted given the stability of this particular team. If something seems out of process or is something new for the team, or a situation didn't quite fit with current DoD during the Sprint, it's addressed at that time (if not earlier) and showcased during Retro. 

What I'm really wondering about is about the non-reactive reviews. Has anybody taken separate time for the team to take a deeper dive into their current process to find areas where accommodations were once made (even from a system/dept level), and assess or build strategies to further bring them closer to the ideal? 

05:31 pm September 12, 2019

I am going to start this out with a statement. I am not bragging in my response. I reread it and I felt it could be interpreted that way. I attribute it to the fact that I have been fortunate to work with some great people that came to value teamwork and the values of using agile practices.

My teams have never found any value in extra reviews of any kind. A couple of them have suggested them only to quickly ask that they be discontinued when undertaken. The teams have been very open and honest about what needs to be discussed. They have all been very willing to discuss anything at anytime.  The DoD has been under constant review and refinement. Experiments are identified and discussed immediately following to determine effectiveness, any adaptions needed or whether to abandon and start over.  Product changes are scrutinized at every opportunity.  All of this occurs based on the time boxes of Sprints in the Scrum Events at a minimum.

The core of agile practices is the constant inspect and adapt loop. If you wait for a special occasion to inspect and adapt then the practices loses their value. Since the Sprint Retrospective is specifically identified for the purpose you are discussing, why is there a need to add another? 

But I didn't do this on my own.  These were team decisions.  We didn't start like this, we inspected and adapted to this. You didn't really state that there is a need for it, just that you feel it would be a nice thing.  I applaud your ambition and dedication to finding ways that could help your teams improve but remember that in the long term you are a Scrum Master and your job is to help the Scrum Team improve in Scrum practices and adoption.  So if you feel that adding an additional quarterly review is warranted, ask your team how they feel about it and what they would like to accomplish in that review.

05:22 pm September 13, 2019

Thank you Daniel for the insight. I totally agree that these are team decisions. I would never bring this onto them without first asking if they think it would be valuable and is something they'd want to participate in.

You are correct, there currently isn't a need for this activity. I was just curious to see if teams have had any fun looking back on the quarter/year, and what's worked. Do any teams find checkpoints useful, if they choose what criteria to use? 

I guess now that I've thought about this more, the value I'm trying to achieve would be to further bring the team together, so perhaps instead I find an opportunity to showcase their successes, accomplishments, and recognitions perhaps at the start of the new year.

05:40 pm September 14, 2019

Why wait until the start of the new year?  If you have a mechanism to showcase success, do it anytime there is something done that is considered a success.  Focus the recognition on what is delivered not something like "This team has completed all the stories in their Sprints for the last 4 months".  Stretching here for a suggestion but how about something like "Team A delivered 8 iterations of a single product feature that ultimately lead to 40% of our customer base renewing their contracts". Show how the work they did lead to customer satisfaction and how that satisfaction helped the company to see value. Or another one is "After 3 iterations on an experimental product enhancement, the team determined from customer feedback that the enhancement was not going to be used so the experiment was canceled."  They saved money in a relative short amount of time and shows return on investment. 

Showcase any kind of "win" as frequently and often as possible as a means of providing transparency into what the team is doing.  Include the Product Owner and Development Team in the delivery of these showcases even let them to make the presentations.  Or if you have an internal stakeholder, include them also. It might be good for a Sales member to show how the Scrum Team was able to take a suggestion that turned into a profit or avoided a outlay of resources that would have been a waste.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.