I'm starting at this new company as a scrum master, and they want to dive into Scrum, which is nice and all, but they only have enough people (4) for one team.

The road map includes delivering a new product and maintaining the old one, so what should we do?

  • 2 products backlogs for 1 team? How should we do planning in this case?
  • 1 product backlog for 2 products? How will sprint review work in this case?
  • The company want dive into Scrum and cripple the methodology by they very first decision ... What does maintaining mean? Is the old product under development or is it just bug fixing and issue solving? Commented Oct 4, 2011 at 16:00
  • I know this is not Scrum by the book . But they have business obligations with the old product, so yeah it is mainly about product support, but if the ROI justify it, that can imply new features as well
    – xsace
    Commented Oct 4, 2011 at 16:18

5 Answers 5


I have previously been the Scrum Master for a team that was developing two products. The covered the same market space so it was understandable we would work on both of them.

We created roadmaps and developed stories independently and then combined them into a single backlog. That way we always knew which product took priority and could select items to work on appropriately. It was much more work for the Scrum Master and Product Owner, but made it easier on the rest of the team since they just viewed each story as a bit of work and didn't give much thought as to which product was more important.

The biggest challenge for the Product Owner was nailing down the priority between stories. One product had a larger installed customer base, but was in sunset because of technical limitations and the other had a long list of "must have" features. It was a balancing act to keep getting out new releases of the old to hang on to existing customer while providing new features in the new to attract new customers and (more importantly) get existing customers to migrate. In the end he had worked it out so the backlog was a pattern of 4 product A stories followed by 1 product B story. We had played with it a lot to that point and I know that since I've left they are still making adjustments based on the business needs.

His other big challenge was determining what frequency he wanted to release updates. Although both products were kept shippable at the end of iterations, it became as much a strategic decision of how releases would appear to the customer. In the end he settled on quarterly releases of the new and old, with the old coming out a week or two later. I can't say if that was the best decision or not.

In my role as Scrum Master, running interference for the team from outside forces was more complicated as people outside the team were frequently a positive influence on one product, but a negative on the other. For example, people we needed to consult with regarding the technology in the old product would sometimes try and make demands on changes to the new product in the middle of an iteration. So I needed them to sit with the developers, but keep focused on why we had them there.

There was also a lot of work in getting the team to see value in working on either project. While there is always better and worse assignments within a project, getting someone to pick up a dull task in a dying project for an iteration means you really need to sell the value of the work. Sometimes you had to highlight the dollars involved in the change.

Another issue the popped up every few months was a suggestion from upper management that we split the team into "vision" and "maintenance" teams. This was a group where people had been members for 3-10 years and they were suggesting splitting it just to make the resource allocation look better on paper. In reality, it would have hurt to take anyone off the maintenance permanently and by the same token not making someone part of the vision would have left them jaded or worse. I was constantly selling the value of the team as a whole was greater than the sum of its parts.

Estimating stories was difficult whenever we were picking up an area that hadn't been touched in a long time. It became difficult for the team to remember easily what other work had been done there and how they had sized it previously. This just meant that before estimation meetings I had to spend a few hours digging around through our old iterations to find similar stories so I could remind them of what else we had done in that area. How it had been sized and how the story had worked out in reality.

Another mechanical issue with the Scrum was running daily stand-ups in a way that kept it clear which product we were talking about. We adopted the approach of talking down through the stories rather than around the room to keep it clear. This was especially important when both products were updating the same technology in the same iteration.


With the same people working on both projects your choices are limited:

  • Lump all the stories into one pot and work on them in each sprint. The big drawback with this is that no one will want to work on the stories for the old project.
  • Split your time so you work 3 days a week on the new project and 2 days on the old (for example). This will require you to have two sets of planning meetings etc. The daily scrum meetings for each day will not be duplicated as they only need to happen on the days you are working on that project.

Two product backlogs for one team.

Otherwise, should you ever grow to have two scrum teams, the cost of "sorting" out of the product backlogs will effectively prevent you from dividing the work.

  • 1
    Most decent product backlog tools have an "area" field. You just use the product as a prefix and it makes dividing a trivial manual task. Commented Oct 5, 2011 at 15:12

The first thing to keep in mind is that Scrum calls for a team of around 10 or fewer people. With a team of 4 people, you are at the lower threshold for seeing the benefits of the Scrum artifacts and events, but putting the framework into place would likely help if the team grows.

Things like the product backlog, sprint backlog, and various measurements and metrics (such as velocity and burndown) should be managed on a per-project basis. You would carry out all of the activities normally. You also need to track how much time each individual will be spending on each project so you know how many story points to pull down for each project. Rather than basing velocity on just story points per iteration, also consider the time spent on each project.


According to comment I would not drive support of existing product by Scrum at all. Scrum is good for development where you can define backlog but maintenance usually cannot define it. It looks like the most effort must be put into your new project so lets handle with Scrum and reduce capacity of team by fixed time allocated to handle issues in the old product. If there will be no defects to fix the time will be used for a new product and team will probably be able to deliver little bit more than committed. If new feature for the old product will be planned you can count with it in the planning of the next sprint for the new product and reduce team capacity even more to get people enough time to implement a new feature for the old product.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.