Boom buffer

From Pearl Language
Revision as of 13:19, 26 May 2013 by Martien (talk | contribs) (terse/full)
Jump to navigation Jump to search

stable teams getting things done.

✣  ✣  ✣

You want to start what you finish and finish what you start, yet work is often interrupted by changing priorities or problems in the field. You want to avoid that this becomes a chronic dysfunction that leads to repeated failure of sprints, failure to meet deadlines, and even company failure.

Sales and marketing demands, combined with management interference, can cause unhealthy interrupts. Often poor product ownership allows competing priorities in a company to reach a build crew. Some crews have even been bribed to work on features not in the company's Template:Pbl.

Therefore:

Allot limited capacity for interrupts and do not allow the time to be exceeded. Close the feedback loop to the risk-carrier decides, often the product owner.

✣  ✣  ✣

Get management agreement on three simple rules that will cause the self-organization to avoid disrupting production:

  1. Create a limited buffer for unexpected items based on historical data. For example, 30% of the team's work on the average is caused by unplanned work coming into the sprint unexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the boom buffer.
  2. Route all requests through the product owner for triage. The product owner will give some items low priority if there is no perceived value relative to the business plan. Many other items will be scheduled for a later stage, even if they have immediate value. Only the product owner can put extremely critical items in the boom buffer.
  3. Automatically abort and replan the sprint, and notify management that dates will slip as soon as the boom buffer overflows. In the example, this happens when adding an item that will exceed the 20 points reserved for expedite work.

The product owner balances the buffer size to balance short term customer satisfaction with future revenue generation. The goal is to reduce the buffer's size to zero.

These rules will invariably cause individuals to self-organize to avoid blowing up a sprint as no individual wants to be seen as the direct cause of sprint failure.

Even better, the buffer will tend to never be full, allowing the team to finish early and pull forward from the backlog and/or work on removing impediments—teams that finish early tend to accelerate faster.

Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The product owner will put any critical items on the Template:Pbl. The team will typically double velocity and get twice as much done in future sprints. This typically allows more than enough time to address critical items and often have spare capacity or slack.


✣  ✣  ✣

Sources



Web: ScrumPLoP » Published Patterns » Illegitimus Non Interruptus » illegitimus non interruptus