This video explains Agile Product Management, focusing on the role of a Product Owner named Pat. It covers how Pat handles user ideas, works with a development team, and manages the product backlog. The video also discusses important trade-offs in product development, such as balancing risk and customer value, and how Product Owners make realistic forecasts to manage stakeholder expectations.
Key Takeaways
1
The Product Owner has a product vision, knows why the product is being built, what problem it solves, and for whom.
2
Stakeholders are people affected by the system being developed, and their needs, along with the Product Owner's ideas, are expressed as user stories.
3
Agile development teams release early and often, typically delivering 4-6 stories per week, and invest in automated testing to maintain this pace.
4
To prevent overload from too many stakeholder requests, Agile methods like 'Yesterday's Weather' (Scrum/XP) and limiting 'Work In Progress' (Kanban) are used.
5
The most important job of the Product Owner is to decide what NOT to build and manage the product backlog, which is a queue of desired features.
6
Product Owners prioritize stories by considering both their value and size, even though these are often relative guesses and improve with experience and feedback.
7
Backlog grooming, which involves estimating, prioritizing, and splitting stories, is a continuous workshop done collaboratively with the team and sometimes stakeholders.
8
Effective product ownership is primarily about communication, making sure the team understands the vision and has direct contact with stakeholders for short feedback loops.
9
Product Owners and teams must balance various trade-offs, including knowledge acquisition vs. customer value, short-term vs. long-term goals, and building the right thing vs. building the thing right vs. building it fast.
10
Product Owners are responsible for realistic expectations management with stakeholders, using tools like story burn-up charts with optimistic and pessimistic trend lines to forecast completion dates or scope.
No matching segments found
0:05
Let's talk about Agile Software development from the perspective of the Product Owner
0:09
Here's Pat, she is a Product Owner. She has a product vision that she is really passionate about
0:15
She doesn't know the details of what our product is going to do, but she knows why we are building the product
0:20
What problem it's gonna solve, and for who
0:22
She talks about all the time. Here are the stakeholders
0:25
They are the people who are going to use and support or in any way be affected by the system being developed.
0:30
Pat's vision is that these people here will love our system and use it all the time and tell their friends about it.
0:35
The stakeholders needs and Pat's ideas are expressed as user stories, here.
0:39
For example if this is was flight booking system people need to be able to search for a
flight, and maybe that would be one user story
0:46
Both Pat and the stakeholders
have lots of ideas so Pat helps turn these into concrete user stories
0:51
Now, somebody has actually to build the system. So here they are.
0:54
a small, co-located, cross-functional self-organizing development team
0:58
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.
1:05
In this case, they usually release 4-6 stories per week,
1:09
So that is their capacity
1:10
Capacity is easy to measure. Just count the number of stories released per week
1:14
Some stories are big, so they can count as two. Some are small and count as a half
1:19
but on all, that adds up to about four six stories per week
1:22
Some people call this story points but I'm just gonna call them stories per week.
1:26
In order to maintain this pace and not get bogged down by manual regression testing,
1:30
the team invests heavily in automated testing and continuous integration,
1:34
so every story has at least one
automated acceptance test at feature level
1:37
and most of the code has automated unit tests.
1:40
The problem is, here are bunch of stakeholders asking for all kinds of stuff
1:44
and they sure aren’t going to be limited to 4-6 ideas per week.
1:48
They have LOTS of ideas and LOTS of wishes.
1:50
And every time we deliver something to them, they will get even more ideas and ask for even more stuff.
1:55
So what happens if we try to please them, try to do everything they ask for ?
1:59
will get overflow! Suppose the team starts working at 10 user stories per week.
2:03
If the input is 10 and the output is 4 to 6, the team will get overloaded
2:08
That will cause multitasking, demotivation and all kinds of bad stuff, and ultimately a lower output and lower quality
2:14
It's a lose-lose proposition. It´s kind like trying to shove more paper into a printer to make it print faster,
2:20
or shoving more cars onto an already crammed highway system.
2:23
it just doesn't work. It just makes things worse.
2:25
So, what do we do about this?
2:27
The Scrum and XP way of avoiding this problem is called "Yesterday's Weather"
2:32
The team says: "well, the past few weeks we've finished 4 to 6 features per week
2:37
so, which 4 to 6 features shall we build this week?
2:40
And the product owner job is to figure out of all possible stories in the whole universe
2:45
which 4 to 6 stories shall we deliver next.
2:48
The Kanban way is to limit Work In Progress or limit WIP
2:53
Suppose the team decides that 5 is a optimum number of stories to be worked out simultaneously
2:58
They've learned that is just enough to keep everybody busy without causing an overload
3:02
so they decided that 5 is their wip limit
3:05
whenever they finish one story
3:06
they will accept one user story
3:08
thereby making sure that they never break the limit of five ongoing stories
3:12
both of these approach work fine
3:13
in the sense that the team
3:15
will have just enough work to do and they'll be working fast and affectively
3:18
a side effect though is that there will be a queue forming in front of the team
3:22
and that queue in Scrum is called the Product Backlog
3:25
the queue needs to be managed
3:26
suppose stakeholders keep asking for ten user stories every week
3:30
and the team deliver four to six stories every week
3:33
that means the queue will just get longer and longer
3:36
so, before you know it, you have six month long of wish list in the backlog, and growing
3:40
that means that on average, every story that team deliver is something that somebody asked for six months ago
3:45
how agile is that?
3:47
so there's really only one way to stop the queue from getting out of control
3:50
that word is "NO"
3:52
it is the most important word for Product Owner and Pat practices it
3:56
every day in front of the mirror
3:57
saying yes to a new feature request is easy
4:00
especially if it only means adding it to an ever growing backlog
4:04
the most important job of the product owner is decide what NOT to build
4:07
and taking the consequences of that decision
4:10
and that's why it's hard, of course
4:11
the Product Owner decides what goes in and what goes out
4:14
the Product Owner also decides the sequencing
4:16
what to build now, what to build later
4:19
and how long does this list actually need to be
4:21
that's a hard job so Pat doesn't do it alone
4:24
she does it in collaboration with the team and the stakeholders
4:27
to be able to prioritize the Product Owner must have some idea of the value
4:30
of each story as well as the size. Some stores are critically important others are just bonus features
4:36
Some stories take just a few hours to build and others take months
4:39
Now guess what the correlation is between story value and story size. That's right! None!
4:45
bigger doesn't mean better
4:46
Think any system that you used and I bet you can think of at least one really simple feature that is very important, that you use every day
4:53
and I bet you can think of at least one huge complicated feature that is totally unimportant
4:58
value and size is what helps Pat prioritize intelligently
5:02
like here, these stories are roughly the same size but a different value
5:06
so build this one first
5:07
and over here these two stories have roughly the same value
5:11
but different size
5:12
so build this one first, and so on
5:15
ok that's sound easy enough
5:16
but wait a second
5:17
how does she know the value of the story
5:19
and how does she know the size?
5:21
well here's the bad news, she doesn't
5:23
it's a guessing game
5:24
and it's a game that everyone is involved in
5:26
Pat continuously talk to stakeholders to find out what they value
5:30
and she continuously talk to the team to find out what they think is big or small
5:34
in terms of implementation effort
5:36
these are relative guesses, not absolute numbers
5:39
i don't know what this apple weighs or that strawberry
5:42
but i'm pretty sure that the apple weighs at least five times as much and that the strawberry taste better
5:47
to me at least. And that's all Pat needs to know in order to prioritize the backlog
5:51
pretty cool that way
5:52
At the beginning of a new project
5:54
our guesses well inevitably suck
5:56
but that's ok, the biggest value is really in the conversations rather than the actual numbers
6:01
and every time the team delivers something to real users
6:04
we learn something
6:05
and get better at guessing both value and size
6:07
that way we continuously prioritize and estimate
6:10
Trying to get it all right from the beginning is pretty dumb because that's when we know the least
6:14
so the feedback loop is your friend
6:16
Prioritization is not enough though
6:19
in order to deliver early and often
6:20
you need to break stories down into bite sized pieces
6:23
preferably just a few days of work per story
6:26
we want this nice funnel shape
6:28
with small clear stories at the front
6:30
and more vague stories at the back
6:32
by doing this breakdown in a just-in-time fashion
6:34
we can take advantage of our latest insights about the product and user needs
6:38
all the stuff I'm talking about, estimating the value and size of stories, prioritizing, splitting
6:44
all that it is usually called "backlog grooming"
6:47
Pat runs a Backlog Grooming workshop every Wednesday from eleven to twelve
6:51
one hour per week, the whole team is usually there
6:53
and sometimes a few stakeholders as well
6:55
the agenda varies a bit but sometimes that focuses on estimation, sometimes on splitting stories
7:00
sometimes on writing acceptance criteria for a story, etc
7:04
so i hope you're noticing the theme here: communication
7:07
product ownership is really all about communication
7:09
when I ask experienced product owners what it takes to succeed
7:12
They usually emphasize passion and communication
7:15
so it's no coincidence that the first principle of the agile manifesto is
7:19
individuals and interactions over processes and tools
7:22
so the Product Owner's job is not to spoon feed team with stories, that's boring and ineffective
7:29
Pat instead make sure everybody understands the Vision
7:32
that the team is in direct contact with stakeholders
7:35
and that there is short feedback loop in terms of frequent deliveries to real users
7:39
that way team learns and can make daily trade off decisions on their own, so Pat can focus on the big picture
7:45
let's take a look at a few of the trade-offs that need to be made by Pat and the Team
7:48
first of all there's a tradeoff between different types of value
7:51
early on on the project uncertainty and risk is our enemy, there's business risk
7:56
are we building the right thing
7:58
there're social risk, can these people build it, and there's technical risk
8:02
will it work on the platform that we want to run it on, will it scale
8:06
and there's cost and schedule risk
8:08
can we finish the product in a reasonable amount of time
8:10
for a reasonable amount of money
8:13
knowledge can be seen as the opposite of risk
8:15
so when uncertainty is high our focus is knowledge acquisition
8:19
we focus on things like user interface prototypes or technical spikes or experiments
8:24
maybe not too exciting for the customers
8:25
but still valuable because we are reducing risk
8:28
from a customer value perspective
8:30
the curve looks like this, in the beginning
8:33
as uncertainty is reduced we gradually focus more and more on customer value
8:38
we know what we're going to build and how, so just do it
8:41
and by doing the highest values stories first we get this nice steep value curve
8:45
and then gradually the value curve starts flattening out
8:48
we've built the most important stuff, and now we're just adding the bonus features
8:51
the toppings on the ice cream
8:53
this is a nice place to be because any point
8:56
Pat and the team may decide to trim the tail
8:58
cut right here
8:59
and move on to another more important project
9:02
or maybe start a whole new feature area within the same product, that is business agility
9:07
so when i talk about value here I actually mean
9:09
knowledge value + customer value
9:12
and we need to continuously
9:13
find the trade-off between these two
9:16
another trade-off is short-term versus long-term thinking
9:20
what should we build next
9:22
should we do that urgent bug fix
9:24
or build that awesome new feature that will blow the users away
9:27
or do that difficult platform upgrade
9:29
that will enable faster development in the future some time
9:32
we need to continuously balance between reactive work and proactive work
9:35
or fire fighting and fire prevention
9:38
and this relates another trade off
9:40
should we focus on building the right thing
9:42
or building the thing right
9:44
or perhaps building it fast
9:46
ideally want all three
9:48
but it's hard to find the balance
9:50
suppose we are here
9:52
try to build the perfect product
9:53
with the perfect architecture
9:55
if we spend too much time trying to get it perfect we may miss the market window or run into cash flow problems
10:00
or suppose we're here, rushing to turn a prototype into a useful product
10:04
great for the short term perhaps, but in the long term we might be drowning in technical death
10:08
and our velocity will approach to zero
10:10
or suppose we are here
10:12
building a beautiful cathedral in record time
10:14
except the users didn't need a cathedral, they need a camper van
10:17
so there's a healthy tension here between the Scrum roles
10:20
Product Owner tend to focus on building the right thing
10:23
Development Teams tend to focus on building the thing right
10:26
and Scrum Master or Agile Coaches tend to focus on shortening the feedback loop
10:30
speed is actually worth emphasizing because a short feedback loop will accelerate learning
10:35
so you'll more quickly learn what the right thing is and how to build it right
10:39
however all three perspectives are important, so
10:41
keep trying to find the balance
10:43
finally there is a trade-off between new product development and old product improvement
10:47
product backlog is actually a slightly confusing term because it implies that there's only one product
10:52
and project is a confusing term too because it implies that product development ends
10:56
the product is never really finished
10:58
there's always maintenance and improvements to be done
11:00
until to a product reaches end of life and shut down
11:03
so when a team starts developing a new product
11:06
what happens to their last one?
11:07
handing off a product from one team to another is expensive and risky
11:11
so a more common scenario is that the team continues maintaining the old product
11:15
while developing the new one
11:17
so it's not really a product backlog anymore, it's more like a team backlog
11:20
a list of stuff that the Product Owner wants this team to build
11:23
and it can be a mix of stuff from different products
11:26
and the Product Owner needs to continuously make tradeoffs between these
11:30
once in a while a stakeholder will call Pat and say "hey when will my stuff be done?"
11:34
or, how much of my stuff will be done by Christmas
11:36
as Product Owner, Pat is responsible for expectations management
11:40
or more importantly, realistic expectations management
11:43
and that means no lying
11:45
I know, it's tough, but who said Agile was easy?
11:48
it's not really that hard to make a forecast as long as it doesn't have to be exact
11:52
if you measure the velocity of your team
11:54
or the combined velocity of all your teams
11:56
you could draw a story burn up chart, like this
11:58
this chart shows the cumulative number of stories delivered over time, or story points if you prefer
12:05
note the difference, this curve shows output, that curve shows outcome
12:10
that's the output and that's the outcome that we hope it will achieve
12:14
our goal is not to produce as much output as possible
12:17
our goal is to reach the desired outcome
12:20
happy stakeholders
12:21
using the lest possible output
12:23
less is more
12:25
now look at the burn up chart
12:26
and you can draw an optimistic and pessimistic trend line
12:30
you can do it using fancy statistic voodoo or you can just draw it visually
12:34
and the gap between these lines is of course related to how wavy and unpredictable your velocity is
12:39
luckily that tends to stabilize over time
12:41
so our cone of uncertainty should get tighter and tighter
12:44
okay, so back to expectations management. Suppose the stakeholders ask Pat "when will all of these stuff be done?"
12:50
"when will we be here?"
12:51
that's a fix scope / variable time question
12:54
so Pat uses the two trend lines to answer
12:58
most likely sometime between April and mid May
13:01
suppose stakeholder ask Pat "how much will be done by Christmas?"
13:05
that's a fixed time / variable scope question
13:08
the trend lines tell us that we'll most likely finished all of these, by christmas
13:13
some of those and none of those
13:16
and finally suppose stakeholders say
13:18
"can we get these features by christmas?"
13:22
now that's a fixed time / fixed scope question
13:25
looking at trend lines Pat says "nope, sorry, ain't gonna happen"
13:30
followed by, "here's how much we can get done by christmas"
13:33
or "here's how much more time we would need to get everything done"
13:37
it's generally better to reduce scope than to extend time
13:40
because if we reduce scope first
13:42
we still have the option to extend the time later, and add the rest of the stories
13:47
vice versa doesn't work because, darnit, we can't turn the clock backwards
13:50
you know, time is rather annoying that way, isn't it? so Pat puts it this way
13:54
we could deliver something here and the rest later
13:58
or we could deliver nothing here and the rest later
14:00
which do you prefer?
14:02
these calculations are pretty simple to do so Pat updates a forecast every week
14:06
the important thing here is that we are using real data to make the forecast
14:10
and that we're been honest about uncertainty
14:12
I said no lying, right?
14:14
so this is a very honest way of communicating with stakeholders
14:16
and they usually appreciate it that a lot
14:18
if your organization doesn't like truth and honesty it probably won't like Agile
14:23
now a word of warning
14:24
if the team is accumulating technical debt
14:26
if they're not writing tests and not continuously improving the architecture
14:30
then they will get slower and slower overtime
14:32
and the story burn up curve will gradually flatten out and that makes forecasting almost impossible for Pat
14:37
so the team is responsible for maintaining a sustainable pace
14:40
and Pat avoids pressuring them into taking shortcuts
14:43
okay what if we have a larger project, with multiple teams
14:47
and we have several Product Owners, each with their own backlog for a different part of the product
14:53
overall the model is really the same
14:55
we still need capacity management
14:58
we still need stakeholder communication
15:00
we still need product owners who can say NO, we still need backlog grooming
15:04
we still need a short feedback loop etc
15:06
velocity is really the sum of all output
15:09
so that can be used for forecasting
15:10
or make a separate forecast for each team, if that makes more sense
15:14
in a multiple team scenario, however, the product owners have an important additional responsibility
15:18
to talk to each other
15:20
we should organize Teams and Backlogs to minimize dependencies
15:23
but there will always be some dependencies that we just can't get rid of
15:26
so there needs to be some kind of sync between Product Owners so they build things in a sensible order and avoid sub-optimizing
15:32
in large projects this usually calls for some kind of Chief Product Owner role
15:36
to keep the Product Owners synchronized
15:38
okay that's it, Agile Product Ownership in a Nutshell, I hope this was useful to you.
15:47
© Henrik Kniberg 2012
Subtitles by Paolo Sammicheli
Start a conversation
Ask anything about Product Management for Beginners
100/100 free messages remaining
AI responses may be inaccurate. Verify important information.
Product Management for Beginners
Product School