I was sitting with my team lead the other day and we were discussing how to work with our multiple lines of business effectively. (I repeatedly am trying to explain that we just need 1 product owner to speak for all of them.)  

   Currently we're getting two product backlogs for 1 single product. His thinking is that we just run two different sprints with two different sets of functionality at the same time. Simply branch the code base.

My thinking is, "When are you going to do the integration in that?" because you certainly aren't going to be able to do it continously. He says well we'll have 2 builds, 2 continuous integrations going, and then when we go to put in sprint X with the trunk of production code we'll just merge all of that.

UH, that IS integration. How can it be continous if you're doing it at the end?

I was being sortof stubborn at this point because i was becoming irritated. How can someone not clearly see: One product, One Product backlog, One product owner, One Sprint at a time, One Team on that Sprint, One finished set of Functionality at the end "Potentially" ready to ship.

Let's take a look at the scrum framework diagram:

If you look at this diagram you see the blue boxes on the left. Those represent everything you're going to do in the project (that you currently know about). The white box on the far right, that's the product, finished, potentially ready to ship. Now, if you have to integrate (merge two different lines of code) you have to do that somewhere in between those 2 things, and you have to do it often (as prescribed by the makers of SVN, VSS, etc you should always merge and resolve conflicts as often as possible). Anyhow, if you're merging and resolving, and fighting all of these integration issues during your sprint that leaves little time for actual product development. Keep in mind you have to do this in EACH team not just one team. Unless you want a whole team dedicated to integrating everyone elses code... (oh god don't even think about, james).

Anyhow, as with EVERYTHING in scrum... try it, if it isn't working for you, it'll show up as an impediment. (if you have the right team and the framework is in place)!

As Ken Schwaber is reknowned for saying..."This(scrum) is hard"