Product owners: the cold hard stats

This week i had agile training. It stressed the importance of dedicated product owners. The trainer told us that the bare minimum is 50% of the product owners time.

Where i work it’s common to have a nominal product owner who can only spare 5-10% of their time. This effectively means that 80-90% of requirements are “made up” by the dev team.

Put another way, it takes 5-10 times longer for the company to get the product it wants.

It means the dev team are wasting 80-90% of their time.

The quickest fix is to start making members of the dev team into product owners to address the balance.

Dev targets: measuring business value

Typically, dev targets are based on functionality delivered. This depends heavily on having very specific requirements – how do you define “done”? Its much harder than it sounds. What if the functionality is delivered but with major bugs? What if (when) the requirememt change halfway through the sprint – is that shifting the goalposts?

There is a better way. The product owner can assign “value” points to each story, the same way that developers assign “cost” (aka complexity) points. The points can be relative rather than absolute.

The sprint goal can then be framed as: “Deliver business value of X points”. If the requirements change, no problem. If the released code has a bug, it’s value can be deducted from the sprint total. (Fixing bugs can be given a value – the same as for new features).

Have any teams out there tried this approach?

Product Owner Essentials

From “Getting Real” (37signals).

• Underdo Your Competition
• Fix Time and Budget, Flex Scope
• Less Mass
• Lower Your Cost of Change
• Embrace Constraints
• Half, Not Half-Assed
• Start With No
• Hidden Costs
• Rinse and Repeat

The book contains loads of other useful advice too. Genius.

Why products are like a works jolly to Paris

If you’ve ever been to Paris (or anywhere else) with 50 people you will know that the bigger the group the harder it is to get anything done or to get anywhere.

The length of time it takes for the group to make a decision increases drastically with the number of people in the group.

This is similar to the number of features in a product. The more features, the harder it is to get anything done (see my previous post on the subject).

Sometimes you see a professional tour group leader (you know, the ones waving an umbrella). They massively reduce the “slow-motion” effect of travelling in a group. The product equivalent is the product owner. Every big group of features needs one!

Feedback loops in Scrum

Feedback and feedback loops are a key part of Scrum:

• Iterative releases/demos. Regularly get feedback from the business and from end users.
• Sprint velocity. Velocity takes into account the accuracy of previous estimates.
• Retrospectives. Get feedback from the team as to how they could become more effective.
• Standups. Promotes feedback between members of the team.
• Sprint walls. Gives feedback to everyone about the status of the sprint.
• Burndown charts. In theory this gives early feedback to the business when a sprint is behind schedule. In practice, “hours remaining” is a *very* inaccurate measure pf progress. It doesn’t seem to fit with the Agile principle: “Working software is the primary measure of progress”.

Agile promotes additional feedback such as daily interaction between developers and the business.

Talking of feedback, leave a comment below…

Estimation: “ideal days” vs “relative size”

A common criticism of using “relative size” is that developers tend to estimate in ideal days and then translate it to relative size.

I disagree. I find myself doing the opposite. This week, when asked for an estimate i said “twice what it took us to deliver X”. Where X was a feature that we estimated would take one week and actually took two.

Some people may also dislike relative size because it takes a few weeks to get a meaningful “velocity”. This is actually a good thing – it highlights the trap of projecting from wishful thinking rather than empirical data.

So why “relative size”?

It avoids a common pitfall of absolute size: simply being overly optimistic in all your estimates. Relative size fits better with the Agile principle of feedback: “The primary measure of progress is working software”.

Relative size also makes it hard to game the system.

Either way…

No matter which approach you take, estimates should factor in risks, unknowns, etc. All things be equal, a high-risk feature should have a higher estimate than a low-risk feature.

It may even be worthwhile doing a best-case and worst-case estimate. I suspect there are generally more potential delays than potential windfalls.