You may land up in situations when a project is almost stable. For developers handling issues and enhancements for the project, the work available is not sufficient. So, when team is comfortable with the project and it’s already stabilized, team can start handling another project at the same time. It’s good for the people working in these projects from learning perspective. They are exposed to multiple technology stacks, problems and functionality. At the same time, it works well for an organization in general.
Scrum for One Team Handling Multiple Projects
When you talk about one team handling multiple projects, Scrum point of view becomes blur. There will be two product backlogs for two projects for example. But combined team cannot focus on two Spring backlogs at a time. It’s difficult to define the relative priority of the issues of two projects individually and work on them. So there is a need to have a common set of issues to be in the sprint for the whole team. This helps in assessing team’s velocity for picking up the tasks for next sprint. But it’s not possible to mix the whole product backlog into one, as there are stake holders who would be interested in their individual projects. It’s also hard to know the health of the particular project.
To solve this problem we need to use one ‘Sprint backlog’, which gets items from multiple ‘product backlogs’. So there will be two artifacts that can be released at the end of each sprint. The decision of which backlog items should be taken into sprint backlog should be done based on the situation/priority.
For this purpose team can use JIRA and wiki together as issue tracking system. JIRA can be used to maintain the product backlogs of two projects. For each sprint create sprint backlogs in each project space in JIRA followed by a combined view of both sprint backlogs which is nothing but the sprint backlog for the team. For this one can create a filter in JIRA which gives issues from a particular sprint from both projects in XML format. On wiki team can use ‘JIRA view’ to display the sprint backlog items.
If you talk about assigning priorities of issues, the role of product owner comes into picture. Dealing with two product owners at the same time by the combined team seems to be a difficult task. To resolve this issue, there can be one proxy product-owner from the team who works with both customers and with team to prioritize the issues for the product-backlog and sprint-backlog.
Focus on Knowledge Transfer
To begin with, ProjectA team takes the knowledge transfer (KT) of ProjectB project and they starts working on ProjectB. KT of ProjectA is conducted later and finally you’ll have one team working on two projects doing pair-programming. You may want to take a look on a blog on knowledge transfer in Agile maintenance for details.
P.S. Thanks to Haroon, Ganesh and Kris for their inputs on subject-matter
Erwin van der Koogh says
ShriKant,
Why do you say you can not have 1 product backlog for 2 projects and at the same time suggest 1 sprint backlog?
If you can not combine them together in 1 product backlog, what makes you think you can combine them in a sprint backlog? I can see why you would think it is less work, because if they are in 1 PB you need to get all stakeholders together to prioritize between the 2 projects. But that is a discussion you need to be having as soon as possible to see if it is feasible at all to have this team work with both sets of stakeholders.
If the stakeholders can’t agree on a prioritization on a product backlog level, there is no way it is going to work on a sprint backlog level.
And when you get to this level of agile, please try to let go of the notion that a team works on a project. A team just pulls work from a product backlog regardless if it is for *product* A or *product* B.
The only projects you will be left with are initiatives spanning multiple teams and they are done only by project managers working with POs to make sure the timing of delivery is right.