Flow to READY, Iterate to DONE

04 Jul, 2009

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 Product Owner flows, the Team iterates

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

The Backlog partitioned into flow parts: In Sprint, READY, Preparing, New.

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:

READY Kanban

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.


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

Newest Most Voted
Inline Feedbacks
View all comments
13 years ago

One thing I’m missing is how you limit the total amount of backlog items that an organisation has. In my experience product owners can have up to a year’s worth of feature requests in progress or under debate, which is ludicrous and often stalls the flow of requirements to the teams.

Lars Vonk
13 years ago

Thanks Serge,
I like the partitioning of the backlog into 4 areas. I currently use 3 (where new and preparing is one), splitting them up looks like a good idea.
Also I am thinking, why no put the work of the product owner(the getting things ready part) on the sprint backlog itself. So a task of the sprint backlog could be something like: get feature x to ready. This has some advantages IMHO:
1. Team is completely aware of what is coming next sprint since it is on the same board.
2. If the PO gets sick someone else can easily pick it up.
3. If the new backlog items aren’t ready than the sprint has failed. This is good because then the backlog isn’t ready for the new sprint.
What do you think?

Machiel Groeneveld
13 years ago

Putting the product owners work on the sprint backlog has at least one issue: it’s not synchronous to what the team is working on. That’s probably the reason why Serge came up with a pre-sprint-flow to make this more visible. Also, the nature of the product owners work is different, less sprinty and more fuzzy.

Otto Paulsen
Otto Paulsen
13 years ago

Hi Serge. I really like what you write here. It is very close to the way we have been working for some time, and I would like to share some of our experience.
We use the READY state, and find it very useful. Everybody can see that there is work to be done before we can include an item in scope. We have not been so explicit about the 4 stages, but I think it is a good idea, because it will make the necessary work more visible.
However, our PO role is a bit different than what you seem to assume here. You have the PO obviously very close to the team and probably working with this stuff most of his/her time. I believe this is good, but in our case that is not the situation. Our PO is sitting in the user organization which is physically far from the scrum development team and the SM (me), and he is PO only a small part of his time. In addition, the work of getting items in the READY state is pretty much done by the team. And there is a good reason for this. The PO and the users normally have a business case they want to solve, but they have no good idea on how to solve it. But the development team has a lot of business knowledge and are the people best fit to come up with a solution. I think this is the case in most of the scrum teams where I work.
So a normal process of getting stuff from new to ready is that 1) the users and PO explain the problem for the team. 2) The team spend some time thinking and discussing, and end up with a suggested solution. 3) the team presents the solution to the PO and users. They may do some adjustments and that is about it. Ready! The total effort required vary a lot, from almost nothing or just a few minutes, to several days over a period of several weeks.
The work the development team has to do to make items ready goes into the sprint backlog. It is time boxed, or actually just estimated in hours. They do however not earn story points for doing this kind of work. After all, we want them to do to only as much as necessary.
There is one major drawback in our way of doing this. When the development team creates a solution, they often identify several new user stories, normally because the original one is split. So the team tries to formulate the user stories. But as you know, this is not a job for the team. The user stories get technical, and they often do not have business value. Just a function that was easy to separate from the rest. I guess this only visualizes that the PO should sit with the team after all, and join in on the solution work so he can take care of the user stories from the beginning. Hmm. That’s a hard one…

Fabrice Aimetti
13 years ago

Hello Serge, Thanks for this excellent article. You fill find its french translation on Préparer le PRÊT – Itérer jusqu’Ý  TERMINÉ. Regards.

Yuval Yeret
13 years ago

I like this very much. In one of the companies I’m consulting to we are trying to indeed create a flowing process for backlog creation, and this is very inline with what we have in mind.
A key question though is how to deal with scale, namely if you are working on big projects with many teams, you need to decide at what level you are tracking on this kanban. Is it Features/Epics/Stories?
One thing I’m thinking of is maybe tracking at the level that originally goes into the backlog, but if during the “preparing” stage you understand its comprised of more stories you can move the tracking to this level (and throw away the original story? leave it as an aggregate?)
This sounds like an area where Minimally-Marketable-Features (MMF) can come into play nicely – maybe you want to track at the MMF level, and if you understand something can be effectively split to two or more MMFs, fine!
Another scaling issue is if you have multiple teams that are sprinting the same backlog, or even multiple component teams sprinting the same project (and having each their internal component backlog) – I know its not a recommended structure but one that happens in really large scale until the Feature-team approach really takes flight… 😉
Any thoughts?

Carsten Ruseng Jakobsen

I really find this blog well-written and good!
I agree with Serges point above in separating the work of PO from the work of the Team. Otherwise it is very difficult to establish a stable continous flow for the Team. Also the nature of the PO’s work is often more disruptive.

Manjit singh
Manjit singh
9 years ago


Explore related posts