Flow to READY, Iterate to DONE

Serge Beaumont

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.

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

Comments (18)

  1. Machiel - Reply

    July 4, 2009 at 8:47 pm

    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.

  2. Serge Beaumont - Reply

    July 4, 2009 at 9:17 pm

    @Machiel: short answer is I don't set a maximum number of items, I set minimum quality requirements to the items themselves.

    The best answer I have so far is what I wrote under the "Prioritized Buffer: New" heading. Demanding that stakeholders present the business context and valuation throttles the things that get on the backlog: not just any wild idea gets on it. Basically some of the load is pushed back into the organization this way.

    Another technique is to ask "Why?" a couple of times to get to the higher level goals, and leave them at that coarser-grained level until they get closer to the "Top 10" of the New stuff.

    But overall I guess this is an intrinsic property of Product Owner work. You can only manage the flow of new stuff as best you can, never block it. By managing that flow a Product Owner can give the Team the illusion that work comes in nicely packaged chunks: the Product Owner should not wish for that luxury, it's the whole point of the role :-)

  3. Lars Vonk - Reply

    July 5, 2009 at 1:23 pm

    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?

  4. Machiel Groeneveld - Reply

    July 6, 2009 at 10:01 am

    @Lars
    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.

  5. Otto Paulsen - Reply

    July 6, 2009 at 11:25 am

    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...

  6. Serge Beaumont - Reply

    July 6, 2009 at 7:38 pm

    @Lars: You mention putting items on the backlog. I agree with your reasoning behind it. A Scrum board allows coordination, and therefore it's good to put it somewhere that allows it. However, I have a counter-suggestion. What about using a Scrum board-like mechanism, but putting it next to the Scrum board? This way you have coordination AND an explicit split of PO and Team related work. Oh, and by the way, that's what the next post will be about ;-).

    @Otto: thanks for your extensive comment. It's interesting to see your concrete case :-). You mention putting "getting to READY" work into the team because of your situation. The way I look at is that you are not pulling PO work into the team, the people in the team are putting work into the PO role.

    Your impediment is that you do not have enough PO support, and as a team you've taken on this role to fill the gap. It's the reaction of every responsible professional, but you do know you're making yourself the owner of the problem, right? :-). The real impediment still need to be fixed: I hope you're not getting into problems because you're "too slow"...

    I would suggest that everybody explicitly tracks the work you're putting into the PO role, and the work that you're putting into the Team role. By making this explicit you can maybe even show how one of your biggest impediments can be improved: if someone else fills in that PO capacity, we can do more Team work! There is definitely a business case in there somewhere :-).

    You also mention that as a Team you have enough business knowledge to fill in the PO role. That's fine, reality is hard on theory, and if that's the best you can do, it's the best you can do. But again I would say that you're implementing the PO role at that moment: it's a workaround to an impediment. It would work as long as having two hats does not give problems, like you mention in your last paragraph. It's not just about knowledge, but a mindset induced by the role. As a team member you can not help but take implementation into account, and it's really hard to keep a clean view that keeps business value at the top of mind.

    You mention that the business does not know the solution. If you talk about the implementation solution that's mostly correct, the "how" is something the team has to add to get stuff to READY. But there are two levels of solution. One is "what needs to be done in the product", but at the business level there is what the business is trying to achieve. So the solution "we need a more efficient order entry process" to fix "customers are angry because they're waiting on the phone" is one that is specified only in terms of the business. That's the level of solution that your PO MUST supply: goals and solutions ONLY in business terms, WITHOUT referring to the product. This answers the "why?" question. But the way the product supports the business is what should be determined in dialog with the team, answering the "what?" question, and with that context information the team can determine the "how?". So there are several levels of "solution": the team members can not realistically provide them all.

    I hope I can make this all more concrete in the next blog post: I hope I'll get to it soon!

  7. Fabrice Aimetti - Reply

    July 13, 2009 at 11:47 pm

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

  8. Twitted by jhollingworth - Reply

    July 23, 2009 at 9:29 am

    [...] This post was Twitted by jhollingworth [...]

  9. Yuval Yeret - Reply

    August 2, 2009 at 4:10 pm

    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?

  10. Carsten Ruseng Jakobsen - Reply

    August 4, 2009 at 10:14 am

    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.

  11. [...] to document more user stories than required, and it will be a form of a waste. Product Owner should maintain good balance here. var dzone_style="2";SHARETHIS.addEntry({ title: "Bugs Source #1: Unclear User Stories", url: [...]

  12. Serge Beaumont - Reply

    August 6, 2009 at 4:50 pm

    @Yuval: The flow style I suggest is independent of the granularity of the backlog items: I consider this to be an orthogonal issue. I tend to add one (or more, depending on how much you're scaling) layer on top of the fine-grained backlog (which is nice for the team) that is coarser grained (which is nice for the PO's overview: seeing the trees for the forest). I have done some large scale implementations with multiple (8) teams, where I introduced a higher level backlog that represents the strategic goals of the company: all lower level backlogs would point up at the strategic one. Another trick is to have an "epic type" that is not part of the backlog proper, but only there to connect related user stories. There's many ways to do this, but in the end I'd say that what you're "atomically flowing" is your finest-grained level, whatever it may be.

    As to sprinting the same backlog, that's perfectly fine. The only situation you want to avoid is one team sprinting multiple backlogs because that pushes PO work (integrating the two backlogs) into the team.

  13. [...] disso, para dar mais sentido para o backlog, Serge Beaumont sugeriu um interessante modo de particionar o backlog o qual mapeia para um fluxo e faz com que o backlog tenha sua existência [...]

  14. [...] Atualização em 18/08/09 - Depois de esvaziar o buffer neste post, continuei lendo e pesquisando sorbe o assunto. Pretendo formatar um modelo que funcione bem para as características específicas aqui da Myfreecomm. Nas leituras achei este post que responde exatamente as minhas perguntas. [...]

  15. [...] approach to agile coaching. Another BoF was run by Serge Beaumont on practical tools, like the Ready state and Jeff Patton’s Story Mapping for the Product Owner. Both BoFs have noticeably created a [...]

  16. [...] Owner Ready Board.” Agile Product Owner Blog, November 2009. [10] Beaumont, Serge. “Flow to READY, Iterate to DONE.” Xebia, July, 2009. [11] Leffingwell, Dean. “More on Lean, Backlog and Little’s [...]

  17. Manjit singh - Reply

    May 20, 2013 at 11:30 pm

    Great ARTICLE! I LOVE THE SIMPLE BUT YET PRACTICAL EXPLANATION. ANY ONE CAN PUT THIS TO PRACTICE RIGHT AWAY.

    THANK YOU FOR WRITING AND SHARING.

Add a Comment