Difference between revisions of "Boom buffer"
(Zeroth version.) |
m (Themes += Jumpstart - Agile) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Oyster | {{Oyster | ||
|goal=deal with interruptions during the sprint | |||
|stage=Sparkle | |stage=Sparkle | ||
|theme= | |theme=Scrum, Jumpstart | ||
|context={{p|stable team}}s getting things done. | |context={{p|stable team}}s getting things done. | ||
|wish | |wish=You want to get as much done in a single sprint, without interrupts. | ||
| | |so=Allot limited capacity for interrupts and do not allow the time to be exceeded. | ||
|wish=You want to {{p|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 {{p|sprint}}s, failure to meet deadlines, and even company failure. | |wish full=You want to {{p|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 {{p|sprint}}s, failure to meet deadlines, and even company failure. | ||
|background=Sales and marketing demands, combined with management interference, can cause unhealthy interrupts. Often poor {{p|product owner}}ship allows competing priorities in a company to reach a {{p|build crew}}. Some crews have even been bribed to work on features not in the company's {{pbl}}. | |background=Sales and marketing demands, combined with management interference, can cause unhealthy interrupts. Often poor {{p|product owner}}ship allows competing priorities in a company to reach a {{p|build crew}}. Some crews have even been bribed to work on features not in the company's {{pbl}}. | ||
|therefore=Allot limited capacity for interrupts and do not allow the time to be exceeded. Close the feedback loop to the {{p|risk-carrier decides}}, often the {{p|product owner}}. | |therefore full=Allot limited capacity for interrupts and do not allow the time to be exceeded. Close the feedback loop to the {{p|risk-carrier decides}}, often the {{p|product owner}}. | ||
|new=Get management agreement on three simple rules that will cause the self-organization to avoid disrupting production: | |new=Get management agreement on three simple rules that will cause the self-organization to avoid disrupting production: | ||
#'''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 {{p|sprint}} unexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the {{p|boom buffer}}. | #'''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 {{p|sprint}} unexpectedly. If the team velocity averages 60 points, 20 points will be reserved for the {{p|boom buffer}}. | ||
| Line 20: | Line 21: | ||
Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The {{p|product owner}} will put any critical items on the {{pbl}}. The team will typically double velocity and get twice as much done in future {{p|sprint}}s. This typically allows more than enough time to address critical items and often have spare capacity or slack. | Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The {{p|product owner}} will put any critical items on the {{pbl}}. The team will typically double velocity and get twice as much done in future {{p|sprint}}s. This typically allows more than enough time to address critical items and often have spare capacity or slack. | ||
}} | }} | ||
==Sources== | |||
*http://gamasutra.com/view/feature/190891/programmer_interrupted.php | |||
{{Source | {{Source | ||
|source=ScrumPLoP | |source=ScrumPLoP | ||
Latest revision as of 14:34, 12 July 2013
…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:
- 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.
- 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.
- 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