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.