Press "Enter" to skip to content

Agile Product Ownership in a Nutshell


00:00:04let’s talk about agile software

00:00:06development from the perspective of the

00:00:08product owner here’s Pat she’s a product

00:00:11owner

00:00:11she has a product vision that she’s

00:00:13really passionate about she doesn’t know

00:00:15the details of what her product is going

00:00:16to do but she knows why we’re building

00:00:18the product and what problem is gonna

00:00:20solve and for who she talks about it all

00:00:23the time

00:00:23here are the stakeholders they’re the

00:00:25people who are going to use and support

00:00:27or in any way be affected by the system

00:00:28being developed

00:00:29Pat’s vision is that these people here

00:00:31will love our system and use it all the

00:00:32time and tell their friends about it the

00:00:34stakeholder needs and Pat’s ideas are

00:00:36expressed as user stories here for

00:00:39example if this was a flight booking

00:00:41system people need to be able to search

00:00:43for a flight and maybe that would be one

00:00:45user story both Pat and the stakeholders

00:00:47have lost ideas so Pat helps turn these

00:00:49into concrete user stories now somebody

00:00:52has to actually build a system so here

00:00:53they are

00:00:53a small co-located cross-functional

00:00:56self-organizing development team since

00:00:58this is an agile team they don’t save up

00:01:00for a big bang release at the end

00:01:02instead they release early and often in

00:01:05this case they usually release about

00:01:06four to six stories per week so that is

00:01:09their capacity capacity is easy to

00:01:11measure just count the number of stories

00:01:13released per week some stories are big

00:01:15so they count us – some are small and

00:01:17count as a half but all in all it adds

00:01:19up to about four to six stories per week

00:01:21some people call these story points but

00:01:23I’m just going to call it stories per

00:01:25week in order to maintain this pace and

00:01:27not get bogged down by manual regression

00:01:29testing the team invests heavily in

00:01:31automated testing and continuous

00:01:32integration so every story has at least

00:01:34one automated acceptance test at the

00:01:36feature level and most of the code has

00:01:38automated unit tests the problem is here

00:01:40are a bunch of stakeholders asking for

00:01:42all kinds of stuff and they sure aren’t

00:01:45going to be limited to four to six ideas

00:01:46per week they have lots of ideas and

00:01:48lots of wishes and every time we deliver

00:01:51something to them they’ll get even more

00:01:53ideas and ask for even more stuff so

00:01:55what happens if we try to please don’t

00:01:56try to do everything to ask for will get

00:01:59overflow suppose the team starts working

00:02:01about 10 new stories per week if the

00:02:02input is 10 and the output is 4 to 6 the

00:02:06team will get overloaded that will cause

00:02:08multitasking demotivation and all kinds

00:02:10of bad stuff and ultimately it’ll lower

00:02:12output and lower

00:02:13quality it’s a lose-lose proposition

00:02:15it’s kind of like trying to shove more

00:02:16paper into a printer to make it print

00:02:18faster or shoving more cars onto an

00:02:21already crammed highways it just doesn’t

00:02:23work it just makes things worse so what

00:02:25do we do about this well the scrum and

00:02:28XP way of avoiding this problem is

00:02:29called yesterday’s weather the team says

00:02:32well the past few weeks we’ve finished

00:02:34four to six features per week so which

00:02:37four six features shall we build this

00:02:39week and the product owners job is to

00:02:41figure out out of all possible stories

00:02:43in the whole universe which four to six

00:02:45stories shall we deliver next the

00:02:47compound way is to limit work in

00:02:49progress or limit WIPP WIP suppose the

00:02:53team decides that five is the optimal

00:02:55number of stories to be worked on

00:02:56simultaneously they’ve learned that

00:02:58that’s just enough to keep everybody

00:03:00busy without causing overload so they

00:03:02decide that five is their whipped limit

00:03:04whenever they finish one story they’ll

00:03:06accept one news story thereby making

00:03:08sure that they never break the limit of

00:03:09five ongoing stories both of these

00:03:11approaches work fine in the sense that

00:03:13the team will have just enough work to

00:03:15do and they’ll be able to word fast and

00:03:16effectively a side effect though is that

00:03:19there will be a queue forming in front

00:03:21of the team and that queue in scrum is

00:03:22called a product backlog the queue needs

00:03:25to be managed

00:03:26suppose stakeholders keep asking for ten

00:03:28new stories every week and the team’s

00:03:30delivered four to six stories every week

00:03:32that means the queue will just keep

00:03:34getting longer and longer right so

00:03:35before you know it you have a six-month

00:03:37long wish list in the backlog and

00:03:38growing that means that on average every

00:03:41story that’s team delivers is something

00:03:43that somebody asked for six months ago

00:03:45how agile is that so there’s really only

00:03:47only one way to stop the queue from

00:03:49getting out of control and that word is

00:03:51no it is the most important word for

00:03:54product owner and Pat practices it every

00:03:56day in front of the mirror saying yes to

00:03:58a new feature request is easy especially

00:04:00if it only means adding it to an

00:04:02ever-growing backlog the most important

00:04:04job for products owner is to decide what

00:04:06not to build and take the consequences

00:04:08of that decision and that’s why it’s

00:04:10hard of course the product owner decides

00:04:12what goes in and what goes out the

00:04:14product owner also decides the

00:04:15sequencing what do we build now what we

00:04:17build later and how long does this list

00:04:19actually need to be that is a hard job

00:04:21so Pat doesn’t do it alone she does it

00:04:24in collaboration with the team

00:04:25the stakeholders to be able to

00:04:27prioritize the product owner must have

00:04:29some idea of the value of each story as

00:04:31well as the size some stories are

00:04:33critically important now these are just

00:04:34bonus features some stories take just a

00:04:37few hours to build and others take

00:04:38months now guess what the correlation is

00:04:40between story value and story size

00:04:42that’s right none bigger doesn’t mean

00:04:45better think of any system that you’ve

00:04:47used and I bet you can think of at least

00:04:49one really simple feature that is very

00:04:51important that use every day and I bet

00:04:53you can think of at least one huge

00:04:55complicated feature that is totally

00:04:56unimportant value and size is what helps

00:05:00pad prioritize intelligently like here

00:05:02these two stories are roughly the same

00:05:03size but a different value so build this

00:05:06one first and over here

00:05:08these two stories have roughly the same

00:05:09value but different size so build this

00:05:12one first and so on okay that sounds

00:05:15easy enough but wait a sec how does she

00:05:17know the value of a story and how does

00:05:19she know the size well here’s the bad

00:05:21news she doesn’t it’s a guessing game

00:05:23and it’s a game that everyone is

00:05:25involved in Pat continuously talks to

00:05:27stakeholders to find out what they value

00:05:29and she continuously talks to the team

00:05:31to find out what they think is big or

00:05:33small in terms of implementation effort

00:05:35these are relative guesses not absolute

00:05:37numbers I don’t know what this Apple

00:05:39weighs or that strawberry but I’m pretty

00:05:42sure that the Apple weighs at least five

00:05:43times as much and that the strawberry

00:05:45tastes better to me at least and that’s

00:05:48all Pat needs to know in order to

00:05:49prioritize the backlog it’s pretty cool

00:05:51that way at the beginning of a new

00:05:52project our guesses will inevitably suck

00:05:55but that’s okay the biggest value is

00:05:57really in the conversations rather than

00:05:59in the actual numbers and every time the

00:06:01team delivers something to real users we

00:06:03learn something and get better at

00:06:05guessing both value and size that’s why

00:06:07we continuously prioritize an estimate

00:06:09trying to get it all right from the

00:06:11beginning is pretty dumb because that’s

00:06:12what we know the least so the feedback

00:06:14loop is our friend prioritization is not

00:06:17enough though in order to deliver early

00:06:19and often we need to break the stories

00:06:21down into bite-sized pieces

00:06:23preferably just a few days of work per

00:06:25story we want this nice funnel shape

00:06:27with small clear stories at the front

00:06:29and more vague stories at the back by

00:06:31doing this breakdown in a just-in-time

00:06:33fashion we can take advantage of our

00:06:34latest insights about the product and

00:06:36use your needs all this stuff I’ve been

00:06:38talking about

00:06:39estimating the value and size of stories

00:06:41and prioritizing splitting all that is

00:06:44usually called backlog grooming Pat runs

00:06:46a backlog grooming workshop every

00:06:48Wednesday from 11 to 12 one hour per

00:06:51week the whole team is usually there and

00:06:52sometimes a few stakeholders as well the

00:06:55agenda varies a bit but sometimes it

00:06:56focuses on estimation sometimes on

00:06:58splitting stories and sometimes on

00:07:00writing acceptance criteria for a story

00:07:02etc so I hope you’re noticing the theme

00:07:05here communication product ownership is

00:07:07really all about communication when I

00:07:09ask experience product owners what it

00:07:10takes to succeed they usually emphasize

00:07:12passion and communication so it’s no

00:07:15coincidence that the first principle of

00:07:17an agile manifesto is individuals and

00:07:19interactions over processes and tools so

00:07:22the product owners job is not to

00:07:24spoon-feed the team with stories that’s

00:07:27boring and ineffective Pat instead makes

00:07:30sure everybody understands the vision as

00:07:32a team is in direct contact with

00:07:33stakeholders and that there is a short

00:07:35feedback loop in terms of frequent

00:07:37deliveries to real users that way the

00:07:39team learns and can make daily trade-off

00:07:41decisions on their own so Pat can focus

00:07:42on the big picture let’s take a look at

00:07:45a few of the trade-offs that need to be

00:07:46made by Pat and the team first of all

00:07:48there’s a trade-off between different

00:07:49types of value early on in a project

00:07:52uncertainty and risk is our enemy

00:07:54there’s business risk are we building

00:07:56the right thing there’s social risk can

00:07:59these people build it and there’s

00:08:01technical risk will it work on the

00:08:02platform where you want to run it on

00:08:04will it scale and there’s cost and

00:08:06schedule risk can we finish the product

00:08:08and a reasonable amount of time for a

00:08:10reasonable amount of money knowledge can

00:08:13be seen as the opposite of risk

00:08:15so when uncertainty is high our focus is

00:08:17knowledge acquisition we focus on things

00:08:19like a user interface prototypes and

00:08:21technical spikes or experiments maybe

00:08:23not too exciting for their customers but

00:08:25still valuable because we are reducing

00:08:27risk from a customer value perspective

00:08:29the curve looks like this in the

00:08:31beginning as uncertainty is reduced we

00:08:34gradually focus more and more on

00:08:36customer value we know what we’re going

00:08:38to build at how so just do it and by

00:08:40doing the highest value stores first we

00:08:42get this nice steep value curve and then

00:08:45gradually the value curve starts

00:08:46flattening out we’ve built the most

00:08:48important stuff and now we’re just

00:08:49adding the bonus features the toppings

00:08:51and ice cream

00:08:52this is a nice place to be because at

00:08:54any point Pat and the team may decide to

00:08:56trim the tail to cut right here and move

00:08:59on to another more important project or

00:09:01maybe start a whole new feature area

00:09:03within the same product that is business

00:09:05agility so when I talked about value

00:09:07here I actually mean knowledge value

00:09:10plus customer value and we need to

00:09:12continuously find a trade-off between

00:09:13these two another trade-off is

00:09:17short-term versus long-term thinking

00:09:19what should we build next should we do

00:09:22that

00:09:22urgent bug fix or build that awesome new

00:09:24feature that will blow the users away or

00:09:27do that difficult platform upgrade that

00:09:29will enable faster development in the

00:09:30future sometime we need to continuously

00:09:32balance between reactive work and

00:09:34proactive work or firefighting and fire

00:09:36prevention and this relates to another

00:09:38trade-off should we focus on building

00:09:40the right thing or building the thing

00:09:42right or perhaps building it fast

00:09:45ideally we want all three but it’s hard

00:09:48to find the balance suppose we are here

00:09:50trying to build the perfect product with

00:09:53the perfect architecture if we spend too

00:09:55much time trying to get it perfect we

00:09:56may miss the market window or run into

00:09:58cashflow problems or suppose we are here

00:10:00rushing to turn a prototype into a

00:10:02usable product great for the short term

00:10:05perhaps but in the long term we might be

00:10:06drowning in technical debt that our

00:10:08velocity will approach a zero or suppose

00:10:10we are here building in a beautiful

00:10:12cathedral in record time except that the

00:10:14users didn’t need a cathedral they

00:10:15needed a cameraman

00:10:16so there’s a healthy tension here

00:10:18between the scrum rules product owners

00:10:20tend to focus on building the right

00:10:21thing development teams tend to focus on

00:10:24building the thing right and scrum

00:10:26masters or agile coaches tend to focus

00:10:28on shortening the feedback loop speed is

00:10:30actually worth emphasizing because a

00:10:32short feedback loop will accelerate

00:10:34learning so you’ll more quickly learn

00:10:35what the right thing is and how to build

00:10:37it right however all three perspectives

00:10:39are important so keep trying to find the

00:10:41balance finally there is a trade-off

00:10:43between new product development and old

00:10:45product improvement product backlog is

00:10:48actually a slightly confusing term

00:10:49because it implies that there is only

00:10:51one product and project is a confusing

00:10:53term – because it implies that product

00:10:55development ends a product is never

00:10:57really finished

00:10:57there’s always maintenance and

00:10:58improvements to be done all the way

00:11:00until it product reaches end of life and

00:11:02is shut down so when a team starts

00:11:04developing a new product

00:11:05happens to their last one handing off a

00:11:08product from one team to another is

00:11:09expensive a risky so a more common

00:11:11scenario is that the team continues

00:11:13maintaining the old product while

00:11:15developing the new one so it’s not

00:11:16really a product backlog anymore it’s

00:11:18more like a team backlog a list of stuff

00:11:20that the product order wants this team

00:11:22to build and it can be a mix of stuff

00:11:24from different products and the product

00:11:26owner needs to continuously make

00:11:27trade-offs between these once in a while

00:11:30a stakeholder will call Pat and say hey

00:11:32when will my stuff be done or how much

00:11:34of my stuff will be done by Christmas as

00:11:36product owner Pat is responsible for

00:11:38expectations management or more

00:11:40importantly realistic expectations

00:11:42management and that means no lying I

00:11:44know it’s tough but who said agile is

00:11:46easy it’s not really that hard to make a

00:11:49forecast as long as it doesn’t have to

00:11:50be exact if you measure the velocity of

00:11:52your team or the combined velocity of

00:11:54all your teams you can draw a story burn

00:11:56up chart like this this chart shows the

00:11:59cumulative number of stories delivered

00:12:01over time or story points if you prefer

00:12:03note the difference this curve shows

00:12:06output that curve shows outcome that’s

00:12:10the output and that’s the outcome that

00:12:12we hope it will achieve our goal is not

00:12:14to produce as much output as possible

00:12:16our goal is to reach the desired outcome

00:12:19happy stakeholders using the least

00:12:21possible output less is more now look at

00:12:25the bernam chart and you can draw an

00:12:27optimistic and pessimistic trendline you

00:12:30can do it using fancy statistics voodoo

00:12:32or you can just draw visually and the

00:12:34gap between these lines is of course

00:12:35related to how wavy and unpredictable

00:12:37your velocity is luckily that tends to

00:12:39stabilize over time so our cone of

00:12:41uncertainty should get tighter and

00:12:43tighter okay so back to expectations

00:12:45management suppose the stakeholders ask

00:12:47Pat when will all of this stuff be done

00:12:49when will we be here that’s a fixed

00:12:52scope variable time question so Pat uses

00:12:55the two trend lines to answer most

00:12:57likely sometime between April and

00:12:59mid-may suppose the stakeholders ask Pat

00:13:02how much will be done by Christmas

00:13:04that’s a fixed time variable scope

00:13:06question the trend lies tell us I will

00:13:09most likely finish all of these by

00:13:12Christmas some of those and none of

00:13:14those and finally suppose the

00:13:17stakeholders say can we get the

00:13:19these features by Christmas now that’s a

00:13:22fixed time fixed scope question looking

00:13:25at trend lines Pat says nope sorry it

00:13:28can happen

00:13:29followed by here’s how much we can get

00:13:31done by Christmas or here’s how much

00:13:34more time we would need to get

00:13:35everything done it’s generally better to

00:13:37reduce scope that they extend time

00:13:39because if we reduce scope first we

00:13:42still have the option to extend the time

00:13:44later and add the rest of the stories

00:13:45vice versa doesn’t work because darn it

00:13:48we can’t turn the clock backwards no

00:13:50time it’s rather annoying that way isn’t

00:13:51it so Pat puts it this way we could

00:13:54deliver something here and the rest

00:13:56later or we could deliver nothing here

00:13:58and the rest later

00:13:59which do you prefer these calculations

00:14:02are pretty simple to do so Pat updates

00:14:04the forecast every week the important

00:14:06thing here is that we are using real

00:14:08data to make the forecasts and then we

00:14:10are being honest about uncertainty I

00:14:11said no line right so this is a very

00:14:14honest way of communicating with

00:14:15stakeholders and they usually appreciate

00:14:17that a lot if your organization doesn’t

00:14:19like truth and honesty it probably won’t

00:14:21like agile now a word of warning if the

00:14:24team is accumulating technical debt if

00:14:26they’re not writing tests and not

00:14:27continuously improving the architecture

00:14:29then they will get slower and slower

00:14:31over time and the story burnup curve

00:14:33will gradually flatten out that makes

00:14:34forecasting almost impossible for Pat so

00:14:37the team is responsible for maintaining

00:14:38a sustainable pace and Pat avoids

00:14:41pressuring them into taking shortcuts ok

00:14:44what if we have a larger project with

00:14:45multiple teams and we have several

00:14:48product owners each with their old

00:14:50backlog for a different part of the

00:14:51product overall the model is really the

00:14:54same we still need capacity management

00:14:56we still need stakeholder communication

00:14:59we still need product owners who can say

00:15:01no we still need backlog grooming we

00:15:03still need a short feedback loop etc

00:15:05velocity is really the sum of all output

00:15:07so that can be used for forecasting or

00:15:09make a separate forecast for each team

00:15:12if that makes more sense in a multiple

00:15:14team scenario however the product owners

00:15:15have an important additional

00:15:17responsibility to talk to each other we

00:15:19should organize the teens and backlogs

00:15:21to minimize dependencies but there will

00:15:22always be some dependencies that we just

00:15:24can’t get rid of so there needs to be

00:15:26some kind of sync between the product

00:15:27owners starts so that they build things

00:15:29in a sensible

00:15:30and avoid sub optimizing in large

00:15:32projects it’s usually calls for some

00:15:34kind of chief product owner role to keep

00:15:36the product owners synchronized okay

00:15:38that’s it

00:15:39ads on product ownership in a nutshell

00:15:40hope this was useful to you