Often the best solution is to change the context. From your description, it sounds like you may be trying to work on too many projects at once. This multitasking leads to thrashing and wasted effort. Working on all products at once may give the illusion of progress on all of them, but really just delays the delivery of the first one. The last bit of work gets done at the same time, or later, whether you delay starting it or multitask.

It’s better to get a shippable increment of one product finished than to be working on several in parallel. You can switch between products after shipping that increment. I recommend Johanna Rothman’s book, Manage Your Project Portfolio, for more strategies on dealing with this problem.

I hope I described my problem well enough and there is someone outthere who can help :)

The problem with having one Product Backlog with all the projects thrown together is communication outside the team. The rest of the company sees the projects as separate. This is something that also needs enhanced transparency, which we will create.

Our current first pass plan is to create a combined Sprint Backlog for one-week sprints. I don’t like this because it perpetuates the false view of separate projects into the rest of the company. However, one must pick how much to change at one time. In this culture, getting Product Backlogs in place is the first necessary step. Pushing transparency up the chain will then be better supported.

I suspect that there’s a lot of thrashing, and loss of both focus and energy. Wouldn’t it be better to do one thing until it’s done-done before switching to another?

Johanna Rothman has written on multi-tasking a lot. You might find her article, Refocusing: Emerging from the Split Focus Schedule Game, of interest. Also, I recommend Tom DeMarco’s book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

I am facing this situation now. Many PO’s each with several projects, a team of 8 developers plus 2 floaters with constrained skill sets from another group.

The POs should come to an agreement amongst themselves about the ordering of the Product Backlog. If they can’t that indicates and organizational problem that won’t be solved by pushing the decisions down to the development level.

During the sprint planning, it may be advantageous to reorder some of the backlog items to make the work in the sprint less fragmented. This can be discussed by the developers and product owners. If everyone feels they are on One Team with common goals, these things can be worked out easily. If there is distrust and manipulation, it will be visible and cause problems.

BR,

Gilad

It definitely makes prioritizing harder, and it can lead to silliness like Customer A gold plating the system with resources that Customer B could better use to add real business value.

Certainly less than ideal, I agree.