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?
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:
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.
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.
