We manage about a half dozen projects using a single backlog. I say “about” because it depends upon how you want differentiate projects.

Loosely, we have five or six product owners, some of whom own more than one product. We have a reasonably small team with seven devs and a team lead who also codes when he has time. And we have a few evangelizers who work with our process folk to move ideas into the pipeline. Of course, several folk wear several hats which muddies things but I’ll ignore that for my answer. Interestingly, we do not have a formal scrum master.

We didn’t have to merge backlogs together, but it sounds like a straightforward task on your side.

Keeping things organized can be a real pain, so here are some points you’ll want to consider.

• Governance is key. Everyone who has an administrative finger in the pie must communicate with others before making significant changes. And / or those making changes must be comfortable with their authority to do so (and be prepared to take the heat for a bad change). Our change makers have strong executive backing and lines are pretty clearly drawn around areas. But when there’s a doubt, we ask before we change.

• There can be more overhead involved with backlog grooming, prioritization, and kick-offs. Prioritization as a ritual suffers the most because it’s hard to get all of the owners together on a regular basis. We use a number of go-betweens to negotiate priority and / or deliver the bad news of not making the priority cut.

• A lot of our work is driven by external commitment. That takes away some of the autonomy out of our decisions, but that’s the reality of business. Your devs need to be aware of that change though. Feathers can get ruffled if there is a perceived loss of control. We try not to over-commit though, and we’ve had to say “no” to some product owners who were sitting on the cusp of making it into the sprint.

• We generally use two methods to tag what product a product backlog item belongs to. We use both simply because it makes grooming and other tasks easier.

  1. We’ll preface the PBI title with the product name or shorthand version.
  2. We have a separate field that indicates overall product, and that has to be filled out as well.

• We have to put conscious effort into cross-training and making sure that everyone gets a hand in the various areas. We have a very large code base with respect to our development team. Some of the code we do is very specialized as well. Our team lead is awesome in that regard and he’ll push our commitment level down a notch so we can afford the inefficiencies that come from cross-training. Having a strong team lead is critical in this regard.

• We do our best to maintain our sprint time frames. Complex projects with newer team members translates into not uncommon bleed over with commitments. Process around your branching will really help here. All of our work is done against a branch that is then merged back to a trunk release. We also have a build server that runs nightly in addition to ad-hoc triggers. Devs who break the build know and resolve the issue within 24 hours. Period. Failure to resolve within 24 hours means your commit is rolled back and the senior devs give them grief. And the senior devs are hardest on themselves when it comes to maintaining the build.

• Code walk-throughs and reviews become even more critical. It helps keep everyone up to date on what’s changing in the various areas.

• Likewise, the daily standup involves all the devs plus our UI people. We’re right at the edge of beneficial collaborative communication and inefficiency from too many people. But we keep the standup to less than 15 minutes and will quickly move on from side discussions. Usually we’re done in 5 to 10 minutes.

• I can’t speak to the effects on metrics like velocity or overall commitment and burndown rates. Those aspects just haven’t been important enough for us to follow closely. YMMV, so take that under consideration. This also presumes that each team has a reasonably similar definition of story point. If not, that’s going to mess up initial estimates after the merge. It will also generate some problems for historical comparisons since you’re not using the same unit of measure as you were before. Easy way out is to just declare it a “new team” for the metrics and just start gathering data after the merge.

• We have seen significant benefit from this approach. We’ve had some sprints where all hands are focused on one area and we can knock out a lot of change in a short period of time. You shouldn’t underestimate the value that comes from being able to quickly apply double the normal number of developers on a particular project. But you have to put in the cross-training ahead of time. It also means we never have devs with “nothing to do” because of test cycles or grooming or whatever. We always have a backlog to tackle.

• Dedicate time for R&D projects. Otherwise it’s too easy for them to slip through the cracks and you lose the opportunity to invest in those areas.

• Really work on ego-less coding and that while you may have experts in an area, you don’t have owners of a code area. Preventing the opportunity for bruised egos is important when different styles are introduced into an area. So long as the new code meets the team standards and is functional, it should be good. Just because it’s not how the expert would have done it doesn’t matter.

• Make sure the teams involved are using the same coding conventions and style. Nothing like inconsistency here to wreak havoc on your attempts at integration.

• Keep holding your retrospectives, and hold them as a group. It’s important to get everyone’s feedback on what’s working, what’s not working, and what needs to be tried differently. This helps drive a sense of camaraderie within the team and gives a sense of ownership around the development process.

The correct Scrum answer is “Ask the team(s)”. This is the principle of self-organisation where they should be able to restructure themselves to get the job done quickly. You see many people in the teams have more context knowledge than an outsider and they know what is best. This also includes the Product Owner.

I take it that you came here and asked the question as there is something that does not feel right and you have hidden concerns. So I am going to give you a few pointers to discuss with the team to come up with the right decision.

Product Owner

There is only one product owner for a backlog and this should be a business person or person representing business. It should not be IT management. A big backlog has many items and with multiple teams it could be too much for a single PO to deal with. You may want to keep backlogs separate for this reason.

If there are multiple PO’s, then you definitely need multiple backlogs as teams should be dedicated in a sprint to a single PO and backlog. The reason is a team does not need to manage conflicts between product owners priorities.

Product Development versus Maintenance

Maintenance teams work on many small enhancements, bugs over several different products and possibly with several product owners. These BAU teams need the support of IT management to help schedule the and manage the conflicts between multiple product owners.

Project teams should focus on one product at a time to minimize context switching and delivering one great product at a time. Context switching could result in delivery of many mediocre products with some degree of technical debt.

Context Switching

Working on multiple products or different features causes context switching which slows down teams productivity. The PO should factor this in when working out what is next and what team should be working on what piece of work. The amount of switching is not insignificant and not just a theoretical issue, it is real and I have witnessed team dropping up to 80% in productivity due to this.

A good PO will try group features and type of work to help teams do less context switching, thus improving their performance.

Risk

Sadly, management try put the risk of time, money, budget and business pressures on the team; and teams accept this by agreeing to this. As a development professional, you should simply state the facts and impacts of the decisions and make the business own their own risk.

Examples

• Agreeing to a ridiculous time. Rather say what effort its going to take to do the job properly and make business manage the time problem

• Estimations. Business expect teams to accurately estimate in a world of complexity and uncertainty. Teams should ask business what they are doing to mitigate if the estimates are exceeded due to unforeseen challenges, which are highly likely. Teams should not factor in fat, but instead business should.

• Technical Debt. Teams should estimate on doing high quality code that is fully tested and estimate on that, i.e. Stop writing defects due to pressures. If business want lower quality, then it is their risk to take and when things go wrong its their problem.

Professionalism

Be a professional by stating building the right things to the agreed quality. Estimate to your best ability based on facts at hand. When these facts change, communicate it and adjust the estimate. As a development team, build great products and do not take on business risk. Communicate and manage expectations.

Inspect and Adapt

Teams should always be seeking ways to improve and if they feel it is going to make things better, they should try it. Then inspect to see whether there are improvements. Finally they should adapt and improve on their new approach or scrap it if not working. The intent behind seeking to improve should always be there.

Bottom Line

Ultimately, the management of the backlog is the choice of the PO. How he/she wants to manage the queue of work is up to them. The only think is they MUST keep the pipeline of work to ALL teams healthy and in a good state. It is thus up to the PO to decide.

The contract

In sprint planning sessions, the team should expect a list of groomed product backlog items that are clear, unambiguous and ordered. With a short discussion with the PO the team should know exactly what the PO wants; the WHAT. The team then focus on how they are going to build.

If the PO comes to the planning meeting well prepared, who cares how the backlog is managed. If the PO comes unprepared to the sprint planning meeting, this should be addressed by the SM and made very visible as this is totally unacceptable and not a team problem to take on.

We just recently absorbed another team’s backlog. The team only had one member (not much of a team, I know), but there is actual work on their backlog. We’re not very familiar with their work, and they’re not very familiar with ours.

Even though your backlogs are merged, that doesn’t mean everyone has to work on everything right away. It’s unreasonable to expect that, so don’t worry too much about everyone being able to do everything in both backlogs right away.

Instead, start out having both teams working on exactly what they were working on before; the only difference is everything is in the same backlog.

Then, every iteration/sprint have some of the members from each team work on stories from the other backlog. By not having everyone working on unfamiliar items at the same time, you spread out the cost of learning each others’ systems. Over time your team will gradually absorb each others’ knowledge.

If you do all the learning up-front, there will be significant performance penalties. Someone in senior management will surely notice, and you’ll be forced to absorb another team’s backlog in hope that new team can compensate for the poor performance… 🙂 Jokes aside, however, this would be my recommendation.

I am assuming that the reason you (or management) wants to create a merged backlog for two teams is that you want to be able to pick only backlog items for one of the system and have both teams work on them.

When this is the case, expect a lot of friction from the team that is forced to work on the system they are not familiar with. Expect that the team will take every straw (i.e. tiny backlog item related to their “home” system) to keep on working on the system they were working on before. Who is to blame them? It is no fun to work on something that you are not good at. And the fact that the other team is good as something you are not good at makes it worse – because it makes you look even more dumb.

So, the only way to make this succeed is to break up the two teams and form them into two mixed teams. Only then, there is a chance that you’ll get all developers up to speed quickly on the (currently) “important” system.

That is not very good to make it that way.
My prev company, went into single product single team mode because in big company, we had different people working on different stuff.

Switching between projects also costs effort, and if there is new person to start developing overhead is really big. One have to get access rights to developed system, different repository etc.

I prefer specialization, people know what they are doing, have all needed information, know pitfalls of project, and people do not have the feeling that you have to drop them from project to project to get them to work, to suck every penny out of them.

Even if they are idling in their project, they are a lot more productive in what they are familiar with, than jumping from project to project.