Ready to implement: verschil tussen versies
(Shine on you crazy diamond.) |
(Toelichting++) |
||
Regel 25: | Regel 25: | ||
Spend about 10% of the {{p|sprint}} time on grooming the {{p|product backlog item}}s into {{p|ready to implement}} state. Spend this time during the {{p|sprint}}, not during the {{p|sprint planning meeting}}. Make it you goal to reduce the {{p|sprint planning meeting}} to a mere reconfirmation of the {{p|product backlog}} that emerged during the {{p|sprint}}'s grooming sessions. | Spend about 10% of the {{p|sprint}} time on grooming the {{p|product backlog item}}s into {{p|ready to implement}} state. Spend this time during the {{p|sprint}}, not during the {{p|sprint planning meeting}}. Make it you goal to reduce the {{p|sprint planning meeting}} to a mere reconfirmation of the {{p|product backlog}} that emerged during the {{p|sprint}}'s grooming sessions. | ||
{{p|sprint planning meetings}} that spiral out of control and lively debates on particular {{p|sprint backlog items}} that have already been taken into the sprint are bad smells indicating the team is working on unready to implement items. | |||
Only allow {{p|ready to implement}} items into the {{p|sprint backlog}}, or risk to be bitten by debate, technical debt, cutting corners, and high pressure. Aim for quality in, quality out. | Only allow {{p|ready to implement}} items into the {{p|sprint backlog}}, or risk to be bitten by debate, technical debt, cutting corners, and high pressure. Aim for quality in, quality out. | ||
|daarom=Only allow items that are really ready to implement into a sprint. | |daarom=Only allow items that are really ready to implement into a sprint. | ||
}} | }} |
Versie van 16 sep 2011 15:25
…getting closer and closer to actually implementing new ideas, new features, new products.
✣ ✣ ✣
Quality in, quality out. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both product owners and development teams shine.
A product backlog item is ready to implement when:
- it brings the product closer to the product goal;
- the product owner:
- can prioritize it;
- has quantified its value;
- knows how to demo it (prepare the demo appropriately before the sprint review meeting);
- the value of its outcome for the user (or vibrant personas) is clear, detailing how it fulfills a need, goal or desire;
- it is detailed appropriately:
- as an enabling disclosure; and/or
- a page from the user manual, written by a mercenary analyst;
- crystal clear acceptance criteria are distilled (e.g. expressed in a domain specific language); these go hand in hand with the user manual section;
- non-functional criteria are clear;
- it is small enough, e.g. no larger than 8 story points;
- the development team:
- says “Ah, we get it!”;
- knows their implementation strategy, direction and conceptual design;
- can estimate its implementation cost in story points and have done so;
Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state. Spend this time during the sprint, not during the sprint planning meeting. Make it you goal to reduce the sprint planning meeting to a mere reconfirmation of the product backlog that emerged during the sprint's grooming sessions.
sprint planning meetings that spiral out of control and lively debates on particular sprint backlog items that have already been taken into the sprint are bad smells indicating the team is working on unready to implement items.
Only allow ready to implement items into the sprint backlog, or risk to be bitten by debate, technical debt, cutting corners, and high pressure. Aim for quality in, quality out.
Daarom:
Only allow items that are really ready to implement into a sprint.
✣ ✣ ✣
✣ ✣ ✣