Ready to implement: verschil tussen versies

Uit Pareltaal
Naar navigatie springen Naar zoeken springen
(Toelichting++)
(Extended++)
Regel 3: Regel 3:
|thema=Bouwen, Projectleiden, Scrum
|thema=Bouwen, Projectleiden, Scrum
|context=getting closer and closer to actually implementing new ideas, new features, new products.
|context=getting closer and closer to actually implementing new ideas, new features, new products.
|wens in één regel=Quality in, quality out. A smooth, sustainable and predictable product development cycle.
|wens in één regel=Quality in, quality out, and stability in a sprint. A smooth, sustainable and predictable product development cycle.
|daarom in één regel=Only allow items that are really ready to implement into a sprint.
|daarom in één regel=Only allow items that are really ready to implement into a sprint.
|wens=Quality in, quality out. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both {{p|product owner}}s and {{p|development team}}s shine.
|wens=Quality in, quality out, and stability in a {{p|sprint}}. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both {{p|product owner}}s and {{p|development team}}s shine.
|toelichting=A {{p|product backlog item}} is {{p|ready to implement}} when:
|toelichting={{p|ready to implement}} is designed to stop time being wasted when it’s discovered that {{p|user store}}s are missing important pieces of information that means they can’t be started or completed.
 
A {{p|product backlog item}} or {{p|user story}} that is {{p|ready to implement}} gives the team confidence that every story they bring into a {{p|sprint}} is completely ready for them to get started on. In this way, {{p|ready to implement}} can improve the flow and stability in a {{p|sprint}}.
 
A {{p|product backlog item}} is {{p|ready to implement}} when:
*it brings the product closer to the {{p|product goal}};
*it brings the product closer to the {{p|product goal}};
*the {{p|product owner}}:
*the {{p|product owner}}:
Regel 12: Regel 16:
**has quantified its value;
**has quantified its value;
**knows how to demo it (prepare the demo appropriately before the {{p|sprint review meeting}});
**knows how to demo it (prepare the demo appropriately before the {{p|sprint review meeting}});
**the value of its outcome for the user (or {{p|vibrant personas}}) is clear, detailing how it fulfills a need, goal or desire;
**the value of its outcome for the user (or {{p|vibrant personas}}) is clear, detailing how it fulfills a need, goal or desire, articulated in the format ‘As a ''role'' I want to ''reach some goal'' so that ''value or benefit''’.; the part starting with “to…” can be put right into the {{p|user manual}};
*it is detailed appropriately:
*it is detailed appropriately:
**as an {{p|enabling disclosure}}; and/or
**as an {{p|enabling disclosure}}; and/or
**a page from the {{p|user manual}}, written by a {{p|mercenary analyst}};
**a page from the {{p|user manual}}, written by a {{p|mercenary analyst}};
**{{p|crystal clear acceptance criteria}} are distilled (e.g. expressed in a {{p|domain specific language}}); these go hand in hand with the {{p|user manual}} section;
**{{p|crystal clear acceptance criteria}} are distilled (e.g. expressed in a {{p|domain specific language}}); these go hand in hand with the {{p|user manual}} section;
**follows the [[INVEST]] model;
***no external dependancies block the item being completed;
*{{p|non-functional criteria}} are clear;
*{{p|non-functional criteria}} are clear;
*it is small enough, e.g. no larger than 8 {{p|story points}};
*it is small enough:
**a handful of {{p|product backlog items}} can be completed in a single {{p|sprint}}
**an item is no larger than 8 {{p|story points}};
*the {{p|development team}}:
*the {{p|development team}}:
**says “Ah, we get it!”;
**says “Ah, we get it!”;
Regel 24: Regel 32:
**can estimate its implementation cost in {{p|story points}} and have done so;
**can estimate its implementation cost in {{p|story points}} and have done so;


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|ready to implement}} removes a major impediment:
*Removed disruptions and waste caused by issues being clarified with customer or other.
*It’s about focus, commitment and how to share knowledge.
*Easy to address when identified.
 
Make features {{p|ready to implement}} before they are {{p|ready to ship}}:
*do not allow a feature to be included in sprint unless it is {{p|ready to implement}};
*simple concept, depends on discipline and creates stability in {{sp}};
*prepare {{pbl}} with at least same speed as {{sp}}s;
{{po}} tasks are not part of {{sp}} plan:
*clarification is a disruptive activity by nature;
*make clear arrangements for how {{po}} activities are supported by {{dt}};
{{dt}} both deliver {{sp}}s and support {{po}}:
*balance is achieved by first ensuring that features and {{uss}} are prepared sufficiently using these objectives
**a feature can be implemented by {[dt}} in one {{sp}} (< 600h);
**a {{us}} can be implemented by 1–2 people within 1–2 days (< 50h)
*{{dt}} proactively participated in workshops preparing {{p|sprint planning meeting}}
Systematically remove impediments:
*sprint retrospective at the core;
*measure and analyze data, e.g. fix-time for broken builds or flow.
 
Lead developers typically assist on multiple stories.
 
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 parallel to 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.
{{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 {{p|ready to implement}} into a sprint. Spend about 10% of the {{p|sprint}} time on grooming the {{p|product backlog item}}s into {{p|ready to implement}} state.
|daarom=Only allow items that are really ready to implement into a sprint.
}}
}}
 
Sources:
*http://www.boost.co.nz/blog/agile/definition-of-ready/
*http://systemagility.com/2011/05/17/definition-of-ready/
*http://agile2009.org/files/session_pdfs/Going%20from%20Good%20to%20Great%20with%20Scrum%20Session.PDF
{{Bron
{{Bron
|auteur={{mvs}}
|auteur={{mvs}}
|codeur={{mvs}}
|codeur={{mvs}}
}}
}}

Versie van 19 sep 2011 07:52


…getting closer and closer to actually implementing new ideas, new features, new products.

✣  ✣  ✣

Quality in, quality out, and stability in a sprint. A smooth, sustainable and predictable product development cycle makes planning releases a breeze and both product owners and development teams shine.

ready to implement is designed to stop time being wasted when it’s discovered that user stores are missing important pieces of information that means they can’t be started or completed.

A product backlog item or user story that is ready to implement gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, ready to implement can improve the flow and stability in a sprint.

A product backlog item is ready to implement when:

ready to implement removes a major impediment:

  • Removed disruptions and waste caused by issues being clarified with customer or other.
  • It’s about focus, commitment and how to share knowledge.
  • Easy to address when identified.

Make features ready to implement before they are ready to ship:

product owner tasks are not part of sprint plan:

development team both deliver sprints and support product owner:

  • balance is achieved by first ensuring that features and user stories are prepared sufficiently using these objectives
    • a feature can be implemented by {[dt

Daarom:

{{{daarom}}}

✣  ✣  ✣



✣  ✣  ✣


in one sprint (< 600h);

Systematically remove impediments:

  • sprint retrospective at the core;
  • measure and analyze data, e.g. fix-time for broken builds or flow.

Lead developers typically assist on multiple stories.

Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state. Spend this time parallel to 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. Spend about 10% of the sprint time on grooming the product backlog items into ready to implement state. }} Sources: