| Context | The Product Owner has created Product Backlog Items for the a release. |
| Problem | When do which Product Backlog Items need to be broken down? Decomposing all Product Backlog Items for estimation and realization in a Sprint for a complete release creates wasted effort as requirements change and new requirements arise. Furthermore, estimations are not precise if the Product Backlog Items are realized far in the future. |
| Forces | too little/too much effort wasted too little/too much detail planning |
| Solution | Decompose Product Backlog Items depending on their realization date. Break down and estimate Product Backlog Items which will be realized in the next few Sprints and use Themes and Epics for requirements, which are far away. Themes are medium-sized, but too large to be implemented in a single Sprint, Epics can even span multiple Releases. Although estimates of Themes and Epics are not as precise as estimates of small Product Backlog Items, the effort of breaking them down immediately is wasted in many cases. Furthermore, too many Product Backlog Items clutter the Backlog. |
| Resulting Context | The Product Backlog Items have been broken down efficiently. |
Dieser Artikel wurde von Andreas Heilwagen am 16.05.2011 um 08:30 gepostet und unter Scrum eingeordnet. Sie können Kommentaren über den RSS 2.0-Feed folgen. Das Posting steht unter der Creative Commons-Lizenz wenn nicht anders vermerkt.
