How to build a big product in a collaborative way – 3

Well in shape into 2013 after the end of the Great MayanCycle, let’s continue the posts thread talking about how to help a Product Owner team work effectively.

We talked already about how to setup the team and how we build the Product Backlog collaboratively.

Let’s touch today the way our team grooms and orders the backlog and I will start telling you the story of a failure.

A “good” failure indeed: one of those you learn something out!

Some months ago, facing the development of customer requests based on the business priority order, the team realized that implementing a new feature would have required moving to the new version of a 3^rd party we integrate in our system.

No big deal: they said!

And everything would have been ok, except for the fact that, after some weeks, we realized that the new version of this product was not actually properly working with our new operating system.

Result, as you can imagine, was: a lot of troubles, blaming games, fights, time wasted and, finally, the decision to roll back to the previous version.

What went wrong then?

The question is that requirements are prioritized according to business value, but Product Backlog is ordered instead, taking into account other factors than simply customer priority.

Otherwise, what would be the added value of a Product Owner?

My 10-years old son would be perfectly able to do tasks strictly following a prioritized list given by someone else.

Of course, I oversimplified the question a bit.

But not too much indeed!

However, out of this failure, we learned how to arrange our backlog better, putting into it competence and brains, not only from Product Owners, but from developers and managers as well.

Now, before ordering our backlog, we take into account 3 parameters mainly:

1. Business value
2. Dependencies
3. Risks

So, before giving the backlog a certain order, we evaluate the business value ranking coming from Product Manager, we consider the Product Anatomy and rate both the technical and non-technical risks we see associated to the requested MMFs. 

So the PO team defines the backlog order, putting high in the list not necessarily the most valuable items, but obviously the ones which the others are dependant from. We give special attention to the riskiest features, many times splitting them and touching them first, so that we can have an early feedback and take actions accordingly.

Actually there’s a fourth parameter which comes into play many times, that is cost: since the goal of a Product Owner is maximizing the Return on Investment, one could choose to anticipate cheaper features, given a certain business value.

That’s the kind of brain we have to put in, to move from prioritized requirements to an ordered backlog.

What else would you suggest to consider in order to get a proper backlog ordering?