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
”