Devops for Growth

You want to know when items are done, ready for the next step. You cannot estimate when you don’t know what done means.

The product owner's conditions of satisfaction for a product backlog item are the high-level and crystal clear acceptance criteria that he or she likes to see applied to a product backlog item before considering it is finished. A product backlog item is finished when it can be demonstrated to meet all conditions of satisfaction identified by the product owner.

The definition of done is informed by reality where it captures activities that can be realistically committed by the development team to be completed at each level (feature, sprint, release). 

Working on too many things at once leads to radical reduction in the velocity of an individual, a team, or a company, grinding the system to halt.

Therefore:

Focus maximum squad effort to get the top priority ready to release and celebrate yet another ka-ching moment. Consider setting the work in progress limit for items in progress to one.

You want clear, unambiguous and intelligeble requirements, expressing needs and wishes.

Tom and Kai Gilb talk about User Stories: A Skeptical View. Question: How many words in the 'requirement', “We want the most intuitive system possible.” are potentially ambiguous? Answer: All. Collect interpretations, and you will find everybody has quite different interpretations, none are identical.

Therefore:

Ask how many words in the requirement are potentially ambiguous. Next, collect and compare interpretations from different individuals.

✣  ✣  ✣

An alternative way to prove unintelligibility is counting defects in relation to the following standard using the Spec QC review method.

Rules:

1. The specification will be clear enough to test. Not later, but in itself! Now!
2. The specification will be unambiguous to all intended readers, anywhere, anytime (including lawyers, and expert witnesses in your lawsuit).

Now using the spec, “We want the most intuitive system possible.”, how many of the words potentially violate those rules? Tom Gilb's and Kai Gilb's personal answer is 7, but even 1 disqualifies the spec as useful.

✣  ✣  ✣

Sources

• Tom Gilb & Kai Gilb » Gilb Papers » User Stories: A Skeptical View

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

• Downstream definition of ready equals the upstream definition of done.
• definition of ready means that any item can be pulled into the sprint.
• High quality definition of ready leads to high-quality work and speeds up velocity.

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.

You want to make sure something is ready to be promoted to the next phase or level.

The checklist demonstrates when something is done in this step and thus equals ready for the next step:

• Purpose:
  • Remind people what must be done (they already know how to do it)
• Content:
  • Captures customer feedback and preserves knowledge
  • Frees people to pay attention to the complicated aspects of a job
• Important!
  • Test-drive and refine frequently
  • Modify to fit each environment

A !ghter pilot's checklist before he enters aerial combat is a mental aid that frees his mind for “higher order” thinking.

Routine task checklists and standardized procedures can free brainpower for creative problem solving which can make the difference between success and failure.

Therefore:

Use and evolve a concise and complete checklist detailing what must be done before advancing.