Would you consider is it good approach to group different user stories from different projects into one sprint? Have you ever detected pros/cons?

Let's say

1. Project A (Start 2017-01-05 Estimate End 2017-05-30)
2. Project B (Start 2017-03-01 Estimate End 2017-07-30)

Sprint of 2 weeks when dates of projects overlap and you have the same number of people for all your projects, but you have multiple Scrum masters (one per project) and one team

**Sprint 8 (Prj A & Prj B)**

Last update Jul 25, 2019

Forgot to mention that company performs multiple incremental iterations to improve a software/suite. Each project represents clients' requirements from different business units. That is why there is only one group of devs for the software, but many project managers with different goals, with different stories that can overlap in time and maybe in objectives.

  • How many Developers (people who produce the increment of product each Sprint) do you have in the one team?
    – onedaywhen
    Commented Jun 19, 2018 at 16:11
  • @onedaywhen Around 8 devs. The software is just one with incremental features per project/client. Commented Jul 26, 2019 at 1:48

4 Answers 4


Having worked like this, with a single team working on multiple projects at the same time, on multiple occasions, I have identified numerous reasons to not do this and exactly none at all to work like this.

Ultimately, it will strain or fracture the team, drain motivation, reduce productivity and leave you with two failed projects.

Various companies tried doing this in various different ways, but not of them really worked out in the end.

We tried tackling problems from two backlogs with the whole team. The main downsides there were constantly switching between context, which caused huge overhead, and the inevitable fights with the PO over which project's stories needed to be dropped when we wouldn't make the sprint. Doing one project first and the second after made the fights worse in intensity; doing a story from each in turn made them more common as the overhead reduced velocity.

We also tried assigning some people to work primarily on one project, some people on the other, and some shared, with the idea that both sides would help out if one or the other project would slip. This one fractured the whole team in weeks, with each side just working on a single project and not really caring about the other anymore, losing track of the domain expertise and progress needed for the other project and then just getting annoyed about having to join on meeting for a project they weren't a part of. The team basically ended up being split in two teams, one for each project, but that caused a lot of pain and lost productivity.

Then also we tried working on one project for a sprint, then the other project for a sprint, etc. This worked somewhat. It has less of the issues of the first approach because each project is in a clear timebox, but it will cost you a lot of flexibility when something important happens on Project A but you've just started a sprint for Project B, and then you end up with the same priority fight.

My best advice: don't do it. One person, one team, one project, one goal. Anything other than that is going to cost you tons of morale and productivity, for no gain. Obligatory reading.

Also, as a final note, ask yourself why you want to do this. There is literally no reason to ever consider this; you can just do both projects in series. Complete project A and then complete B once A is done; if you could successfully complete both in parallel then you will always be able to complete them faster in series. Any reasons for starting both at once, are likely rooted in already admitting to yourself that you're going to fail at both projects anyway, and are trying to mitigate the damages by having something to show at the deadline to convince people you need more time/money without them pulling out. Invest your time fixing that problem and leave your people to focus on one thing at a time, that's how they'll work best.

  • Everything you described you "argued over" would have been the PO's job to decide. There should have been no arguments, at least not from the team. I have worked in multi-product teams and as long as there is one PO with one set of priorities, there should be no arguments. It might not be the most pleasant PO job with constant arguments with the stakeholders, but that should not concern the team.
    – nvoigt
    Commented Jun 19, 2018 at 8:42
  • @nvoigt fair enough. I'll expand this with the story of how the PO quit because having to do two projects with complaining stakeholders was stressing him out, when I have some more time. It should be the POs job, but the PO is going to hate his job if he shields the development team, and the development team is going to hate their job when the PO gives up.
    – Erik
    Commented Jun 19, 2018 at 9:09
  • I have seen that too, I would just put the blame on not empowering the PO to actually do their job. The problem is not two (or more) projects, because even with a single project you might have stakeholders with different priorities. The problem is that the PO has no backing from upper management to tell their stakeholders to work constructively together or get the hell out. If the PO has to cave in to every demand a stakeholder makes... then they are not a PO as defined.
    – nvoigt
    Commented Jun 19, 2018 at 10:30

You can have multiple projects. You can have multiple teams. But:

  • One person can only be in exactly one team (1)
  • A Scrum master is per Team not per project.

With those constraints, your plan will not work either way. The best option might be to form one team, put both projects into the backlog and work on them. You can drag work items of multiple different projects into one sprint just as you said. But you will have one Scrum master and one product owner.

Alternatively, if you want two teams, forms two teams, two Scrum masters, two product owners and two backlogs.

(1) (my experience tells me that any way to cheat around this rule will fail badly, because there can be neither focus nor commitment, two of the five core values, if somebody is on multiple teams).

  • Thank you for your answer. We are very limited of people. The platform is standard but has different modules for different business units. Scrum team are the experts to get a consensus to develop the stories from 2 projects in one sprint. We are doing both projects for different customers. We have a product owner and 3 project managers that we are translating them wrongly into Scrum master. At this point we should arrive to the roles 3 PM (2 active for the prjs), 1 SM, 1 PO and 1 ST? The 2 PM will be very limited in their role just negotiating with the customers? Commented Jun 19, 2018 at 13:26
  • I am in no position to tell you how to make use of your people. But there are no Project Managers in Scrum. Scrum master has little to do with project management. The closest might be PO, but even that is not a direct equivalent. You could use the PM as proxies for the client if the client does not want to be agile as well. Or you could retrain them if they want to. Or you can tell them to look for a job of PM at a different company. But you cannot just have them continue PMing. That won't work. Agile is either or. You do it or you don't. A mix will fail worse than just staying C&C.
    – nvoigt
    Commented Jun 19, 2018 at 16:35
  • That's what I read last week in a book: PM need to embrace agile approeach, if not they shouldn't be in charge of the projects. As you said, PM could work as proxies with the customer who normally don't want to work iteratively. Some yes some don't. But let's assume that Scrum team deliver multiple quick deliverables and if the project manager hold them to show everything as a package to the customer, this will create a bottleneck and we could work again as waterfall breaking the agile philosophy. Commented Jun 19, 2018 at 17:28
  • 1
    @MaximusDecimus IMO you should turn your PMs into POs maybe with "double duty" as traditional PM interface for customer. SM is a very different role from what most PMs will be used to. For SM you should get someone who is really passionate and knowledgeable about Agile and Scrum. If you have a customer who wants to see everything in one version it falls to the PO to understand the customer well enough so he can steer the successive iterations. I would still try and get the customer to check out a few preliminary versions starting at about halftime.
    – Kempeth
    Commented Jun 20, 2018 at 14:33

That's a terrible idea

  • There is only one scrum master per team. The scrum master isn't tied to the project because he is not a project manager. Your setup suggests that your company does not understand or respect scrum or the people working under it.
  • There is no advantage of mixing projects like this. This is clearly just management pushing arbitrary deadlines with no regards to practicality. There is no reason why anyone would suggest this over doing project A properly then doing project B propery unless they are trying to trick the developers into committing to more work than is feasible.
  • Switching between jobs is ineffective. People need time to get up to speed when they start something new. This is even more the case when switching between completely different projects.
  • If you get around the previous point by splitting the team, then you're still no better off as you lose a lot of the team's synergies by having them work on different projects.
  • You're bound to run into conflicts as soon as you mix the projects. What is a "fair" split of sprint capacity? Which tasks take priority if you can't finish everything? Project A will push for more attention to get it done. Project B will push back. It will be nothing but drama.
  • You have no guarantee that you will be done with project A on the estimated date. What are you going to do then? Cut it off? If your managers were willing to do that you could just as well move that deadline up a month and avoid this mixing. Are you going to continue to run in parallel? For how long? Because that will delay project B and someone up the ladder is not going to be happy about that.

This is a textbook double bind scenario.

  • Thank you so much for all the listing the resource about double bind. Very useful!!! Mostly all the answers are aligned that we are doing wrong right now, but we are making a progress to change from traditional to agile. At some point people who worked in that way over the years will embrace finally agile. Commented Jun 19, 2018 at 17:32
  • Personally I care far less about "doing proper scrum" than some others. But when you consider going against the standard it's important to know why the standard is the way it is. Scrum's somewhat rigid structure (for an Agile method) is to force stakeholders to make those difficult, inconvenient but necessary choices about what takes priority, how much time you are willing to invest and when to cut your losses and move on. That's something that is important to any project - agile or not - but is often swept under the rug. Often with "clever" ideas like in your question.
    – Kempeth
    Commented Jun 20, 2018 at 14:45

Advantages of having stories from multiple projects in each sprint:

  • You will see progress in more than one project
  • The developers may enjoy the variety


  • Context switching is expensive and reduces the output of your team
  • You lose the clarity of having just one project to focus on, which may also reduce productivity
  • It is often more difficult to define the relative priorities for tasks from different projects

In my experience the most common reason for having multiple projects in each sprint is that the organisation is unable (or unwilling) to prioritise and they do not appreciate the productivity loss that comes from multi-tasking.

but you have multiple Scrum masters (one per project) and one team

Then you aren't doing Scrum and shouldn't really be calling them Scrum Masters. One of the reasons for the existence of Scrum is that it was recognised that consistency of team members really helps a team to work effectively. When a team works together they learn to adapt to each others strengths and weaknesses. If you are changing team members (especially a key role like the Scrum Master) then you are going to have reduced productivity.

  • 1
    I appreciate your so much your answer. We are encouraging to adopt fast agile approach since we worked in a traditional way many years and we want to restructure everything, but like a homecoming more than a huge revolution. We are starting to discover what we are doing wrong. Commented Jun 19, 2018 at 17:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.