Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Partition Your Backlog for Maximum Mileage
Posted by Vikas Hazrati on Jul 28, 2009
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.
Serge suggested partitioning the backlog into the following 4 areas to keep the flow consistent.
- items that are currently in the Sprint,
- items that are Ready,
- items that you're preparing to Ready, and
- the rest: new stuff.
New" and "Ready" are prioritized buffers, "Preparing" and "In Sprint" are Work-In-Progress.
- 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.
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Agile Development: A Manager's Roadmap for Success
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
French translation of Serge Beaumont posts
by
Fabrice AIMETTI
Posted
Top level view is needed
by
Udayan Banerjee
Posted
Use "ready" and "preparing" as dynamic roadmap...
by
Douglas Stein
Posted
-
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 -
I agree with Jeff Patton - we need a top level view. setandbma.wordpress.com/2009/06/18/why-am-i-unc...
-
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 :-)
- 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.
3 comments
Watch Thread Reply