Menu
I'm fairly well read in the benefits and processes of Scrum. I get the ideas on the backlog, burndown charts, iterations, using user stories, and other various concepts of the Scrum "framework".
With that said... I work for a web development firm that manages multiple projects at one time, with six team members that make up the "production team".
How does Scrum work with having multiple projects? Do you still just schedule an iteration for a single project in a certain amount of time and the entire team works on it, and then you move on to the next project with a new iteration when that iteration is completed? Or is there an "agile" way in managing multiple projects with their own iterations with only one team at the same time?
894
If this is a single person, then this person is the Product Owner for your projects, and you can have a single backlog will all items for all projects - or a backlog per project - and you select the backlog items from all projects when you plan a Sprint. In this case, Scrum "works" fine.
If everything's going for you, then one scrum master can handle multiple teams (3 or more). The key things that would make this possible are: All teams working on one product (i.e. one backlog) Working to a common set of practices/norms (e.g. the same DoD)
A Scrum Team works from one, and only one, Product Backlog. Multiple projects can feed into the Product Backlog, but it is the job of the Product Owner to sequence all inputs into a single, prioritized Product Backlog for the Scrum Team.
One board can have multiple projects as well - this is controlled by the board filter. Sprints can be used in multiple projects as well.
Scrum really doesn't dictate that you have to be working on the one self-contained product. It simply states that there is a bunch of stuff that needs to be done (the product backlog), there is a certain amount of development time available in the next iteration (worked out from the project velocity) and there are items selected by the client/business as having most priority from this pool of issues/tasks that will be done in the next iteration (the sprint backlog).
There is no reason that the product backlog and sprint backlog have to be from the one project - even in a single project there will be discrete units of work that are like separate projects - the UI, the business layer, the database schema, etc. Enterprise software development in particular is like this, where you have a number of code bases that all have to be progressing. The Scrum process - meetings, questions, burn down chart, etc - all work whether it is one project or multiple.
Having said that, in practice it is often good for each iteration to have a major theme - "do the reporting module" or "interface with XYZ system's API" - so that a lot of the issues come from one project or area and at the end of the iteration you can point to a large body of work and place a tick against it.
77
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
