Skip to main content

Retrospective for a team with multiple projects

Last post 01:49 pm September 12, 2022 by Boyan Iliev
8 replies
03:06 pm September 5, 2022

Hi all,


We are experimenting with few teams on how to best approach retrospectives. Our main issue is that a single team might end up working on few different projects during a single sprint. This makes retrospectives hard to organize and even harder to execute as different team members have knowledge only over part of the value delivered.

The team experimented with a "Climbing the Mountains" template. Collecting achievements/challenges per project and trying to come up with improvements that will be global for the team. This got us some results, but we would like to explore other options.

Would you mind sharing experience/expertise on this topic? Maybe go with project-based retrospectives instead of the standard sprint based ones? Or maybe avoid working on multiple projects within one team within one sprint to start with?


Thank you very much in advance!


11:31 am September 6, 2022

Our main issue is that a single team might end up working on few different projects during a single sprint.

Well then, I suggest that's precisely the issue the team ought to challenge in their Sprint Retrospective. It isn't a matter of finding some sort of template to use, which would only cover up the real problem:

  • Why are they working on multiple projects despite the resulting difficulties?
  • Are they pulling all this work by choice, or is it being pushed onto them?

05:56 pm September 6, 2022

Thank you Ian, for the reply!


Multiple projects was the easy example. An alternative would be a huge project, where different team members have little overlap in their tasks. Let's imagine a company-wide system change and the team needs to migrate different tools to the new system. Get 2-3 team members focusing on different tools and you have the same result.


Not sure how the way work is pulled/pushed matters. If it really does, I'm open for suggestions, the goal is to have working retrospectives, not arguing the current approach is the best :) Currently tasks are prioritized by business representatives and the team is pulling the highest priority tasks based on capacity each sprint. 


06:43 pm September 6, 2022

If pulled, the team can apply focus, with Done finished increments of work being delivered early and often. Through this system empirical process control is thereby established.

The whole point of Scrum is to provide such empiricism under conditions of high uncertainty. The most important project is therefore the Sprint itself.

Is there a need to establish empirical process control in the "huge project" you describe? Is it complex, meaning is more unknown about it than is known?

From what you say, it sounds like there are well-defined pieces of work proritized by a business authority. If that's the case  why even use Scrum? What significant risk or uncertainty is there to be mitigated by a team each Sprint? Do they have meaningful Sprint Goals to collaborate around and aim for? That could be the more important issue to address in a Sprint Retrospective.


09:18 pm September 6, 2022

Are you sure you are following the Scrum Guide or are you just using some of the terminology that is used?  For example, are your Sprints planned with a Sprint Goal in mind and focus on delivering incremental product value to the stakeholders?  Is your Product Backlog actually a list of all the things needed to be done to the Product in order to improve it? Is your Product Owner the individual respected by the organization to make decisions on what is right for the Product? 

Most of the suggestions you would get here are going to be Scrum leaning.  In this case, I don't think you are following the Scrum Guide and the sprint you mention is more of a fixed duration at the end of which you give a status report.  I may be wrong and if so, please accept my apology.  But regardless, what I'm about to suggest still applies.  Look at the processes you have, find ways to help the team understand the problems and opportunities associated to those processes.  A retrospective is for looking back.  What worked, what didn't? What did we learn from what we just did?  How can we apply those learnings?  Often using a "technique" can make it harder to have a successful retrospection event.  Facilitate discussions by asking leading questions.  Ask the team what they feel not just what you observe. The people doing the work should be the ones that drive the discussions so let them.  If they do not feel that there are problems, then who are you to say that there are.  But remind them that if no one speaks up, nothing can ever improve. 

06:27 am September 7, 2022

These are some great replies.


We are definitely NOT using the Scrum Guide, but similarities are a lot - making me seek help here. Ian is probably right that one of our problems is that the sprint goal is either too high-level for the a team to associate with, or too specific. Making it hard for everyone to collaborate to the same goal.

At the same time, we are mitigating the risk of poor/incomplete system migration by delivering each tool in increments. This allows the business to evaluate both the system migration quality and tools capabilities in the new environment. Yes the backlog is a list of things to be delivered, but after every increment this list gets updated based on feedback.

Tackling the problems and opportunities associated to those processes might be a good starting point. I can imagine this can open the discussion on how to pull and reflect on our lessons learned, having a productive retrospective (instead of me trying to force a technique).


Daniel, you touched another pain-point that I have, but this requires a separate discussion. How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option. Using approach A and claiming its the best, just because you are not aware that there are options B, C, something I've been struggling for some time.


02:07 pm September 7, 2022

How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option.

I often coach my teams that everything we do is an experiment. Do we know for sure that the code we are going to write will be what the stakeholder really wants?  Not really, but we are willing to experiment with it and get their feedback. 

Same holds true with the way people work.  Sometimes you don't know that something can be done better until you take a critical look and agree to experiment with options.  Sometimes the experiment produces bad results but as long as you learn from the results, the experiment is a success.  Challenge them to experiment. 

03:03 pm September 7, 2022

How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option. 

What data or evidence is the team using to support their belief that they are working in the best possible way?   Are they measuring things like lead time, cycle time, customer satisfaction, meeting sprint commitment and Sprint Goal, defects/issues identified within and post-sprint?

If not, then perhaps that is where the team needs to begin; otherwise, they may just be working from opinion only, and a possibly misinformed one at that.

01:49 pm September 12, 2022

Thank you again to everyone who replied. There are several good ideas I need to experiment with, before requesting additional assistance, or claiming success :)

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.