Dealing with multiple projects in the same Scrum team

Question

I am senior developer working in a small Scrum team (capacity ~ 3 FTE) that must deal with multiple projects in various stages:

• project A - actively developed
• project B - about 10% of team capacity for development and maintenance, low predictability (some developments cannot wait the following sprint)
• project C - about 5% of team capacity, maintenance only
• project D - similar C, completely different tech-stack than the team knows, but manageable, maintenance only

Scrum methodology cannot be changed (the team must commit to some stories to be delivered to the end of a three-week sprint), but it is working pretty well because the team is able to estimate pretty well the "reserve" required for projects B, C and D.

The product owner has just changed and as opposed to how things used to be (the team provided a total sprint capacity) now wants detailed team capacity (per person).

I have suggested the following rough format for the sprint capacity:

• for each team member, get the capacity for the sprint (i.e. total - vacation - full day trainings)
• consider an explicit "incidents band" which is a reserve for whatever comes to tackle projects B, C and D (incidents and maintenance). This is because during the sprint planning, we do not know most of the items that the team will have to tackle during the sprint.
• actual capacity for project A stories (what the main client actually received at the end of the sprint) = team members actual capacity - "incidents" reserve - project A incidents

My team lead argues that the PO should not care about what the team does on projects B, C and D and we should only communicate the capacity for project A + reserve for incidents on project A. The main argument is that "the client" cares only about the bigger project A.

On the other side, I argued that the PO handles the entire team and she should be aware of all our activities, otherwise the team will have multiple points of contact from various internal clients, conflicting priorities (e.g. sometimes a bigger than reserve activity comes for a non-A project).

I am interested in how such a situation (a Scrum team mostly dealing with a product, but spending significant effort on maintaining other products) should be handled. As a developer I am mostly interested in increased delivered value, but I might miss other important aspects.

Answer 1

[...] working in a small SCRUM team (capacity ~ 3 FTE) that must deal with multiple projects in various stages

Scrum works best for one team working on one project. If you have things coming your way that can't be planned in advance, then you will need to put aside a capacity buffer for those things so that the stable part of your sprint still has a meaning when it comes to predictability and forecasting.

SCRUM methodology cannot be changed [...]

First, why? Second, it's not a methodology. If the way you work is imposed to you then that's a sign that you are not working in an Agile environment and whatever Scrum you do might just be in name only. Not enough information to elaborate but just be mindful of what "cannot be changed" means for a team that is supposed to "inspect and adapt".

The product owner has just changed and as opposed to how things used to be (the team provided a total sprint capacity) now wants detailed team capacity (per person).

This is a sign of micromanagement and traditional project management behavior. Why does she want person capacity? Is it for 100% resource utilization?

[...] the PO handles the entire team [...]

The PO doesn't handle the team, but the product. In this case I assume product A. Yes, she needs to know the full team context, which seems to come with some surprises from other projects. Yet she seems to try to focus on the team only while ignoring the larger context. The two can't be separated. What's the purpose of her request? To plan better? To squeeze more work from the team? To have everyone busy 100% percent of the time?

I am interested in how such a situation (a SCRUM team mostly dealing with a product, but spending significant effort on maintaining other products) should be handled.

Depends on the full context:

• You could have a buffer/reserve in your sprint for unexpected work coming from B, C and D.
• You could use a more "operational" way of working and switch to Kanban instead of Scrum;
• You could split the team in two. One does Scrum development on project A and the other does just maintenance on B, C, D so focus doesn't spread too thin and context switching is reduced.
• Other ways...

The main thing to consider is "what's the problem you want to fix?". From what you describe, the team seems to have found a way to settle into a working approach, but now you have a new PO who doesn't like something and is trying to make the team work in a different way. First, find out what exactly is the problem, then look for solutions.