Agile Product Ownership in a Nutshell

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 is gonna
solve and for who 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 our 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 lost ideas so Pat helps turn these
into concrete user stories now somebody
has to actually build a system so here
they are
a small co-located 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
four to six 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 us – some are small and
count as a half but all in all it adds
up to about four to six 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 four to six ideas
per week they have lots of ideas and
lots of wishes and every time we deliver
something to them they’ll get even more
ideas and ask for even more stuff so
what happens if we try to please don’t
try to do everything to ask for will get
overflow suppose the team starts working
about 10 new stories per week if the
input is 10 and the output is 4 to 6 the
team will get overloaded that will cause
multitasking demotivation and all kinds
of bad stuff and ultimately it’ll 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 highways 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
four to six features per week so which
four six features shall we build this
week and the product owners job is to
figure out out of all possible stories
in the whole universe which four to six
stories shall we deliver next the
compound way is to limit work in
progress or limit WIPP WIP suppose the
team decides that five is the optimal
number of stories to be worked on
simultaneously they’ve learned that
that’s just enough to keep everybody
busy without causing overload so they
decide that five is their whipped limit
whenever they finish one story they’ll
accept one news story thereby making
sure that they never break the limit of
five ongoing stories both of these
approaches work fine in the sense that
the team will have just enough work to
do and they’ll be able to word fast and
effectively a side effect though is that
there will be a 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 ten
new stories every week and the team’s
delivered four to six stories every week
that means the queue will just keep
getting longer and longer right so
before you know it you have a six-month
long wish list in the backlog and
growing that means that on average every
story that’s team delivers is something
that somebody asked for six months ago
how agile is that so there’s really only
only one way to stop the queue from
getting out of control and that word is
no it is the most important word for
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 products 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 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
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 now these 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’ve
used and I bet you can think of at least
one really simple feature that is very
important that 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
pad prioritize intelligently like here
these two stories are roughly the same
size but a 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 sec 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 okay 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 an estimate
trying to get it all right from the
beginning is pretty dumb because that’s
what 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 breakdown in a just-in-time
fashion we can take advantage of our
latest insights about the product and
use your needs all this stuff I’ve been
talking about
estimating the value and size of stories
and prioritizing splitting all that is
usually called backlog grooming Pat runs
a backlog grooming workshop every
Wednesday from 11 to 12 one hour per
week the whole team is usually there and
sometimes a few stakeholders as well the
agenda varies a bit but sometimes it
focuses 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 experience product owners what it
takes to succeed they usually emphasize
passion and communication so it’s no
coincidence that the first principle of
an agile manifesto is individuals and
interactions over processes and tools so
the product owners job is not to
spoon-feed the team with stories that’s
boring and ineffective Pat instead makes
sure everybody understands the vision as
a 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 trade-off
decisions on their own so Pat can focus
on the big picture let’s take a look at
a few of the trade-offs that need to be
made by Pat and the team first of all
there’s a trade-off 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 and there’s
technical risk will it work on the
platform where you want to run it on
will it scale and there’s cost and
schedule risk can we finish the product
and 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 a user interface prototypes and
technical spikes or experiments maybe
not too exciting for their 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
customer value we know what we’re going
to build at how so just do it and by
doing the highest value stores 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
and 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 a whole new feature area
within the same product that is business
agility so when I talked about value
here I actually mean knowledge value
plus customer value and we need to
continuously find a trade-off between
these two another trade-off is
short-term versus 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 firefighting and fire
prevention and this relates to another
trade-off 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 trying to get it perfect we
may miss the market window or run into
cashflow 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 might be
drowning in technical debt that our
velocity will approach a zero or suppose
we are here building in a beautiful
cathedral in record time except that the
users didn’t need a cathedral they
needed a cameraman
so there’s a healthy tension here
between the scrum rules 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’ll 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 a trade-off
between new product development and old
product improvement product backlog is
actually a slightly confusing term
because it implies that there is only
one product and project is a confusing
term – 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 it product reaches end of life and
is shut down so when a team starts
developing a new product
happens to their last one handing off a
product from one team to another is
expensive a 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 order wants this team
to build and it can be a mix of stuff
from different products and the product
owner needs to continuously make
trade-offs 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 is
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 bernam chart and you can draw an
optimistic and pessimistic trendline you
can do it using fancy statistics voodoo
or you can just draw 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 okay 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 lies tell us I will
most likely finish all of these by
Christmas some of those and none of
those and finally suppose the
stakeholders say can we get the
these features by Christmas now that’s a
fixed time fixed scope question looking
at trend lines Pat says nope sorry it
can happen
followed by here’s how much we can get
done by Christmas or here’s how much
more time we would need to get
everything done it’s generally better to
reduce scope that they 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 no
time it’s 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 these calculations
are pretty simple to do so Pat updates
the forecast every week the important
thing here is that we are using real
data to make the forecasts and then we
are being honest about uncertainty I
said no line 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 burnup curve
will gradually 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 ok
what if we have a larger project with
multiple teams and we have several
product owners each with their old
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 we
still need a short feedback loop etc
velocity is really 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 teens 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 starts so that they build things
in a sensible
and avoid sub optimizing in large
projects it’s usually calls for some
kind of chief product owner role to keep
the product owners synchronized okay
that’s it
ads on product ownership in a nutshell
hope this was useful to you