Agile Product Ownership in a Nutshell

This is basically a 1 day product ownership course compressed into 15 minute animated presentation. There's obviously more to product ownership than this, so see this is a high level summary.

For translated versions & translation guide, see http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell

Special thanks to Alistair Cockburn, Tom & Mary Poppendieck, Jeff Patton, Ron Jeffries, Jeff Sutherland, and Michael Dubakov for providing many of the models, metaphors, and ideas that I use in this presentation.

Download the complete drawing here:
https://dl.dropbox.com/u/1018963/Articles/PO-in-a-nutshell.png

Downloadable version of the video here:
https://dl.dropbox.com/u/1018963/Videos/PO-in-a-nutshell.mov

PS: The intro & outtro song is just me jamming in my home studio. I bought a cool half-acoustic guitar a few months ago and was looking for an excuse to make use of it :o)

Tools used: Artrage (drawing program), Wacom Intuos 5 (drawing tablet), Screenflow (screen & audio capture).

Let's talk about Agile
software development

from the perspective
of the product owner.

Here's Pat.
She's a product owner.

She has a product vision that
she's really passionate about.

She doesn't know the details of
what her product is going to do,

but she knows why we're
building the product,

and what problem it is going
to solve, and for whom.

She talks about it all the time.

Here are the stakeholders.

They're the people who are
going to use and support

or in any way be affected by
the system being developed.

Pat's vision is that these
people here will love her system

and use it all the time and
tell their friends about it.

The stakeholder needs and
Pat's ideas are expressed

as user stories here.

For example, if this was
a flight booking system,

people need to be able
to search for a flight

and maybe that would
be one user story.

Both Pat and the stakeholders
have lots of ideas

so Pat helps turn these into
concrete user stories.

Now, somebody has to
build the system,

so here they are a
small collocated,

cross functional, self organizing development team.

Since this is an Agile team,

they don't save up for a big bang release at the end.

Instead, they release
early and often.

In this case, they
usually release about

4-6 stories per week,
so that is their capacity.

Capacity is easy to measure,

just count the number of
stories released per week.

Some stories are big,
so they count as two,

some are small and
count as a half,

but all in all, it adds up to about 4-6 stories per week.

Some people call
these story points,

but I'm just going to call
it stories per week.

In order to maintain this pace,
and not get bogged down by

manual regression testing,
the team invests heavily

in automated testing and
continuous integration.

So every story has at least one
automated acceptance test at the

feature level, and most of the
code has automated unit tests.

The problem is, here are
a bunch of stakeholders

asking for all kinds of stuff,

and they sure aren't going to be limited to 4-6 ideas per week.

They have lots of ideas
and lots of wishes,

and every time we deliver
something to them,

they will get even more ideas
and ask for even more stuff.

So what happens if we
try to please them,

try to do everything
they ask for?

We'll get overflow.

Suppose the team starts working
on 10 new stories per week.

If the input is 10,
and the output is 4-6,

the team will get overloaded.

That will cause multitasking,
demotivation, and all kinds of

bad stuff and ultimately it will
lower output and lower quality.

It's a lose-lose proposition.

It's kind of like trying to
shove more paper into a printer

to make it print faster, or
shoving more cars onto an

already crammed highway system.

It just doesn't work, it
just makes things worse.

So, what do we do about this?

Well, the Scrum and XP way
of avoiding this problem

is called "yesterday's weather".

The team says "Well,
the past few weeks

we've finished 4-6
features per week.

So which 4-6 features
shall we build this week?"

And the product owner's
job is to figure out,

out of all the possible stories
in the whole universe,

which 4-6 shall we deliver next?

The Kanban way is to
limit work-in-progress,

or limit WIP, W-I-P.

Suppose the team decides that 5
is the optimal number of stories

to be worked on simultaneously.

They've learned that that's just
enough to keep everyone busy

without causing overload.

So they decide that
5 is their WIP limit.

Whenever they finish one story,
they will accept one new story,

thereby making sure that

they never break the limit
of 5 ongoing stories.

Both of these approaches
work fine in a sense that

the team will have just
enough work to do

and they'll be able to work
fast and effectively.

A side effect, though,
is that there will be

queue forming in
front of the team,

and that queue in Scrum is
called a Product Backlog.

The queue needs to be managed.

Suppose stakeholders keep asking
for 10 new stories every week,

and the teams deliver 4-6
stories every week, that means

the queue will just keep getting
longer and longer, right?

So before you know it you have
a 6 month long wish list

in the backlog, and growing.

That means that, on average,
every story that the

team delivers is something that
somebody asked for 6 months ago,

so how agile is that?

So there is really only one way
to stop the queue from

getting out of the control,
and that is the word No.

It is the most important
word for a product owner,

and Pat practices it every day
in front of the mirror.

Saying yes to a new feature
request is easy, especially if

it only means adding it to
an ever growing backlog.

The most important job for a
product owner is to decide what

NOT to build, and take the
consequences of that decision.

And that's why it's
hard, of course.

The product owner decides what
goes in, and what goes out.

The product owner also
decides the sequencing -

what do we build now,
what do we build later,

and how long does this list
actually need to be?

That is a hard job, so
Pat doesn't do it alone.

She does it in collaboration

with the team and
the stakeholders.

To be able to prioritize,
the product owner must have

some idea of the value of each
story, as well as the size.

Some stories are
critically important,

and others are just
bonus features.

Some stories take just
a few hours to build

and others take months.

Now, guess what the
correlation is

between story value
and story size?

That's right - None!
Bigger doesn't mean better.

Think of any system that you
have used, and I bet you can

think of at least one
really simple feature

that is very important,
that you use every day.

And I bet you can think of at least
one huge complicated feature

that is totally unimportant.

Value and size is what helps
Pat prioritize intelligently.

Like here, these two stories
are roughly the same size,

but have different value.

So build this one first.

And over here, these two stories
have roughly the same value,

but different size,
so build this one first.

And so on.

Okay, that sounds easy enough,
but wait a second, how does she

know the value of a story,
and how does she know the size?

Well, here's the bad news,
she doesn't.

It's a guessing game,

and it's a game that everyone
is involved in.

Pat continuously talks to
stakeholders to find out what

they value and she continuously
talks to the team to find out

what they think is big or small,

in terms of
implementation effort.

These are relative guesses,
not absolute numbers.

I don't know what this apple
weighs, or that strawberry, but

I'm pretty sure that the apple
weighs at least five times as

much, and that the strawberry
tastes better, to me at least.

And that's all Pat needs to know

in order to prioritize
the backlog.

It's pretty cool that way.

At the beginning of a new
project our guesses

will inevitably suck.

But that's OK, the biggest
value is really in the

conversations rather than
in the actual numbers.

And every time the team delivers
something to real users, we

learn something and get better
at guessing both value and size.

That's why we continuously
prioritize and estimate.

Trying to get it all right from
the beginning is pretty dumb,

because that's when
we know the least,

so the feedback loop
is our friend.

Prioritization is
not enough though.

In order to deliver
early and often,

we need to break the stories
down into bite-sized pieces,

preferably just a few
days of work per story.

We want this nice funnel shape,
with small, clear stories

at the front and more vague
stories at the back.

By doing this break-down
in a just-in-time fashion,

we can take advantage
of our latest insights

about the product and
the user needs.

All this stuff I've been
talking about -

estimating the value and size of
stories, prioritizing, splitting

- all that is usually called "backlog grooming."

Pat runs a backlog grooming
workshop every Wednesday

from 11:00 to 12:00,
one hour per week.

The whole team is usually there,

and sometimes a few
stakeholders as well.

The agenda varies a bit but
sometimes the focus is

on estimation, sometimes on
splitting stories, and

sometimes on writing acceptance
criteria for a story, etc.

So I hope you're noticing
the theme here:

Communication.

Product Ownership is really
all about communication.

When I ask experienced product
owners what it takes to succeed,

they usually emphasize
passion and communication.

So it's no coincidence that

the first principle of
the Agile manifesto is

"Individuals and Interactions over Processes and Tools."

So the Product Owner's job is

not to spoon-feed the
team with stories.

That's boring and ineffective.

Pat, instead, makes sure
everybody understands

the vision, that the team
is in direct contact

with stakeholders, and that
there is a short feedback loop

in terms of frequent
deliveries to real users.

That way the team learns and can
make daily tradeoff decisions

on their own, so Pat can
focus on the big picture.

Let's take a look at a few of
the tradeoffs that need to be

made by Pat and the team.

First of all,

there's the tradeoff between
different types of value.

Early on in a project,

uncertainty and risk
is our enemy.

There's business risk: are
we building the right thing?

There's social risk: can
these people build it?

There's technical risk -
will it work on the platform

that we want to run it on?

Will it scale?

And there's cost
and schedule risk.

Can we finish the product in
a reasonable amount of time,

for a reasonable
amount of money?

Knowledge can be seen
as the opposite of risk.

So when uncertainty is high, our
focus is knowledge acquisition.

We focus on things like user
interface prototypes

and technical spikes,
or experiments.

Maybe not too exciting
for the customers,

but still valuable because
we are reducing risk.

From a customer
value perspective,

the curve looks like
this in the beginning.

As uncertainty is reduced, we
gradually focus more and more

on the customer value.

We know what we're going to
build and how, so just do it.

And by doing the highest-value
stories first,

we get this nice
steep value curve.

And then, gradually, the value
curve starts flattening out.

We've built the most important
stuff, and now we're just adding

the "bonus features", the
toppings on the ice cream.

This is a nice place to be,
because, at any point, Pat and

the team may decide to "trim the
tail" to cut right here and move

on to another, more important
project, or maybe start on a

whole new feature area
within the same product.

That is business agility.

So when I talk about value here,
I actually mean knowledge value

plus customer value.

And we need to continuously find
a tradeoff between these two.

Another tradeoff is short-term
vs long-term thinking.

What should we build next?

Should we do that urgent bug
fix, or build that awesome new

feature that will blow the users
away, or do that difficult

platform upgrade that will
enable faster development

in the future sometime?

We need to continuously balance
between reactive work and

proactive work, or fire-fighting
and fire-prevention.

And this is relates
to another tradeoff.

Should we focus on building the
right thing or building the

thing right, or perhaps
building it fast?

Ideally we want all three, but
it's hard to find the balance.

Suppose we are here, trying to
build the perfect product,

with the perfect architecture.

If we spend too much time to
trying to get it perfect,

we may miss the market window
or run into cash-flow problems.

Or suppose we are here,

rushing to turn a prototype
into a usable product.

Great for the short term,
perhaps,

but in the long term we'll be
drowning in technical debt

and our velocity will
approach zero.

Or suppose we are here,

building a beautiful
cathedral in record time.

Except that the users
didn't need a cathedral,

they needed a camper van.

So there's a healthy tension
here between the Scrum roles.

Product Owners tend to focus
on building the right thing.

Development teams tend to focus
on building the thing right.

And Scrum masters, or Agile
coaches, tend to focus on

shortening the feedback loop.

Speed is actually worth
emphasizing because

a short feedback loop will
accelerate learning,

so you will more quickly learn
what the right thing is,

and how to build it right.

However, all three perspectives
are important so,

keep trying to find the balance.

Finally, there is the tradeoff
between new product development

and old product improvement.

Product backlog is a
confusing term,

because it implies that
there is only one product.

And project is a
confusing term, too,

because it implies that
product development ends.

A product is never
really finished.

There's always maintenance and
improvements to be done, all the

way until the product reaches
end of life and is shut down.

So when a team starts
developing a new product,

what happens to their last one?

Handing off a product from
one team to another

is expensive and risky.

So a more common scenario
is that the team continues

maintaining the old product
while developing the new one.

So it's not really a
product backlog anymore,

it's more like a team backlog,

a list of stuff that the product owner wants this team to build,

and it can be a mix of stuff
from different products.

And the product owner needs to

continuously make tradeoffs
between these.

Once in a while, a stakeholder
will call Pat and say

"Hey, when will my
stuff be done?"

or "How much of my stuff will
be done by Christmas?"

As product owner, Pat
is responsible for

expectations management, or
more importantly, realistic

expectations management,
and that means no lying.

I know, it's tough, but
who said Agile was easy?

It's not really that
hard to make a forecast,

as long as it doesn't
have to be exact.

If you measure the velocity
of your team,

or the combined velocity
of all your teams,

you can draw a story burn up
chart like this.

This chart shows the
cumulative number of stories

delivered over time, or
story points if you prefer.

Note the difference.

This curve shows output.
That curve shows outcome.

That's the output, and
that's the outcome

that we hope it will achieve.

Our goal is not to produce
as much output as possible.

Our goal is to reach the desired
outcome: happy stakeholders,

using the least possible output.

Less is more.

Now, look at the burn up chart
and you can draw an optimistic

and a pessimistic trend line.

You can do it using fancy
statistics voodoo, or you can

just draw it visually, and the
gap between these lines is of

course related to how wavy and
unpredictable your velocity is.

Luckily, that tends to stabilize
over time, so our cone of

uncertainty should get
tighter and tighter.

OK, so back to
expectations management.

Suppose the stakeholders ask Pat

"When will all of THIS stuff be done? When will we be here?"

That's a fixed-scope,
variable time question.

So Pat uses the two
trend lines to answer.

"Most likely sometime
between April and mid-May."

Suppose the stakeholders
ask Pat

"How much will be done
by Christmas?"

That's a fixed time,
variable scope question.

The trend lines tell us "We'll
most likely finish all these

by Christmas, some of those,
and none of those."

And finally, suppose
the stakeholders say

"Can we get these
features by Christmas?"

Now, that's a fixed time,
fixed scope question.

Looking at trend lines, Pat says

"Nope, sorry, it ain't
gonna happen",

followed by "here's how much we
can get done by Christmas"

or "here's how much more time we
need to get everything done."

It's generally better to reduce
scope than to extend time,

because if we reduce scope
first, we still have the option

to extend the time later and
add the rest of the stories.

Vice versa doesn't work
because darn it,

we can't turn the
clock backwards.

You know, time is rather
annoying that way, isn't it?

So, Pat puts it this way,

"We could deliver something here, and the rest later.

Or we could deliver nothing
here and the rest later.

Which do you prefer?"

The calculations
are simple to do,

so Pat updates the
forecast every week.

The important thing here is that
we are using real data to make

the forecast, and that we are
being honest about uncertainty.

I said no lying, right?

So this is a very honest way of
communicating with stakeholders,

and they usually
appreciate that a lot.

If your organization doesn't
like truth and honesty,

it probably won't like Agile.

Now, a word of warning.

If the team is accumulating
technical debt,

if they're not writing tests,
and not continuously improving

the architecture then they will
get slower and slower over time,

and the story burn up
curve will flatten out.

That makes forecasting
almost impossible for Pat.

So the team is responsible for
maintaining a sustainable pace,

and Pat avoids pressuring
them into taking shortcuts.

Okay, what if we have a larger
project with multiple teams?

And we have several product
holders, each with their own

backlog for a different
part of the product?

Overall, the model
is really the same.

We still need capacity
management, we still need

stakeholder communication,
we still need product owners

who can say No, we still
need backlog grooming

and we still need a short
feedback loop, etc.

Velocity is the sum
of all output,

so that can be used
for forecasting.

Or make a separate
forecast for each team,

if that makes more sense.

In a multiple team scenario,
however, the product owners

have an important additional
responsibility:

to talk to each other.

We should organize the teams
and backlogs to minimize

dependencies, but there will
always be some dependencies that

we just can't get rid of.

So there needs to be some kind
of sync between the product

owners so that they build
things in a sensible order,

and avoid suboptimizing.

In large projects, this usually
calls for some kind of Chief

Product Owner role to keep the
product owners synchronized.

Okay, that's it.

Agile product ownership
in a nutshell.

Hope this was useful to you.