BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ
News Articles Presentations Podcasts Guides

Topics

Choose your language

QCon New York

Find real-world practical inspiration from the world’s most innovative software leaders. Attend in-person or online.
QCon San Francisco

Learn what's next in software from world-class leaders pushing the boundaries. Attend in-person or online.
The Software Architects' Newsletter

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Partition Your Backlog for Maximum Mileage

QCon San Francisco (Oct 2-6, 2023): Find real-world practical inspiration from senior software engineers.

Partition Your Backlog for Maximum Mileage

Leia em Português

This item in japanese

Bookmarks

Jul 28, 2009 2 min read

Write for InfoQ

Join a community of experts. Increase your visibility.
Grow your career.Learn more

Backlogs have been under constant criticism for quite some time now. Mary Poppendieck suggested that the product backlog should be eliminated if it is not satisfying the desired purpose. Similarly, Jeff Patton suggested that flat backlogs fail to convey high level view of the system. He suggested using a story map instead. Further, in order to give more meaning to the backlog, Serge Beaumont suggested an interesting way of partitioning the backlog such that it maps to a flow and makes the backlog worthy for existence.

According to Serge, the flow to ready involves work from the product owner to pick up NEW stories, get them to a READY state, so that the team can start work on them and process them to the DONE state.

Flow to READY

Serge suggested partitioning the backlog into the following 4 areas to keep the flow consistent.

  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.

New" and "Ready" are prioritized buffers, "Preparing" and "In Sprint" are Work-In-Progress.

Partition Backlog

  • Prioritized buffer: New - The product owner has not started work on these items. This is an excellent location to practice triage and get rid of those items which seem to be adding little value. This list needs to be prioritized on the basis of business experience, valuation of benefit, business urgency etc. 
  • Work-In-Progress: Preparing - This is the core list where the PO spends a lot of time trying to get an item to the READY state. According to Serge, this is the place where PO needs to pull in stuff based on his capacity. This partition would also reflect on the velocity of the product owner. The PO needs to ask questions and solicit answers on each backlog item to further refine it and get it to the READY state. 
  • Prioritized buffer: Ready - The READY buffer needs to have a prioritized list of 1.5 – 2 iterations worth of work so that the team can pick up additional items for an iteration if they are finished early. Serge mentioned that having more than 2 iterations worth of items in the ready buffer would constitute waste. 
  • Work-In-Progress: In Sprint - These are the backlog items which are being implemented in the current sprint. 

Thus the breaking the backlog into 4 areas aligns it well with the flow to get an item from NEW to READY to DONE state. This would also help in reducing the inventory buildup at any partition and each partition would be able to pull items based on the capacity of the team and the product owner.

Rate this Article

Adoption
Style

This content is in the Agile topic

Related Topics:

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • French translation of Serge Beaumont posts

    by Fabrice AIMETTI,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You will find the french translation of two excellent posts of Serge Beaumont :
    1° The Definition of READY;
    2° Flow to READY, Iterate to DONE.
    Regards

    Back to top
  • Top level view is needed

    by Udayan Banerjee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with Jeff Patton - we need a top level view. setandbma.wordpress.com/2009/06/18/why-am-i-unc...

    Back to top
  • Use "ready" and "preparing" as dynamic roadmap...

    by Douglas Stein,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A good Product Roadmap (see Pragmatic Marketing) does the following:


    Illustrate(s) the vision and key phases of deliverables for the product.
    The roadmap is a plan, not a commitment.

    I find that maintaining a Word document for the roadmap is really "muda". It's a collection of sentiments and not actionable goals. It's far better to do the following (which I counsel my clients as I bring them up the "Agile Pragmatic" curve):

    • Set release timeboxes around the immovable dates for the business. Since most of my clients are in the K-12 SaaS space where customers have a limit to the change they can absorb, I find that 6-10 week releases composed of 3-5 2-week sprints works well.


    • Into these releases you drop a mixture of Ready and Preparing stories to fit themes that will resonate with customers. Each release has its own release backlog - this is supported natively by tools such as Rally)


    • The current release is totally composed of In Sprint and Ready stories


    • The next release is mostly Ready stories with a sprinkling of Preparing stories. Your job during the current release as a product owner is to make sure that the next release is completely Ready.


    • The farther out you go, the vaguer the roadmap becomes with more and more of the stories in the Preparing state.


    • The product (as opposed to the release) backlog contains mostly New stories with a smattering of Preparing and Ready stories. These are good ideas that haven't been prioritized. The reason some of them are more developed is because a good Product Owner will take ideas from others in the company (after first asking them to flesh out their ideas). The more the ideas are based on real market data and customer interviews, the more likely they are to be in a Preparing or Ready form.



        The end result is that your developers know what they're doing for the current release and understand the "saga" of the product over time. It's also a way to acculturate the dev team to what customers value and why they use the product. For other business stakeholders (senior management, Board, investors, key partners and customers) you have a real roadmap. It's a snapshot of the current thinking that's crisp in the short-term, fuzzier as you go further out, but gives consistent themes. It's a basis for communication and negotiation with these parties. The roadmap can be used to tell not only where you are going, but what things get pushed out (or pulled forward) if there's a need to cut back (or an opportunity to expand) funding.

        FYI, I've been a CTO and VP Development in several industries (including Education, Quant Finance, and enterprise software). You can't use this approach in all industries - it works well for SaaS; it doesn't work well for interplanetary probes or life support equipment :-)

      Back to top

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    BT