Product Ownership (4)

This post is part of a series on my view on essential qualities for a good product owner in scrum. If you just bumped into this post, here are the previous articles: the introduction, part 2 and part 3.

Point 3: "Great communication and negotiation skills"

Let's first of all pull up one of my favorite pictures about project management.

The traditional representation looks like this:

I prefer  a slight variant to it:

[[small sidestep, skip if you understand the pictures]]
For those that never seen this picture, here it is explained in an easy way.
Scope = what needs to be done
Budget = money, people, hardware, software, ...
Time = days till delivery date
Quality = how good the result is (compared to what the customer asked for)
The triangle is sometimes called the iron triangle (there are a few variations out there). Each side and the surface representing one of the aspects. Since it's an iron triangle you can't change one aspect without affecting the others.
What the second version factors in is that scope & quality are closely linked. They actually fight for the same area in the triangle, meaning they mostly behave in a "scope+quality=1" manner. The only way to improve both is generally to play with the sides of the triangle to provide a bigger surface.
The other nice thing about it is that it takes out the resources (=people) from the budget aspect. In most development projects, adding developers is not something that is as easy as adding more hardware or software (which typically falls in the budget area)
[[end sidestep]]

As far as I'm concerned, this is one of the most fundamental pictures to understand. The good news is, it's not rocket science. The bad news, you'll always be fighting about at least one aspect of the triangle.
The thing that is not on the triangle though, is equally important. Communication! I consider communication the glue that holds this triangle together. I already expanded on communication in an earlier post. What is said there still holds true (hurray), and the key point in this case would be the feedback. Because feedback means exchanging ideas, ideas generally mean new ways of looking at something and eventually coming up with a solution. In the case of our triangle, that solution might be to make a tradeoff that suits all stakeholders as good as possible. Or put differently, communication is a key aspect of negotiating. And both skills are indispensable to come to an agreement.

Another part of reaching an agreement is striking a good balance between complexity and added functionality, based on the time (and other aspects in the triangle) that are set. This is where the negotiation really kicks in. Every stakeholder feels his feature set is the most important, highest value, first to be developed feature. And probably, in their distinct worlds, that could be very true. However, if stakeholder A is asking a feature that is so complex it would take 2 sprints of the team, that would cut off the minor update for B and that small module for C for at least another 2 sprints. Stakeholder A's feature may bring some added functionality for B also, but C has no benefit. Where do you go from there? This is where it becomes interesting. How do you balance this? (on a sidenote: yes, I love thinking about balancing stuff also outside game design)
This is where the scrum metrics velocity, business value and storypoints (indicators of complexity as I like to see them) come in handy. They provide you with ammo for your negotiations. How you get out of the situation above? I would probably ask A to split up the 1 story in multiple stories first of all, and see how B could benefit from some of those . Since they are split up, they shouldn't require 2 sprints and complexity on the individual elements should go down. This would open a time for C's request to be fitted in.

The last part of this communication is something I already touched in part 2 of the series. There is a need to communicate with a wide variety of people. Ranging from hardcore developers to golf playing VPs. The way something needs to be presented to those groups is without a doubt very different. In an ideal world, you would have a product owner that can easily summarize technical detail into executive summaries and can expand executive thoughts into detailed user stories. Read that last sentence again, it's key to solving many problems. Speaking the right way to the right person is something I tried to get through on my old blog one time (I'm not entirely happy reading back that post now, but still, the idea in there is key to this last statement)