Difference between revisions of "Ready to build"

From Pearl Language
Jump to navigation Jump to search
m (typos)
(Merged Frank's DoR and this one.)
Line 34: Line 34:


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.
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.
|therefore=Make sure any item is fully ready to implement before you start working on it.
|therefore=Make sure any item is fully ready to implement before you start working on it. Keep the item's description limited to two pages max. For more complex items, consider composing and {{p|enabling specification}}.
}}
}}
Table below is based on Bill Wake's INVEST acronym.
Table below is based on Bill Wake's INVEST acronym.
Line 57: Line 57:
|-
|-
|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 {{dt}} explains the context, what, why (value creation) and for whom (persona) back to the {{po}}. 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.
 
|-
|-
|valign="top"|'''negotiable'''
|valign="top"|'''negotiable'''

Revision as of 10:53, 3 November 2011

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

✣  ✣  ✣

{{{wish full}}}

See below for a detailed explanation.


A product backlog item is ready to build when:

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 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.

Therefore:

{{{therefore full}}}

✣  ✣  ✣



✣  ✣  ✣

Table below is based on Bill Wake's INVEST acronym.

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.

To 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 development team explains the context, what, why (value creation) and for whom (persona) back to the product owner. 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.

negotiable The item is clear on the what, yet still leaves room for:
  • 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.
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.

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.