Difference between revisions of "Ready to build"

From Pearl Language
Jump to navigation Jump to search
m (typos)
(→‎Sources: += Mike Cohn » The Dangers of a Definition of Ready)
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Oyster
{{Oyster
|goal=invest most of your time efficiently building, implementing the product
|stage=Germ
|stage=Germ
|theme=Agile, Scrum
|theme=Agile, Scrum
|context={{scrum}}, about to pull in {{pbi}}s into the {{p|sprint}}.
|context={{scrum}}, about to pull in {{pbi}}s into the {{p|sprint}}.
|wish in a single line=Full focus of transforming wishes into reality.
|therefore in a single line=Make sure any item is fully ready to implement before you start working on it.
|wish=Full focus of transforming wishes into reality.
|wish=Full focus of transforming wishes into reality.
|so=Make sure any item is fully ready to implement before you start working on it.
|wish full=Full focus of transforming wishes into reality, instead of spending valuable time on finding out what exactly needs to be build.
|background=*Downstream {{dor}} equals the upstream {{dod}}.
|background=*Downstream {{dor}} equals the upstream {{dod}}.
*{{dor}} means that any item pulled into the {{p|sprint}}.
*{{dor}} means that any item can be pulled into the {{p|sprint}}.
*High quality {{dor}} leads to high-quality work and speeds up velocity.
*High quality {{dor}} leads to high-quality work and speeds up velocity.


See below for a detailed explanation.
See below for a detailed example of a {{dor}}.


Forces:
*Additional detail allow multiple teams to coordinate their work better.
*Additional detail can lead to more discussion.
*Too much detail limits creativity for implementers.
*Too little detail creates confusion and wastes time during implementation.
*The right level of detail in requirements, both functional and qualitative increases the immediately actionability of it.
*The useful power of the well-written specification increases with the frequencey ofreferring to it, and the number of people that need to interpret it.
*If there are questions about a specification, then the answer needs to be written down in the specification for reference by all future users of the specification, creating a living document of the collective memory of the system. The answers are not just 'discussed' oraly, and forgotten in practice.


A {{pbi}} is {{p|ready to build}} when:
Spend about 10% of the sprint time on grooming the items into {{p|ready to build}} state. Spend this time during the {{p|sprint}}, not during the planning session. Make it you goal to reduce the {{p|sprint planning meeting}} to a mere reconfirmation of the {{pb}} that emerged during the {{p|sprint}}'s grooming sessions.
*it brings the product closer to the {{p|product goal}};
 
*the {{po}}:
Only allow {{p|ready to build}} items into the {{p|sprint backlog}}, or risk to be bitten by debate, technical debt, cutting corners, and high pressure during the {{p|sprint}}.
**can prioritize it;
 
**has quantified its value;
Aim for quality in, quality out.
**knows how to demo it (prepare the demo appropriately before the {{p|sprint review meeting}});
|therefore full=Use an {{p|elegant checklist}} to make sure any item is fully ready to implement before you start working on it. Keep the item's description limited to two pages. For more complex items, consider composing an {{p|enabling disclosure}}.
**the value of its outcome for the user (or {{p|vibrant persona}}) is clear, detailing how it fulfills a need, goal or desire;
|new=To test if an item is {{p|ready to build}}, the {{p|product owner}} can ask these key questions:
*it is detailed appropriately:
*Of all of the items that were presented:
**as an enabling disclosure; and/or
*#Which ones do you not feel confident at all in estimating?
**a page from the {{p|user manual}}, written by a {{p|mercenary analyst}};
*#Which ones would make you feel very uncomfortable if you had to start working on them first thing tomorrow?
**{{p|crystal clear acceptance criteria}} are distilled (e.g. expressed in a {{dsl}} like [http://cukes.info/ Cucumber]); these go hand in hand with the {{p|user manual}} section;
*non-functional criteria are clear;
*it is small enough, e.g. no larger than 8 {{sp}}s;
*the {{p|development team}}:
**says “Ah, we get it!”;
**knows their implementation strategy, direction and conceptual design;
**can estimate its implementation cost in {{sp}}s and have done so;


Spend about 10% of the sprint time on grooming the items into {{p|ready to build}} state. Spend this time during the {{p|sprint}}, not during the planning session. Make it you goal to reduce the {{p|sprint planning meeting}} to a mere reconfirmation of the {{pb}} that emerged during the {{p|sprint}}'s grooming sessions.
Also, use the {{p|ambiguity test}} whenever it makes sense.


Only allow 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.
Of course, anyone of the {{p|build crew}} should ask herself or himself the same questions.
|therefore=Make sure any item is fully ready to implement before you start working on it.
}}
}}
Table below is based on Bill Wake's INVEST acronym.
Table below is based on Bill Wake's INVEST acronym. You can use it to structure your grooming sessions. It helps to uncover and discover otherwise unnoticed aspects and allows you to {{p|build quality in}}.


Second column is the test designed to proof the validity of the first.
The second column is the test designed to proof the validity of the first.


{|rules="rows"
{|rules="rows"
Line 48: Line 49:
|valign="top"|The {{dt}}s have no no known questions regarding the what, why and for whom of the item and  can immediately start implementing the item, working on it until it is done, completing it until it meets all criteria that allow it to be pulled into the next station.
|valign="top"|The {{dt}}s have no no known questions regarding the what, why and for whom of the item and  can immediately start implementing the item, working on it until it is done, completing it until it meets all criteria that allow it to be pulled into the next station.


To improve actionability, consider providing:
Therefore, a {{pbi}} must be detailed appropriately, e.g.
*as an {{p|enabling disclosure}}; and/or
*a page from the {{p|user manual}}, written by a {{p|mercenary analyst}};
 
To further improve actionability, consider providing:
*UI sketches, wireframes, and mock ups;
*UI sketches, wireframes, and mock ups;
*scenarios;
*scenarios;
Line 57: Line 62:
|-
|-
|valign="top"|'''understanding'''
|valign="top"|'''understanding'''
|valign="top"|The {{dt}} explains the context, what, why (value creation) and for whom (persona) back to the {{po}}.
|valign="top"|The {{pbi}} details how it fulfills a need, goal or desire of the role or {{p|vibrant persona}}.
The {{dt}}:
*says “Ah, we get it!”;
*explains the context, what, why (value creation) and for whom ({{p|vibrant persona}}) back to the {{po}}; and
*knows their implementation strategy, direction and conceptual design.
 
 
A popular form for {{us}}s is: As a ''role'' I want to ''action'' so that ''benefit''. Preferably, most stories obey this form. In some cases, you might consider using a {{p|vibrant persona}} for the the ''role''.
 
Typically, the ‘To’ part of a story, e.g. “To save a message” in a mail program, is the title of the story. The title of the story is something you can put into the user manual. Therefore, keep the title terse, concise, limited to a single short line. Make sure the title has both an action (verb) and object (noun) in it.
 
Another way to test understandibility and intelligibility is to do the {{p|ambiguity test}}.
 
|-
|-
|valign="top"|'''negotiable'''
|valign="top"|'''negotiable'''
|valign="top"|The item is clear on the what, yet still leaves room for:
|valign="top"|The item is clear on the what, yet still leaves room for:
*ways to make it better or implement it faster;
*how it will be implemented, meeting or exceeding the non-functional requirements and within the technological and architectural guidelines; and
*how it will be implemented, meeting or exceeding the non-functional requirements and within the technological and architectural guidelines; and
*nudging details—functional, behavioral, technical, or otherwise that would benefit its use or implementation
*nudging details—functional, behavioral, technical, or otherwise that would benefit its use or implementation
Line 71: Line 89:
|-
|-
|valign="top"|'''sized appropriately'''
|valign="top"|'''sized appropriately'''
|valign="top"|The item's estimated implementation effort is 8 {{sp}}s or less.
|valign="top"|The item's estimated implementation effort is 8 {{sp}}s or less. If a story takes more than half of the {{p|sprint}} to implement by a single person, don't take it into {{p|sprint}}.
|-
|-
|valign="top"|'''testable'''
|valign="top"|'''testable'''
Line 90: Line 108:
|-
|-
|valign="top"|'''demonstrable'''
|valign="top"|'''demonstrable'''
|valign="top"|Either the {{dt}} or {{po}} or both can demonstrate the item when implemented.
|valign="top"|Either the {{dt}} or {{po}} or both can demonstrate the item when implemented. A good time for this is the {{p|sprint review meeting}}, but any other time during the {{sprint}} is also good. It gives a chance to immediately get some feedback and fold that in to current development.


Defining and scripting the demonstration helps to:
Defining and scripting the demonstration helps to:
Line 100: Line 118:
A {{p|mercenary analyst}} can help verbalize the item in a concise, coherent and comprehensive way.
A {{p|mercenary analyst}} can help verbalize the item in a concise, coherent and comprehensive way.
|}
|}
==Sources==
{{WebSourceListItem
|url=http://www.infoq.com/news/2014/06/using-definition-of-ready
|site=InfoQ
|person=Ben Linders
|title=Using a Definition of Ready
}}
{{WebSourceListItem
|url=https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
|site=Mike Cohn
|title=The Dangers of a Definition of Ready
}}
{{Source
{{Source
|author={{mvs}}
|author={{mvs}}
|coder={{mvs}}
|coder={{mvs}}
}}
}}

Latest revision as of 06:58, 10 August 2016

scrum, about to pull in product backlog items into the sprint.

✣  ✣  ✣

Full focus of transforming wishes into reality, instead of spending valuable time on finding out what exactly needs to be build.

See below for a detailed example of a definition of ready.

Forces:

  • Additional detail allow multiple teams to coordinate their work better.
  • Additional detail can lead to more discussion.
  • Too much detail limits creativity for implementers.
  • Too little detail creates confusion and wastes time during implementation.
  • The right level of detail in requirements, both functional and qualitative increases the immediately actionability of it.
  • The useful power of the well-written specification increases with the frequencey ofreferring to it, and the number of people that need to interpret it.
  • If there are questions about a specification, then the answer needs to be written down in the specification for reference by all future users of the specification, creating a living document of the collective memory of the system. The answers are not just 'discussed' oraly, and forgotten in practice.

Spend about 10% of the sprint time on grooming the items into ready to build state. Spend this time during the sprint, not during the planning session. 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.

Only allow ready to build items into the sprint backlog, or risk to be bitten by debate, technical debt, cutting corners, and high pressure during the sprint.

Aim for quality in, quality out.

Therefore:

Use an elegant checklist to make sure any item is fully ready to implement before you start working on it. Keep the item's description limited to two pages. For more complex items, consider composing an enabling disclosure.

✣  ✣  ✣

To test if an item is ready to build, the product owner can ask these key questions:

  • Of all of the items that were presented:
    1. Which ones do you not feel confident at all in estimating?
    2. Which ones would make you feel very uncomfortable if you had to start working on them first thing tomorrow?

Also, use the ambiguity test whenever it makes sense.

Of course, anyone of the build crew should ask herself or himself the same questions.


✣  ✣  ✣

Table below is based on Bill Wake's INVEST acronym. You can use it to structure your grooming sessions. It helps to uncover and discover otherwise unnoticed aspects and allows you to build quality in.

The second column is the test designed to proof the validity of the first.

Check Proof
immediately actionable The development teams have no no known questions regarding the what, why and for whom of the item and can immediately start implementing the item, working on it until it is done, completing it until it meets all criteria that allow it to be pulled into the next station.

Therefore, a product backlog item must be detailed appropriately, e.g.

To further improve actionability, consider providing:

  • UI sketches, wireframes, and mock ups;
  • scenarios;
  • design ‘comics’ and story boards.
independent Any dependancies are identified and the dependency count is less than three, meaning that the item is relatively independent and does not pull a lot of other items into the sprint.
understanding The product backlog item details how it fulfills a need, goal or desire of the role or vibrant persona.

The development team:

  • says “Ah, we get it!”;
  • explains the context, what, why (value creation) and for whom (vibrant persona) back to the product owner; and
  • knows their implementation strategy, direction and conceptual design.


A popular form for Template:Uss is: As a role I want to action so that benefit. Preferably, most stories obey this form. In some cases, you might consider using a vibrant persona for the the role.

Typically, the ‘To’ part of a story, e.g. “To save a message” in a mail program, is the title of the story. The title of the story is something you can put into the user manual. Therefore, keep the title terse, concise, limited to a single short line. Make sure the title has both an action (verb) and object (noun) in it.

Another way to test understandibility and intelligibility is to do the ambiguity test.

negotiable The item is clear on the what, yet still leaves room for:
  • ways to make it better or implement it faster;
  • how it will be implemented, meeting or exceeding the non-functional requirements and within the technological and architectural guidelines; and
  • nudging details—functional, behavioral, technical, or otherwise that would benefit its use or implementation
valuable The relative (business) value is clear and written on the item.
estimable The item's relative implementation effort expressed in story points is written on the item by the development team, using techniques like planning poker.
sized appropriately The item's estimated implementation effort is 8 story points or less. If a story takes more than half of the sprint to implement by a single person, don't take it into sprint.
testable Crystal clear acceptance criteria for both the product owner and operations are associated with the item, probably written on the back of the item or documented in an automated test harness.

Acceptance criteria help to:

Popular tools like Cucumber can be used to express these criteria and facilitate automated testing practices.

Other useful practices include giving examples of:

  • use case processes;
  • reports;
  • queries;
  • input forms; and
  • inspectors.
demonstrable Either the development team or product owner or both can demonstrate the item when implemented. A good time for this is the sprint review meeting, but any other time during the sprint is also good. It gives a chance to immediately get some feedback and fold that in to current development.

Defining and scripting the demonstration helps to:

  • set scope;
  • think through the many aspects of its use;
  • find both happy and exceptional paths through the item's use; and
  • validate earlier defined scenarios and their outcomes.

A mercenary analyst can help verbalize the item in a concise, coherent and comprehensive way.

Sources