Product Owner in 10 minutes


Hi my name is harshal lonare. And today I am going to talk about Agile Product Ownership

Let’s start with Agile software development from the perspective of the product owner.  Here’s Pat, she is a product owner.  She has a product vision that she is really passionate about. She doesn’t know the details of what her product is going to do but she knows why we are building the product and what problem it is going to solve and for whom.  She talks about it all the time.  Here is 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 stakeholders’ needs and Pat’s ideas are expressed as user stories here.  For example, if this was a train ticket booking system people need to be able to search for a journey ticket, 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 actually build the 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 as two, 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 them, try to do everything they ask for?  We will get overflow.  Suppose the team starts working about 10 new stories per? If the input is 10 and the output is 4 to 6 the team will get overloaded and that would 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 is 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.  It just doesn’t work. It just makes things worst.

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 to six features shall we build this week?  And the product owner’s job is to figure out, out of all possible stories in the universe, which four to six stories shall we deliver next. The KANBAN way is to limit work in progress or limit WIP, W I P.  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 new 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 will be able to work 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 the product backlog.  The queue needs to be managed. Suppose stakeholders keep asking for 10 new stories every week and the teams deliver 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 the team delivers is something that somebody asks for six months ago, and how Agile is that?  So, there is really 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 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’ve used and I bet you can think of at least one really simple feature that is very important, that’s used 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 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, wait a second, how does she knows the value of the story and how does she know the size? Well, here’s the bad news, she doesn’t, it is 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 am pretty sure that the apple weighs at least five times as much and that the strawberry, but Strawberry tastes better, to me at least, and that’s all Pat needs to know in order to prioritize the backlog.  It is 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 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 breakdown in a just-in-time fashion, we can take advantage of our latest insights about the product and user 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: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 are 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 the 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 is a trade-off between different types of value. Early on in a project, uncertainty and risk is our enemy.  There is business risk, are we building the right thing; there is social risk, can these people build it; there is technical risk, will it work on the platform where we  want to run it on; will it scale; and there is costs 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 a user interface prototypes and technical spikes or experiments.  Maybe not too exciting for their customers but still valuable because we are reducing risks.  

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 are 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 are 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 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 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 might be drowning in technical debt that our velocity will approach a zero.

Or suppose we are here building a beautiful park in record time, except that the users didn’t needed a park they needed a community hall.  So, there is 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 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?

The handling over of a product from one team to another is expensive and risky so a more common scenario is that the team continues maintaining their 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 his 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.  

So here is everything I can think of what product owner does. If you are using one of the techniques I mentiones before


If you are going to use any of them please let me know which one you like the most

Or which one makes more sense.

If you have any questions or if you want to share something with your own experiance please put your words in comment section.

I will speak to you soon!

Happy Producing Products 😛



Please enter your comment!
Please enter your name here