Scrum Project – Who Handles UX?

Read this excellent article from Ron Jeffries and you will understand what needs to be done.

If you want to do Scrum, you have to follow the rules. If you don't follow the rules, it's not Scrum. And you shouldn't expect it to work.

There is plenty of space in Scrum to adapt the rules to the local team, but only once the basics have been mastered. This sounds like a prime example of a group of people who decided to alter the rules before they truly understood what they were doing. The principle of Shu-Ha-Ri applies here (and in many other places).

I'm currently 2/3rd of the way through Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise and I would highly recommend that book as it covers a lot of the topics issues involved in scaling out agile process to more than one team and maintaining backlogs for enterprise-level products (i.e. those that might span years)

Although I haven't encountered your specific situation so I can't really say how well my advice would work in practice, based on my own experience with Agile, combined with external reading, this is what I would suggest:

• Maintain separate backlogs for each product. So you would have five backlogs: P, A1, A2, B1, B2. This way each backlog clearly indicates where you are in that product's development and what lays ahead for that product.
  • When you have too many stories in a backlog, you reduce overall agility as there's more things for you to manage. Having 5 different products in one backlog won't be very productive. Especially if you have more than one product owner. How much moving around would you have to do if you had a single backlog and all of a sudden your CTO comes to you and says, A2 is your highest priority, put everything else on hold?
  • Leave product backlog at a somewhat high-level (i.e. don't break stuff down to 1-3pt). Having only larger items will again reduce the number of stories and the teams need to deal with and will make it much easier to prioritize work.
• Create 2 team backlogs: A and B. Based on business needs and priorities you should able to pull stories from P, A1, and A2 and transfer those into A. And P, B1 and B2 would get transferred into B.
  • Ideally you would only have several iterations worth of stories in the team backlogs. This way as business needs and priorities shift, you'll be able to adjust the volume of stories that you pull from each of the product backlogs.
  • These team backlogs would take product stories and possibly break them down into finer chunks with more details defined. But you'd only fill in details when the team is ready to actually do the work.

The positive thing is that having separate product backlogs means that you'll have 5 velocities and you will be able to predict exactly when each feature for those products will be delivered.

The challenge will be to standardize the point scale across the 5 projects and 2 teams because if different products/teams use different point scale, your velocity will be worthless. The book I mentioned above talks about some of the ways for this standardization. Basically, you want to start with same base weight (e.g. 1pt ~ 1 day of work). Also having scrum of scrums meetings (possibly with technical leads) will help with higher level planning, equalizing the point scale and coordination of work between the teams.