Difference between revisions of "Set of reference stories"
Jump to navigation
Jump to search
(Zeroth version.) |
m (terse/full) |
||
| Line 3: | Line 3: | ||
|theme=Agile, Scrum | |theme=Agile, Scrum | ||
|context=multiple {{p|development team}}s working on a single product. | |context=multiple {{p|development team}}s working on a single product. | ||
| | |goal=enable planning across multiple squads and tribes | ||
|wish=Planning with predictability and sustainability creates trust and competitive advantage in the market. | |wish=Planning with predictability and sustainability creates trust and competitive advantage in the market. | ||
|so=Maintain a set of baselined reference stories used by all squads as a benchmark for estimation. | |||
|wish full=Planning with predictability and sustainability creates trust and competitive advantage in the market. | |||
|background=Mike Cohn: | |background=Mike Cohn: | ||
*In a consulting firm I would absolutely want to strive to have a common baseline for story points. | *In a consulting firm I would absolutely want to strive to have a common baseline for story points. | ||
| Line 20: | Line 21: | ||
*teams can be unfairly compared to one another; | *teams can be unfairly compared to one another; | ||
*estimating time (e.g. ideal days) is very dependent on individual skills and experience | *estimating time (e.g. ideal days) is very dependent on individual skills and experience | ||
|therefore=Bring a broad group of individuals representing various {{p|development team}}s together; e.g. pairs of each {{p|development team}}. Have them estimate a dozen or so {{pbi}}s (ideally in the form of real {{p|user stories}}); it will take some more time to reach consensus with a large group; e.g. two hours to estimate 12 items. Have each pair of estimators take back to their {{p|development teams}} the two handfuls of estimates and use them as a comparing reference for local estimates. Publish a set of agreed-upon {{p|user stories}} and their {{p|relative estimate}}s. | |therefore full=Bring a broad group of individuals representing various {{p|development team}}s together; e.g. pairs of each {{p|development team}}. Have them estimate a dozen or so {{pbi}}s (ideally in the form of real {{p|user stories}}); it will take some more time to reach consensus with a large group; e.g. two hours to estimate 12 items. Have each pair of estimators take back to their {{p|development teams}} the two handfuls of estimates and use them as a comparing reference for local estimates. Publish a set of agreed-upon {{p|user stories}} and their {{p|relative estimate}}s. | ||
|new=*Using some artificial user stories as they’ll be more likely to be understandable by a broad set of consultants. | |new=*Using some artificial user stories as they’ll be more likely to be understandable by a broad set of consultants. | ||
*Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to). | *Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to). | ||
Latest revision as of 10:27, 16 June 2013
…multiple development teams working on a single product.
✣ ✣ ✣
Planning with predictability and sustainability creates trust and competitive advantage in the market.
Mike Cohn:
- In a consulting firm I would absolutely want to strive to have a common baseline for story points.
Wish:
- establishing a common definition of a story point across multiple teams within an organization
- helps estimation and planning in general and gives a common basis for capacity (given that teams, technology, processes and tools remain relatively stable);
- clears up any confusion and suspicion of underachievement in the higher management layers;
- allows consulting firms to create ‘SLAs’ based on empirical data rather than risky guesses;
- may help to surface particularly bad environment/political issues on certain projects - “hey, why does it take 5 times as long to do a story point on this project?
Forces:
- some people strongly resist or reject estimation, let alone creating a common baseline for story points (e.g. orthodox Kanban adepts);
- teams can be unfairly compared to one another;
- estimating time (e.g. ideal days) is very dependent on individual skills and experience
Therefore:
Bring a broad group of individuals representing various development teams together; e.g. pairs of each development team. Have them estimate a dozen or so product backlog items (ideally in the form of real user stories); it will take some more time to reach consensus with a large group; e.g. two hours to estimate 12 items. Have each pair of estimators take back to their development teams the two handfuls of estimates and use them as a comparing reference for local estimates. Publish a set of agreed-upon user stories and their relative estimates.
✣ ✣ ✣
- Using some artificial user stories as they’ll be more likely to be understandable by a broad set of consultants.
- Any new story can be compared to any of the old ones so the original baseline become less important over time (as there are many more to compare to).
✣ ✣ ✣
Sources