How to organize work for a team delivering 3 connected but distinct products and stay agile

Question

We are a team responsible for 3 products:

• 2 products are in active development of new functionality and are moving fast therefore work there could be classified as project
• 3^rd product is alive and kicking and here work involves BAU ¹ and maintenance

One of the products is new and with great promise to the business, so the work there will always be in full swing. It is also most attractive project to team members.

The second product is being developed, but work there is of slightly lower priority and therefore will ebb and flow.

The BAU work on the 3^rd product will be mostly quiet with short bursts of activity to fix reported issues and assist in deployment.

Thus far the work planning was very much ad hoc and we want to bring increased planning, predictability and some tracking with all the benefits but mainly, so that the team stays motivated due to delivering the real value, while the business gets increased predictability and quality.

So the question as stated in the title is:
How to manage such diverse and of changing nature work, but add enough process to keep the objectives of increased predictability, software quality and job satisfaction?

We think that we have following options:

1. Two separate Scrums to manage the two products under active development and a Kanban board to pull the BAU items for the third product. People would rotate between the 3 to give everybody some smooth with the rough (new projects vs. BAU work). Downsides are the various combinations affecting even very rough notion of team capacity and velocity, fluctuating estimates.
2. One Scrum with all work across the 3 projects going into it. This way we are staying a team of the same capacity, the same averaged ability to estimate, and rotating of smooth to rough would be happening on per user story basis. We are not sure yet whether this way is supported by the tools we use (Jira) but it seems like much better option to accommodate such complex business setting.

I think we are keener on option 2, but would anybody see any obvious problems and trappings which we might have missed?

Any constructive pointers and suggestions much appreciated!

N.B. We know how specific and unique such situation is and ideally we all would work on one project/product with well groomed backlog, great road map and with business being able to create ideal delivery environment, but these things are out of our control.

---

^{1 : Business as usual}

Answer 1

Adding additional Scrum teams is a function of the number of development team positions you have, not the products you're working on. A development team should be no more than nine people, so if you have 20 development team members, then it might be appropriate to divvy people out into separate product Scrum teams. However, doing Scrum of Scrum is non-trivial, and you should have a well-establish process and the necessary support positions in place before you even consider it.

If you have 9 or few people on your development team, having 3 products is not a reason to break the team up. The way this all works is deceptively simple. First, everything goes in the backlog. It really doesn't matter whether it's for separate products or not; it's all work that needs to be done by the team. You can use tags, areas, epics, etc. to distinguish what product a particular PBI belongs to if you like, but it hardly matters.

Second, everything gets assigned a business value. Typically, the business value will follow the same format as story points for your effort, with a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 40, 80, 120, etc.), but will generally add two zeros to the end to 1) differentiate it from the effort and 2) make it look like money. It's not money, but business types like to see things like 1300 rather than 13 for something like business value. That's all just convention, though, you're free to handle it however you like, just as with effort. The point is that you need some scale of business value and you need to assign PBIs to that scale.

Third, you prioritize the backlog based on this business value. The more business value a PBI has, the more inherently valuable to the organization it is, and therefore the higher priority it has for the organization. As a side note, it's for this reason that I like to recommend that Scrum teams treat everything as a PBI, including bugs, technical debt, etc. A bug is not inherently more valuable because it's a bug, but the bold red that usually goes along with a "bug" status tends to imply it needs to be fixed right away. Conversely, there's a tendency to avoid paying off technical debt, even if it has great value to the organization to do so, simply because it's implied that it's not as important as the buzz-word features that go into the marketing brochures. When everything is a PBI and assigned a business value, you're then always working on the things that are most valuable to the business, regardless of whether it's a feature, a bug, tech debt, and regardless of whether it's for Product A, B, or C.

Which brings me to: fourth, work on the items with the most business value each sprint. It doesn't matter which product it's for at that point. If your "maintenance" product has something that needs to be done with great value to the business, it comes front and center, whereas if your new, flashy product has something a proposed item with little to no business value, it goes to the bottom of the pile, as it should, despite the fact that it's for the product everyone wants to work on.

In case it's not entirely obvious through repetition, here's a bit more: business value, business value, business value. It's all about business value. If you're working on stuff that doesn't bring value to the organization you're wasting your time. Period. At any given time, during any given sprint, you should always be working on the PBI that has the greatest value to the organization, regardless of what type of thing it is or what product it's part of.

Then, when it comes to your devs wanting to work on "sexy" features and not wanting to go grunt maintenance work, well, welcome to the world of software development. That describes every developer ever. Unfortunately, there's always grunt work to be done and somebody has to do it. The best you can do is try to rotate it, so maybe if Developer A worked on a maintenance product PBI last sprint, Developer B will have to do one this sprint, while Developer A gets to take a crack as a flashy product PBI. Spread the pain, as it were.

Answer 2

Option 2 with a dedicated product owner for each of the projects. Each product owner must agree during Sprint Planning that the sprint will capture enough deliverables for their project. Leverage in negotiations will occur based on the agreed upon priority project order for that sprint.

Balance a less interesting task with a more interesting one where possible. Alternatively, if BAU tasks are really boring, assign credits to them with a reward of an afternoon off for anyone accumulating some agreed upon number of those credits. In the long run the return will more than pay for the cost of those afternoons awarded.

Answer 3

Its an common situation and I think most businesses manage it with:

3: Make one dedicated team per project + one for BAU

Which is great for management but not so good for devs stuck on BAU

The problem you'll face with 1 is that rotating team members slows things down and people get lazy on the hard tasks if they know they are going to rotate out.

The problem you'll face with 2 is both that progress on the projects is limited by volume of BAU work and priority bug of the day. PLUS you will tend to naturally split into teams with people choosing tasks related to the area they know.

My solution is to FINISH projects, ie stop the BAU work and move on to the next thing.

Its very hard for a business to do this because there are always existing customers, internal and external, that want new features.

But from a tech point of view at some point you are just turning that original piece of software into a giant ball of mud. It should be a better investment making a v2 or something new.