The perceived need for scaling could follow as a reaction to the scope of the project at hand. It is quite common within projects to try and do as much as possible parallel development of different semi-detached functional areas of the product. This comes quite close to how I used to manage projects in the past. Whatever in the same timebox could be done in parallel, should. I was very efficiency driven back then, but also taught and stimulated to think this way.
Within this paradigm it would be preferable, that the PO has some sort of party around him helping to create the user stories he would be in charge of. Creating big teams gives us more capacity to do more work in our timebox. Larger teams and more work create the need for more coordination, because of limited span of control, thus creating the need to scale.

Also, I think we are still very much driven by the paradigm of the chain of command. It is simply comfortable when there is someone who can make the tough decisions for us and mediate between us whenever conflicting interests arise. The need for extra coordination between and over PO’s in the same context thus fits very naturally with our needs in a growing project context.
Come to think of it, maybe it is no coincidence that the person designated CPO is more times than not the first PO that was on the project. If we look deep within ourselves wouldn’t every PO actually want their first project steps to be so successful, that the extra means are granted to grow the team and consequently rise above to lead the way as CPO? And should we be that CPO, would we ever fully trust another colleague with the work we carefully prepared and poured our blood sweat and tears into? It would be great if we could somehow keep some sort of supervision on the others. Make sure the projects success and our hard work isn’t killed off in the next sprint or two. Scaling with a CPO construction would provide means to fulfill these needs.

Of course the above reasons to scale could be valid, but there are also downsides to them.

Although doing parallel work may sound efficient, maybe validation with your customers shows that the product increment doesn’t fulfill their needs as thought up in the first place. Since you have done a lot of parallel work, the risk of waste is also greater. Should you need to radically pivot your product in another direction, it will be much harder due to the already large scale of your operation.
I thus think that scaling towards having different teams work on the same backlog potentially inhibits us from maximizing validated business value, as you are pulling forward less important features from the backlog, before actually validating and thereby knowing whether you have actually delivered value with your top items. From this angle, it would be wise considering not to scale.

When scaling from success, we run the risk of slipping into a power monger mode and form a team beneath us to gain status and control instead of branching out sideways.
When this happens we are not working towards joint company stakeholdership any more, but we trying to build our own ivory towers. When the CPO leading the PO’s claims decisive power in certain areas, I believe you would not be creating the right entrepreneurial environment in which decisions are based on arguments and value for the customer and company. Maybe, as a PO, if you already know you need a decision from the CPO, you are inclined to use other influencing methods rather than comparable and less subjective measures than for example business cases, jeopardizing the quality of decision making and therefore the success of the product.

During my study, I was taught “there is no one best way to organize”. I think of this line as a universal truth, that in my opinion also applies to scaling the PO role. I therefor think that form is less important than the route taking you there. Knowing that there are risks involved in scaling and consciously dealing with them helps you along this route to find a form that works for you.

(*)Scaling is also common in productline contexts (for instance a CPO over a group of PO’s managing a product family) or within business units where you would have various strategic themes that the CPO would like to have implemented over the same time period.

Getting a view on innovation
When a company fills in a portfolio tool like a Boston Consulting Group (BCG) matrix, it gets a view on its product market combination (PMC) portfolio. You can tell a lot about the company and its business from how a BCG matrix (*) develops over time. One of the most fun things in my eyes is the amount of question marks turning into stars. A question mark being a PMC in a high growth, low share section (e.g.; doing something relatively new), a star being a PMC in a high growth, high share section (e.g.; being successful in doing new stuff).

The amount of question marks in the portfolio illustrates the amount of newly launched PMC’s on to target markets. When you also consider the amount of ideas not becoming question marks, and turn this into a ratio, you could get some idea on how innovative the company is. Add to his the amount of question marks turned into stars and you really get a sense of outward successful innovation. I distinguish outward and inward innovation, because I believe that experiencing a commercial hypothesis to be proved wrong is at least just as valuable as seeing it proved right.
This doesn’t mean that innovation can’t be applied in other quadrants, just that it might not be the smartest thing to do when for instance handling dogs. In many cases adding features to cash cow products can be a brilliant strategy. Take for example razors, where adding more razorblades, self-adjusting blades and other sleight handling improvements constantly extends the product lifecycle.

Innovation flavours
To get an idea of how scrum could accommodate for innovation, first we have to get an idea on the various sorts of innovation like “additive innovation” out there. In general there are four forms of innovation a company can venture into:

Incremental innovation: small improvements leading to slightly better results

Additive Innovation: adding product features, customization, new products in existing business lines

Complementary innovation: creating new offerings new in current business, but adjacent to current product lines

Radical innovation: doing completely new things, unknown to business and/or target markets.

Using agile to suit innovation
In the following section I will highlight a couple of alternative ways in which you could use agile and scrum mechanics to shape and facilitate these forms of innovation:

Incremental innovation:
1. Spend a retrospective or a section on this product improvement; try to get in one small improvement each sprint. Maybe this will ease the team into providing more input for the backlog.
2. Agree with the team that every sprint every individual team member comes up with at least one idea to improve the product in some way.

Additive innovation:
1. Create spikes in sprints to prototype new features, validate these with customers;
2. Hold demo like meetings with your target audience; ask them what they think about the product.

Complementary innovation
1. Keep key options open, have stories worked out in two variations and do validate these paths in spikes and demo meetings;
2. Invest time in finding the appropriate product owner for the job. Market and customer knowledge is important here as the company is going to serve adjacent and different markets than before;
3. Take care that the entire DMU is taken into account in the story map. Also look at internal impact of providing new services and products, for instance customer service needs.

Radical innovation
1. Make sure the innovation team is freed from all organizational gravity. Pull them away from status quo and peer paradigms;
2. Reserve time for existing teams to work on a free format project. This could be a once every month time box of a day for example. It can be whatever they would like, as log as results are made transparent. Let them the same social objects as in scrum (boards, graphs, backlogs);
3. Take care that you have means to measure relevant metrics early on. Every addition should increase sales, market share and other relevant metrics. Use retrospectives to find root causes and steer through story map;
4. Keep all options open, incorporate A/B tests, multi-variant tests, prototypes, feature polls and so on. Sprint goals are hypotheses you would like to see validated.

What I love about scrum, is that it so lightweight and adaptable. On the incremental- to radical innovation scale, there is no step in which scrum can’t be adapted to accommodate for innovation while remaining to move fast.

The above list is just a brain dump of what I quickly came up with. I am convinced that there are many more creative ways in which we could adapt agile and scrum practices towards innovation. Please view this blog as an open invite to share your thoughts on this subject.

PS: Merry Christmas and a very Happy New Year!

(*)A BCG matrix says nothing about profitability of the PMC, so market share in a growth market could be labeled as a vanity metric. The matrix also builds on the premise that you know a market to put question marks in. Sometimes however you don’t know what your market is going to be. Furthermore, the BCG matrix can be filled in numerous ways depending on how you define for example the market scope.

All these questions could and probably will play a role in the consumer
buying process of complex products and therefore ultimately decide whether product “a” is bought or competitor “b”. It’s not said all of these questions get asked and answered by the same person(a). Most buying decisions of complex nature are made by a so called decision making unit or DMU.

Decision Making Unit theory indicates a number of roles with regards to
buying decisions such as the:

- initiator : identifies problem/ need to solve;
- gatekeeper: regulates info for decision;
- influencer: influences decision;
- buyer: buys solution;
- decider: decides what product to buy;
- user: actual user of product;

We build storymaps based on pragmatic personas, which are primarily users. Selling our product however, as decision making theory shows us, may mean tactically taking into account the entire decision making unit, not only the users. I encounter a lot of releasable walking product skeletons, neither shippable nor marketable.
Too thin a walking skeleton, means releasable, but no one will buy it. Too fat a walking skeleton, means putting in too much and missing crucial market windows.

A sellable increment, which if possible is of course also a first release, means fleshing out your skeleton just a bit more making it more of a sellable Frankenstein than just a bag of bones.

A sellable increment or marketable feature set, in my opinion is your
kano threshold attributes + a well thought-out and implemented set of performance attributes, resulting in the product being a viable option in the customers consideration set of alternatives. Next to that, we need a good usp, or a unique set of these, positioning your product from all others. All of these product properties, or a specific set depending on your product marketing strategy, will need to be translated to DMU needs, to be able to hone the product for sales.

My advice would be to start thinking about the DMU and how this works for your product. Get marketing involved and see what they already know about the composition of the DMU. Create some peronas and try to involve them somehow in demos and future plans to get the feedback you need.

I encountered a lot of story-maps based on this principle in financial services lately. The “hello world”-first slice, or walking skeleton, comprised of nothing more than the bare minimum technical necessities to get a working chain environment end-to end. Later being fleshed out with additional functionality.

Most of the times this is the right thing to do, because in most cases there are dependencies with other systems and internal “suppliers”. The risk to see whether the system would work with these external systems later on in the project is too big to postpone, to when the features come up that possibly depend on these external pieces of the product puzzle.
Getting these dependencies out of the way, means seeing a working chain and having a better picture of how things work, mitigating the risk associated with delaying dependencies. For the external factors it means building the essentials and stubbing the rest, creating the barest technical walking skeleton possible, a working end-to-end chain.

Strangely some projects I saw with large amounts of external dependencies did see the value of this possibility, but still decided to go for a more functional first slice of the product, leaving them struggling for months before delivering end-to-end working software. How could this be?

The issue here was, that at the start of the project people all saw the dependencies but none of them could be addressed effectively. The major issue was the fact that all but one external supplier to the project were actually other internal departments that couldn’t/ wouldn’t lend resources and rather stick to their own release calendars (making them real old skool stakeholders by the way which is pretty evil). They also had a lot of problems getting their own environments from outside of the project, which didn’t help as well.

In the ideal world this project should not have started without the necessary support in place to complete the first ideal optimal technical slice in a couple of sprints. Which is actually not so different from when you create a regular walking skeleton come to think of it ☺. Remember to keep a technical walking skeleton an option when working in complex chain environment and or existing system environments. You might be amazed how fast you can get the first feedback, from customers and other stakesharers.

Should you have some interesting other slicing dimensions you would like to share, or you totally disagree with me, please leave a comment below! Many thanks in advance.

More focus on “the string of rights” generally brings a great deal of success but also a lot of stress to cope with. The stress comes from the fact, that if all capacity in our production system is focused on doing the “rights”, that those “rights” might not always be the “rights” you are responsible and accountable for right now.

Dealing with the stress means stakeholders have to change their attitudes from viewing themselves as stakekeeper to stakesharer. Stakesharers put more value on the overall company results than the stakes they hold (semi) individually. This as opposed to stakekeepers. To facilitate “stakesharership” means, we have to scan our organizational context to see what elements are not aligned with the concept and to improve on them (e.g.; communication structures for dealt portfolio management, job descriptions, budget-management processes, leadership styles etc.)

Your focus on the string of rights increases if there are less stakekeepers around, as Burm’s formula for joint company stakeholdership shows us:

If there are also mature teams with enough sense of responsibility and involvement to become staketakers, chances are your increased focus on value and joint company stakeholdership are just around the corner.

Say goodbye to traditional stakeholdership. If you want to create real ownership in your agile company and maximize focus on value delivery, embrace the concept of joint company stakeholdership today!

PS: If you fill in Burm’s formula for your company right now, how would you score?

In my previous blog post I presented the stages that a backlog item flows through before it gets to Ready. But those were the ideas behind it: in this blog post I’ll show how I’ve implemented them in practice. I’ll show you two interesting examples.

The basic Ready Kanban has three columns: New, Preparing and Ready (see the explanation in the previous post of the series). You can add the fourth “In Sprint” if you want to show what’s currently in the Sprint, but that’s only really needed if it’s not hanging close to the Scrum Board: otherwise the Scrum Board effectively functions as the In Sprint column. It’s good to have a visual cue in the Preparing column to show the limit on work in progress, like a fixed number of slots for user story cards.

Rob’s READY Kanban

This board was created by Rob Buster, one of the Product Owners at bol.com. As you can see his board has four columns since this board is hanging close to his desk, which is on a different floor from the team floor.

Some things to note on his board:

• he added a “Poker Ready” section, where he can collect a number of user stories that can be estimated in one go in a poker planning session. This is a very good idea and will probably end up on many Ready Kanbans. Even so, I specifically do not prescribe it in my generic format, since it’s up to the work dynamic between a Team and a PO if they want to do this one at a time or in batches.
• the pink hearts were added by a colleague in the same room who found the large brown paper ugly…
• Rob uses blue stickies to partition his Ready buffer into Sprints. Again a very good idea, since it clearly shows the currently expected set of user stories to be picked up in the next sprint. It also allows physical shuffling of user stories to fill up the Sprints to the team’s velocity.

The first Ready Kanban

This was the first Ready Kanban ever to be put up. I initially filled it with the top of the backlog that was in preparation: the top five in the “Preparing” state, and the next 10 in the “Top 10 New” state. Note that it’s hanging in its logical place: on the left side of the Scrum board, in line with the overall left-to-right flow of user stories.

This is that same board a few days later (I’ve fudged out the titles):

Many interesting things had happened here:

• The analysts, who were performing all the getting-to-Ready work, started showing up frequently in the team room. Just like a Scrum board does for a team, it became their rallying point to discuss coordination, status and progress.
• The New buffer started drying up. With the improving speed of the team, many items on the old “change requests” list were reevaluated and found to be outdated or obsolete. It clearly pointed at a need to get the dialog with the business up to speed to get their requests. I had not expected this to happen, I thought that this buffer would always be full. It turns out that there is a subtle effect going on here: putting something in New implies a subtle promotion, and this leads to a simple triage being done on the user story. You could say that it functions as a “bullshit filter” .
• The top card in the Preparing column was stuck there while the ones below it moved. It became clear that there was an impediment in getting that user story ready, and extra effort and focus went into resolving the decisions to be made by the business.
• The Ready buffer was not filling rapidly enough. The level of the Ready buffer is a really good way to show if the velocity of the PO in sync with that of the Team. It works so well in this regard that the team members saw that it would not really be that useful to keep pounding away at functionality if the work would dry up. So they started to help the PO role to get user stories Ready. Now that is what I call self-organization!

Conclusion

All in all, I am REALLY happy with the results I’ve seen when I applied this board. All of a sudden the PO’s have their information radiator, they can coordinate with others, stuck user stories are clearly visible, and now there is a basis for measuring the performance of the PO role. We can make a trend graph showing the level of the Ready Buffer (the PO’s version of the burndown…), we can measure average completion time of a user story (in line with Lean’s “takt time”), and the PO can bring some sanity back by limiting the work in progress in the Preparing state.

So please spread the word and make sure as many PO’s as possible know about the Ready Kanban: the PO role is by far the hardest of all roles in Scrum, and I know from experience that all help is welcome…

What’s up next? I hope I don’t take as long as last time, but I’ll show you how I implemented the Ready Kanban in JIRA. When you have a distributed PO role (or any distributed situation for that matter), you’ll need support by tooling to bridge the gap…

In a previous blog post I introduced the definition of READY, and I wanted to do another “context” blog post before starting on this one: on the difference between flowing (“kanban”) and iterating. However, I had much more to say on the subject than I expected, so the thing kept expanding… I’ll gather my thoughts and publish that one later. So for the purpose of this blog post just bear with me: I find that a Product Owner’s job is best done in a flow style. And since my dear ex-colleague Lars Vonk told me he was waiting for this post, I’ll just explain the how here. Lars, here you go…

Update: the third of the series is also done. See here.

Not all backlog items are equal. A backlog item starts out as a rough sketch – usually just the As a.. I want… So That… stanza – and needs to be fleshed out to the extent that it can be picked up by the team in a Sprint. Just like a team has a basic workflow getting stuff to Done, the same applies for the Product Owner role. Scrum does not have any specific support for a Product Owner: somehow the Product Backlog just “happens”. In this post I’ll try to fill that gap with respect to the process that a Product Owner can follow.

I’ll explain a partitioning of the backlog that maps onto a flow, the nature of those partitions and how you proceed through them to get enough stuff Ready for the team to pick up in the next Sprint.

Flow to READY

The overall flow of work through a Scrum team is that the Product Owner role picks up new stuff, gets it READY, and the Team role picks it up to get it to DONE. Note that I explicitly use the word “role” here: team members have a role to play in supporting the Product Owner role to get backlog items to READY.

Partitioning the backlog

A backlog can roughly be partitioned in four areas based on the overall flow:

1. items that are currently in the Sprint,
2. items that are Ready,
3. items that you’re preparing to Ready, and
4. the rest: new stuff.

Of course this is an idealized view of things. In practice the lines are blurred somewhat because the mapping of priority on the workflow steps is not always as clean as you’d like. New items might show up really high in priority, putting it in between the READY items. On the other hand this way of viewing the backlog could be used to enforce the prioritization: something that’s READY could by definition be prioritized higher than something that’s not.

From partitioning to flow

If we take these flow steps and put them side by side, we get the following:

The fact that I’ve used one color for “New” and “Ready”, and another for “Preparing” and “In Sprint” is not a coincidence: “New” and “Ready” are prioritized buffers, “Preparing” and “In Sprint” are Work-In-Progress. Let’s go through the flow step-by-step.

Prioritized buffer: New

Backlog items in the New state are the ones you haven’t started working on yet, at least not to the extent that you’re getting them to READY. Even so, in practice I’ve seen that it’s wise to perform a minimal triage on these items: if you have every mad idea on there, you’ll quickly be inundated in an avalanche of items. Stakeholders tend to say “I’ve got a thousand ideas!”, but many of them are just that: ideas. Only a small fraction are actually realistic or useful to implement. This initial triage should be kept simple, but it does put some discipline with stakeholders putting in their requirements. Don’t be too worried about stakeholders complaining, in general a stakeholder will appreciate knowing what they need to do to get their requirements in . To be put on the backlog as New, a stakeholder should provide the following:

• a story solely in terms of the business experience that describes what they experience and what they need without referring to how the product would support it
• user story stanza (As a.. I want… So that…)
• a (rough) valuation of benefit
• a rough indication of size (i.e. cost): small, medium, large. (Note that this is best guesstimated by a team member or the product owner after a chat with the stakeholder: they have more knowledge of the product)

The business urgency gives you a rough prioritization, which enables you to decide which items to pull in first.

Work-In-Progress: Preparing

This step is the big one as far as the Product Owner is concerned: it’s where the core Product Owner work gets done.

The Product Owner is the single point of contact for all stakeholders, and this is of course intentional. There needs to be a single focal point for all requirements and prioritization, otherwise it will fall back to the team role and the Product Owner role is all but useless. An unfortunate side effect for our poor Product Owner is that they constantly get bombarded with requirements and pressure from all stakeholders. The result is that a Product Owner is stretched thin trying to deal with it all. I’ve found that this is where the flow/kanban style really shines: explicitly limiting work in progress is one of the best tools to bringing some sanity in the Product Owner’s life.

The Product Owner pulls items into the Preparing step according to capacity. Just like a team pulls in work to capacity and does not change it until the Sprint is over, a Product Owner should pull in a number of items (I’ve seen two per person in the Product Owner role a lot, don’t know yet if that’s a general thing, though), work on them until they’re Ready, and only pull in new items when a “free slot” opens up in the preparing step.

The Product Owner does not need to (and in most cases can’t) provide all information, but is responsible for making sure that someone does, so that the backlog item will get to Ready. This means that a Product Owner will talk with stakeholders to ask them for more information, with the Team to provide an estimation of implementation complexity, and anybody else who is needed to provide clarity and information. This is quite a job, and in larger organizations it’s not unusual to see multiple people (often analists) supporting this role.

Because of the explicit step in the flow it is now possible to measure Product Owner performance. The equivalent of velocity in the flow style is cycle time: the average time needed to bring a backlog item from New to Ready. A backlog item that is stuck will be easier to recognize, since it will remain in the Preparing step longer than is usual. It also helps to plan Product Owner capacity. Comparing the cycle time with the a number of backlog items that is consumed per Sprint by the team helps to determine if the Product Owner is going fast enough to keep up.

A Product Owner’s speed is not measured in a backlog item’s story points but in number of backlog items because the amount of work for each item is roughly the same: every item needs its questions answered regardless of the size. Large backlog items may be more work, but in most cases they will have to be broken up into sizes that are manageable by the team. This translates into more backlog items for (originally) large ones, so large items are factored in this way.

When a backlog item is Ready it can be moved into the Ready buffer.

Prioritized buffer: The Ready Buffer

I have found it very useful to think of the list of Ready items as a buffer. A Product Owner’s productivity needs to be such that this buffer is full enough when the next Sprint starts. Tracking the size of the buffer (in story points, since now the capacity of the Team is the relevant one) is a very good way to see if the Product Owner is getting into trouble. You could use a burn-down chart, a burn-up chart, or simply a continuous trend line of buffer size, but I find it a great help that a Product Owner has access to the same type of trend information that is available to Teams when they use burn-down charts.

There are two levels of Ready: each backlog item needs to be Ready, but the backlog needs to be Ready as well, just before the next Sprint. Backlog-Ready means that the Ready buffer is full enough for an iterations’ worth of work, and some extra work as “spare change” in case of renegotiation, last minute decisions, insights or priority shifts. In practice going for 1.5 to 2 iterations’ worth is a good target. The reverse is also true: if the buffer is really full, more than two Sprints’ worth of Ready items, you’re likely wasting work since reality will change before you get round to the later items in the buffer (items become “unready”), forcing extra work. In that case you it’s better to increase the Team capacity or use the free time for some crystal ball gazing or market research .

Work-In-Progress: In Sprint

Of course this step is relatively easy to describe, this is where all the usual Scrum stuff enters the picture . As a Product Owner you’ll track which items are In Sprint, but your work is not entirely done. In an analogy of a quote on design: “a good design does not depend on one big decision, but on hundreds of little ones”, a Team will need you around to unblock them with decisions. During a Sprint a Team will come up with alternatives for details of the implementation. Often these alternatives have an impact on the end result: they might have an easy option but it will not be exactly what was asked, or a team might find a part of the implementation is harder to do than expected. In that case you need to be around to help them forward.

Summary

The backlog can be partitioned in four parts that you can connect with a flow. Since this blog post is getting long enough as it is I’ll write another one on how you support this process with a Kanban board and electronic tools.

Update: I’ve written the third post of the series: you can find it here

Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit…

Edit: the link to the second post in the series turns out to be buried too much at the bottom, so I’m adding it at the top: See Flow to Ready, Iterate to Done

The Definition of Ready

I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called “the dynamic model of Scrum”. The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I’ve got some good answers to these questions.

Here’s a picture from my Scrum course material to illustrate the concept…

What does the READY state do?

In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.

Defining READY

READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the “supplier” is the Team and the “client” is the Product Owner, it’s the other way around with the Definition of READY: the Team is the “client” and the Product Owner is the “supplier”. Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: “Ah, we get it”.

Even though you can put any precondition in the Definition of READY, the need for a good backlog overshadows all other considerations, so you’ll definitely need to address two items: readiness of User Stories, and readiness of the Backlog.

When is a User Story READY?

I have found that a User Story is ready when you have answered three questions: Why?, What? and How?, it has been estimated and it is small enough.

• Why?: What are the stakeholders trying to achieve? What are their goals? What is the business context? What is the Quantified Value?
• What?: What is the Outcome Vision? What is the end result of the user story?
• How?: What is the Implementation Strategy? What is the associated cost (story points)? Is the story small enough (story points vs. team velocity)?

Note that with answering these question I do not want to imply that you need a whole lot of documentation or artifacts. Again, it’s whatever the team says it needs. If the back of a napkin suffices, go for it. If the team needs more, provide that. Note that the detail level needed must be determined per user story. Some will be business as usual, and you may suffice with a simple “I want one of those, but this time in green”. Others could for instance be related to a new process in the Intensive Care ward of a hospital. You might just need a tad more there…

I use the term “implementation strategy” to further clarify the level of detail needed. Fully specifying the How? would lead you back to waterfall, but you can’t make a points estimation if the team does not have a rough idea of how they’ll tackle the user story. So you go as far with specifying the implementation as is needed for a points estimation. Note that this is a natural side effect of planning poker sessions, so the easiest is to capture the outcome of that discussion along with the estimation. And I really advise that you do it, I’ve seen too many cases where the team wonders why they gave that user story 5 points, just two days after the planning poker session…

In the end a User Story is READY if a team can implement it, and a Product Owner can prioritize it.

When is the Backlog READY?

The backlog is READY when about 1,5-2 Sprint’s worth of User Stories at the top of the backlog is READY, and those user stories are sufficiently small to allow good team flow.

And finally, follow this mantra

Don’t let anything that’s not READY into your Sprint, and let nothing escape that’s not DONE.

Okay, now you know how to define READY. In a next post I’ll tell how how to get there…

In the Lean Software Development method Scrum there are three roles: the Team, the Scrum Master and the Product Owner. In my experience the Product Owner role is by far the most confusing and hardest role to ‘get right’ and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I’ve talked to. I want to discuss the origins of the Product Owner role and my experience in how (not) to fill this role, especially in companies that don’t do product development.

The mythical Product Owner

I’ve seen many flavors of Product Owners and none of them really worked as they should have. Actually, rumor has it that good Product Owners actually don’t exist. Now that’s something we should be frank about if that’s true. If the Product Owner is a combination of responsibilities that doesn’t work in practice, we should find some alternative. First, I’ll explain my experience so far.

Definition of the role

Scrum is based on best practices, no one ‘invented’ Scrum by merely theorizing about how the world should work. People like Jeff Sutherland and Ken Schwaber have done projects in the past that were successful and one of the major reasons for their success was the presence of one person who represented all customer interests to the team (later called the Product Owner). Ken Schwaber describes the product owner as ‘one person [that] is responsible for maintaining and sustaining the content and priority of a single Product Backlog’ Jeff Sutherland is more elaborate and lists all responsibilities of the product owner in his online book ‘The Scrum Papers’. Among others he adds the responsibility ‘[...] for the profitability of the product (ROI)’. The direct combination of the ROI and the features of the product are what Product Ownership is all about.

Different flavors

Keeping in mind what the product owner should be according to Scrum, I want to explain the different flavors of Product Owners I’ve come across. Their flavor was mostly defined by the person taking on Product Ownership and their ‘regular’ job.

PO the Product Manager
In product development companies, such as famous Scrum companies like PatientKeeper and Planon, there is usually a role called Product Manager. A Product Manager can be the Product Owner without any issues because they are almost synonymous. Scrum gives the Product Manager a specific way of controlling his product by use of the Product Backlog. The only real issue that I’ve seen is that product managers tend to push down on the teams to deliver, which is considered a bad practice and eventually decreased productivity. Product Manager ‘only’ have to learn empirical management to be good Product Owners.

PO the Project Manager
In most projects I’ve worked in, the project manager does the planning of activities. If he gets the Product Owner role, he usually approaches the backlog from a planning perspective. That means he’ll decide what goes into what sprint based on external dependencies and availability of staff etc. Most project managers are actually not responsible for the profitability of the project or the budget. The PM makes the plan, but the Project Board approves the plan and budget. If the project goes over it’s deadline or budget the Project Board is accountable (if the PM gave ample warnings). The main problem is that work should not flow from managers but directly from stakeholders to developers because a manager is not the customer and usually lacks the business knowledge to make the right decisions. A project manager would actually have to be made accountable for the budget and profitability to be a good Product Owner.

PO the functional/information analyst
For most teams this sounds like the ideal product owner. An information analyst usually has in depth knowledge on what the customer needs. The information analysts I’ve worked with were good at structuring information and conveying it to the developers. Although very good for the productivity, an information analyst is not the same thing as a Product Owner. The analyst usually has ‘feature perspective’: what should the product do. His main competence is getting the requirements and wishes from the (potential) users of the system. If left unmanaged he’ll try to please the customer by implementing everything the customer asks for.
Implementing all requirements sounds good, but few projects have enough resources to do that, that’s why you need to prioritize features. I haven’t seen information analysts do this very well because the budget was not their responsibility. The analyst might work very closely with the product owner to prepare coming Sprints but he doesn’t actually need the Product Owner for that if the Product Backlog is in good shape. In any case an information analyst is a very valuable team member, not a Product Owner.

PO the Release Manager
A somewhat ambiguous term ‘release manager’, but it’s best explained as a coordinating planning and resource manager that plans work to be done and selects team members to do it. He also reports the status of work to stakeholders. In some ways the release manager role sounds a bit like the Product Owner role, they both feed work to the team. However, there were a few issues with this specific release manager as Product Owner. First of all, the release manager only planned work for one ‘type’ of developers (J2EE, C++ or .Net etc.) which means that features had already been split up into work packages for each competence. This makes prioritization an impossible task because the link between the work packages and the actual features were missing. The distance between the business case and stakeholders and the release managers was simply to great to make any real decisions and it wasn’t allowed to drop features to meet the schedule. So these release managers were Product Owner for one reason, we were doing Scrum and we needed someone (anyone?) to fill that role because it was in the Scrum book.

PO the Unit Manager
In one of my projects, a unit manager (manager of a business unit within an IT organization) took on the product owner role an in-house project. The main focus of a business unit manager is his people and because he knew Scrum he had no problem facilitating the team and giving them trust and responsibility. But that’s not the main responsibility of the Product Owner, that’s being accountable for the outcome of the project.
Getting the accountability right in an in-house project is perhaps even harder then when there’s a clear customer-vendor relationship. In this case team members were also stakeholders and the unit manager and stakeholders also wanted to help with development (are you still with me?). The main problem was accountability hadn’t been transfered explicitly to the Product Owner. The executive that controlled the budget had little control over the project and thus we fell into the age old project-trap where the people with the money ask “where is my money going?” The Unit Manager didn’t get to spend the money as he saw fit and didn’t take over responsibility for the success of the project, which left the Executive as the ‘hidden’ Product Owner.

The ‘right’ Product Owner

Although I haven’t seen the role filled correctly, I do see the need the Product Owner role is intended to fulfill in Agile projects. The big word here is Business Case. The business case describes the benefits of the deliverables of the project, for instance: “If we implement software product x, we’ll save x amount of money per year”. Executives love Business Case driven development and that’s why the Product Owner should steer the project using the business case (perhaps we should call him ‘Business Case Owner’?). The reverse is also true, if your Product Owner isn’t accountable for realizing the Business Case, he’s not your real Product Owner. But if you can transfer accountability to the product owner, what kind of competences does the Product Owner need to posses to perform Business Case driven steering?
Business Case Value
He needs to know which features add most value to the business case. If time saving is the main goal of the product, measurable time-saving features are valued higher than (for instance) usability features or product maintenance features.
Financial
He needs to know how much money a feature will cost and how much it will deliver. Having feature set X will increase our market share by Y. He needs to know how much to spend on each feature set and be able to drop or simplify features to match the budget.
Some domain knowledge
The product owner needs some domain knowledge so he can decide on what the stakeholders are talking about. Combining high level knowledge of features coupled with owning the business case is the main benefit of the role.
Time
One often discussed topic is the availability of the Product Owner. If you look at the responsibilities, he doesn’t have to be available full-time. If the product backlog is in good shape and priorities don’t change often the team can refine and implement the backlog items without the Product Owner.

The impossible job?

Now for the big problem: reality. Anyone can describe what a good Product Owner should be and do (I just did), but that doesn’t make it a reality. There is a fundamental problem with the Scrum Product Owner role outside of product development companies: good Product Owners are too rare. Most Scrum experts actually admit that a good Product Owner is a rare phenomenon.
One of the great selling arguments of Scrum is that it’s a lightweight process, some might even call it a process framework. That’s a good thing because that means you can start using Scrum quickly and then fine tune the actual process within the Scrum framework. However, the Product Owner role hinders this easy implementation of the framework. I can’t start up the customer-project feedback cycle immediately because in my experience the demands for the Product Owner role are too high.

Conclusion

I’ve explained when the Product Owner role didn’t work as it should have and also what a good Product Owner should be concerned with to maximize the project effectiveness by focussing on the business value of it’s features. I conclude that the role is hard to fill in the right way which makes Scrum hard to kick-start and makes the process feel either broken or too heavy.
Perhaps we need a special ‘non-product-development’ version of Scrum? Or redefine the Product Owner role to fit large organizations so that we can start the process immediately and then gradually move towards the ultimate vision of true collaboration between the business and development.