[ACCEPTED]-How does Scrum work when you have multiple projects?-scrum

Scrum really doesn't dictate that you have 29 to be working on the one self-contained 28 product. It simply states that there is 27 a bunch of stuff that needs to be done (the 26 product backlog), there is a certain amount 25 of development time available in the next 24 iteration (worked out from the project velocity) and 23 there are items selected by the client/business 22 as having most priority from this pool of 21 issues/tasks that will be done in the next 20 iteration (the sprint backlog).

There is 19 no reason that the product backlog and sprint 18 backlog have to be from the one project 17 - even in a single project there will be 16 discrete units of work that are like separate 15 projects - the UI, the business layer, the 14 database schema, etc. Enterprise software 13 development in particular is like this, where 12 you have a number of code bases that all 11 have to be progressing. The Scrum process 10 - meetings, questions, burn down chart, etc 9 - all work whether it is one project or 8 multiple.

Having said that, in practice it 7 is often good for each iteration to have 6 a major theme - "do the reporting module" or 5 "interface with XYZ system's API" - so that 4 a lot of the issues come from one project 3 or area and at the end of the iteration 2 you can point to a large body of work and 1 place a tick against it.

I think the answer depends on "who will be prioritizing the backlog items" (i.e. decide 19 what needs to be done first). If this is 18 a single person, then this person is the 17 Product Owner for your projects, and you 16 can have a single backlog will all items 15 for all projects - or a backlog per project 14 - and you select the backlog items from 13 all projects when you plan a Sprint. In 12 this case, Scrum "works" fine.

If every 11 project has its responsible, then you're 10 likely to encounter some troubles where 9 each responsible will - more or less consciously 8 - try to favor its project(s). IMHO, you'll 7 need to have one Product Owner only with 6 the authority to settle the priorities by 5 arbitration.

One rule that shall be followed 4 in such a context is to never change the Sprint content during the Sprint. If necessary, you 3 can shorten the iteration to two or three 2 weeks to lower the risk of having to add 1 an urgent item in the current Sprint.

I have to disagree. I think it is key to 76 the process to have a team focused on a 75 single project during a sprint. If you 74 have some specialists that can't contribute 73 to the entire development process (content 72 authors, graphics people, business process 71 analysts, etc.) I would shuffle them off 70 the team when they can no longer contribute. Or 69 better yet, get them trained up on some 68 different tasks so they can contribute to 67 things like testing.

Another thing to keep 66 in mind is that running projects in parallel 65 kills your schedule. Consider this: for 64 simplicities sake, lets say we have 5 projects 63 using the same team and starting on the 62 same date. Each project needs 3 one months 61 of effort, In the best case scenario running 60 parallel, you will finish them all at once 59 and it will take 15 months. Your velocity 58 will get creamed because you can only fit 57 1/5 of a month of effort in a single sprint. You'll 56 also be doing 5 demo meetings all at the 55 same time. So best case scenario, you deliver 54 your 5 projects in 15 months and your competition 53 will be claiming they could do the same 52 work in 3. Your teams estimating maturity 51 will suffer because they will only be able 50 to consider 20% of their available labor. You 49 may find that you actually are unable to 48 perform some tasks in a single sprint. If 47 you have to change the number of projects 46 being worked from 5, your team will have 45 to adjust their estimating habits which 44 will damage the teams efficiency. Additionally, your 43 team will find it difficult to self-organize 42 when a simple task reassignment may require 41 spinning up a new dev environment before 40 work can begin.

If you were to run the same 39 5 projects serially, you'd deliver the 5th 38 project in the same 15 months, but you would 37 have educated your client that your team 36 is in such demand that you have a 12 month 35 backlog and that you can use that time to 34 refine your project goals. Or if you have 33 a constant backlog, you know it's time to 32 start hiring another team. Your best project, however, is 31 finished in 3 months with a client that 30 has seen rapid improvements during the active 29 period. You're able to finish that project 28 a year earlier and can put it on your resume. Your 27 sprint velocity will stabilize over that 26 period of time and you may find that hits 25 its stride after a project or two and are 24 able to accomplish more in a given sprint.

I 23 think running projects serially is one of 22 the biggest hurdles an organization attempting 21 to adopt scrum faces. It's a major cultural 20 change associated with deconstructing the 19 project manager role, but the benefits to 18 the scrum process are huge.

Keep in mind 17 that EVERYBODY does not need to be a full 16 team member. They can be engaging your 15 client in the waiting room, preparing for 14 the development process. I keep my business 13 analysts, network architects and graphics 12 design people as domain experts and only 11 attach them to a team as needed. Let them 10 run with sprint 0. You'd be surprised how 9 engaging working on look-and-feel and workflow 8 is. It's also good to prepare your client 7 with the understanding that when development 6 begins in earnest, their level of participation 5 may actually go up and that it is important 4 for them to be available. Let them know 3 the schedule so they have plenty of time 2 to deal with things like vacations and holidays 1 well in advance.

I have been in this precise situation.

If 25 you have one product owner across the projects 24 then Phillipe is absolutely correct; One 23 sprint with one team should work just fine.

If 22 you have more than one product owner, then 21 ideally the business side needs to choose 20 a single 'prioritizer' who is given the 19 responsibility for scheduling the work. This is definitely the best solution.

If 18 (as is probably the case) the business don't 17 want to change how they want to prioritise 16 things (that would be far too convenient) then 15 you can split the team., and run two concurrent 14 sprints. However with a team of six, I wouldn't 13 split it into a more than 3 teams (I wouldn't 12 want to split it at all, but I think 2-3 11 teams would be workable). Splitting any 10 further as Kenny suggests, and having teams 9 of a single person seems to me somewhat 8 pointless, as then you no longer have a 7 team, just individual programmers.

If you 6 are splitting the team, I haven't found 5 much value in amalgamating the stand-ups, unless 4 you have separate sprints working on very 3 much of the same codebase, but then that 2 may be an argument to amalgamate those teams 1 for the purpose of the sprint.

There is another opinion I have been reading 27 about lately, namely that in an Agile environment 26 the concept of Project might be counterproductive 25 and could be eliminated. According to this 24 line of thinking, the organization should 23 be focusing on Releases instead. This is because 22 Projects are artificial boxes of work that produce 21 no value until they are finished. They are 20 contrary to Agile's goal of frequently delivering 19 shippable value. A Release is more in line with 18 Agile because it is oriented towards delivering 17 value and because its scope can be reduced 16 or expanded based on what teams can deliver 15 before the next Release.

There is a potential middle 14 ground, in which what was formerly called 13 a Project in your company is now repackaged as 12 the common Agile Theme or Feature. The benefit of this 11 approach is that the Theme or Feature can now be implemented 10 in pieces of value, as the product owner 9 sees fit.

There is still the question of 8 one team working on multiple Products, and it is 7 a question because of legitimate concerns 6 about domain knowledge and possible technical 5 skills. But Products built with Agile, even multiple 4 Products built by a single team, are constantly 3 accumulating Release-able value. In contrast, Projects are 2 worth nothing until they finish (and many 1 do not).

Something to think about...

I think anopres was right: the best way 39 is to avoid multiple projects at the same 38 time with scrum. Do everything to convience 37 that running too much in parallel is not 36 efficient.

Let us assume 5 projects each 35 about 3 months for team with 5 people.

Approach 34 1: each person works on single project in 33 team

• 1/5 speed of delivery per project gives 15 months of delivery for all projects
• Every single person is expert but only in own project
• No team spirit

Approach 2: 1 sprint per project, switching 32 projects

• Every 6th sprint work on project
• Too long time between project work - not regular incremental value for project (for product backlog yes), easy to forget, effort needed to restore context,
• First project delivered after about 12-13 months (assuming 2 weeks sprint)

Approach 3: 5 projects in single 31 sprint

• Requires too much detailed split of tasks just to fit into sprint
• Very little incremental build per project
• Delivery of first project after about 12-15 months

Approach 4: recommended - Serialized 30 work

• Team works on single project after project
• First project started and delivered after 3 months
• Second project started after 3rd month,delivered after 6th month
• ...
• 5th project started after 12th month, delivered after 15th month
• Team highly focused on project, intensive research and collaboration with customer
• Whole team has general good knowledge about all projects
• No waste time on context switching
• Require good team cooperation (conflicts can slow down delivery).

As you see, solution 4 is generally 29 better because projects are deliveried much 28 faster, team works together and efficient. Other 27 approaches includes waste time from context 26 switching, no full team collaboration, very 25 long total delivery time of all projects 24 etc.

And what about backlog grooming? If 23 team works on single project at once that 22 is simple - everybody will join. If there 21 are multiple projects we may need to delegate 20 single people to separate grooming sessions 19 (not full team is involved).

It is important 18 to convience customers that starting 2nd 17 project after 3 months will still result 16 in faster delivery (after 6th month) rather 15 than if we start it immediatelly with all 14 others. It is an illusion that managers 13 see - we start 5 projects at once, we work 12 hard and deliver little by little. In the 11 end this is not efficient however.

That is 10 why I do not belive that scrum is efficient 9 for multiple projects in parallel, it is 8 very tricky to match it into framework and 7 work according to scrum rules. Sometimes 6 it may be good having 2 projects to keep 5 all people occupied, but the more projects 4 we add the less efficient scrum will be. Maybe 3 kanban is an alternative just to see the 2 progress and team work (not so strong like 1 in Scrum team)?

Regards, Adam

As @Chris said, a normal project has sub 32 projects inside. You only have one backlog 31 though.

Think in a backlog with all your 30 projects. First problem: are you assigning 29 priorities to tasks or projects? I do prefer 28 a backlog per project. At least to have 27 clear the priorities that the product owner 26 has.

Having different product owners, and 25 due to the fact that those product owners 24 are not going to agree on how much time 23 they should give to each project. "Someone" will 22 have to absorve the decision on how to manage 21 interproject priorities. Note: developers 20 shouldn't do it.

Here it comes our project"S" manager 19 that will balance the resources product 18 owners need and the time members of the 17 team can give. Product owner A paid for 16 one month of work, but product owner B is 15 always updating his project (and paying 14 you well too). There some how you'll balance 13 your team for A to have his one month (developer 12 time), and do not stop B from filling your 11 pockets.

In the case of internal software 10 (one company, a thousand projects). The 9 different product owners should agree on 8 the time given to them. They do not live 7 isolated, but in the same boat as you (project"S" manager). They 6 will make your life easier being able to 5 postpone some tasks, but at the same time 4 you should never forget their needs.

Well, I'm 3 still trying to figure out the best way 2 to do this. But this is what we're pushing 1 right now. I hope it helps.

Team members can split their time between 8 scrum projects, but it’s much more productive 7 to have team members fully dedicated. Team 6 members can also change from one sprint 5 to the next, but that also reduces the productivity 4 of the team. Projects with larger teams 3 are organized as multiple scrums, each focused 2 on a different aspect of the product development, with 1 close coordination of their efforts.

I would suggest running one Sprint for each 2 Project and have 1 daily standup meeting 1 to handle all active Springs/projects.

I'd like to contribute. This is the way 14 I do it:

• There is one product owner and one product backlog per team. The product owner doesn't have to be one single person, but this product owner "entity" is in charge of the product backlog.
• The product backlog has the user stories of every project (all the projects here). Each user story has an effort/story points (team responsibility) and a business value (product owner responsibility).
• We have a "product backlog grooming" meeting every sprint. Before this meeting the product owner has updated the business values of the stories (if they need some change for whatever business reason- that we don't and shouldn't care-) and include some new stories. In this meeting the new stories are explained and the efforts are updated as well. This meeting lasts about one hour (except the first time, about 4 hours).
• When we are going to plan a new sprint we open the product backlog, order the stories by ROI (this is business value / effort) and plan stories until the time has gone.

And that's it. I can say this works 13 pretty fine. We use a couple of google spreadsheet 12 (the product backlog and the sprint backlog 11 ones, both with charts and stuff) for doing 10 this, and redmine (with a specific semantic) for 9 an online organisation every day: time, task 8 progress, etc

The problem with this approach 7 is that I have duplicate the tasks in the 6 sprint backlog spreadsheet and redmine. But 5 I don't find any online tool for doing this 4 completely online. I miss a product backlog 3 in redmine (no other semantic works for 2 me), a single board in jira, more stories 1 in taiga, etcetera