Skip to main content

Single Scrum Team with Multiple Projects / Products

Last post 04:26 am December 12, 2014 by Filip Czapeczka
3 replies
05:00 pm December 9, 2014

We currently have one scrum team working on a single product and it works great.

The rest of the developers are split across smaller teams of 1 or 2 developers, each working on individual products. Each of these has it's own backlog and product owner. Then we have one individual that handles fixes and improvements to multiple existing products, which is basically managed by Kanban.

This all works ok, but I'm not convinced it is the best approach. E.g. The lone developers working on a product have limited support, code reviews, testing resource and nothing gets done when they are on holiday or sick.

My question is whether we should consider merging the smaller teams into a single or a couple of scrum teams that work on multiple products. I have read around the affects of task switching and realise this may be an issue.

Does anyone have any practical experience of this? The benefits I can see might be less meetings, more knowledge sharing, a better chance of code reviews getting done, support from others to get pbi's done by the end of the sprint, more consistent estimation and planning, continuation of projects when developers take holiday, etc.

We would need a good product owner able to take decisions on the split of projects. We are planning to take on more developers, but in the interim I'm wondering if this is a valid solution until we can get closer to 1 team per product / project? Also, should we bring our Kanban developer into the team too?

Thanks

Jared


10:32 pm December 9, 2014

> Then we have one individual that handles
> fixes and improvements to multiple existing products

This implies that the various products involve similar skills and/or technology stacks. If that is the case, it may indeed be viable to combine developers into 1 or 2 teams.

You don't *necessarily* have to find a single PO who can order and prioritize a common Product Backlog. As long as a team does not work on more than 4 products it can run weekly sprints alternating between backlogs. Each product is thereby serviced at least once per month and the task-switching boundary is subjected to clear control.

The person currently allocated to support may be included as a full team member. Given that there will be ongoing ad-hoc support requirements that may affect *any* product, and not just the one being currently worked on, the team can reduce its Sprint backlog capacity to accommodate this work. It is up to the team to self-organize and decide who actions any unplanned support requests...and this needn't necessarily be the currently assigned "support guy".

If an approach like this is acceptable, I suggest running it for a while as it may prove to be more efficient. A more informed decision about how to expand the team with new hires can then be made.


12:09 pm December 10, 2014

Thanks for the feedback. Having heard from you and looked up other sources, it seems the solution to our problem is to reduce the number of projects we work on simultaneously (e.g. to max of 2 per team). That will increase throughput for those projects and not introduce a major context switching issue.

Thanks

Jared


04:26 am December 12, 2014

Jared,

We had a very simiar situation to yours. In our case we found out, that for real, we have one product for now, so we merged every little team to the biggest one.
Please think, if you don't really have 1 product. If not, still there can be one developers team managing 3 products. But it has to come with one Product Owner who sets the priororities in a backlog combined from 3 other product backlogs.

The benefits are obvious

Filip


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.