LACE (CCSQ Lean Agile Center of Excellence)

Page tree

Versions Compared

Old Version 3

changes.mady.by.user Nia Young

Saved on

compared with

New Version Current

changes.mady.by.user Marc Santini

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

We expect the Product Manager to use strategic vision to guide prioritization, planning, and delivery:

  1. The vision for all features has been presented to the team 
  2. The Product Manager will be fully available to the feature owner
  3. Work defined at the Feature level will be prioritized


We expect all team members

Definition of Ready (DoR)

  • Clear Acceptance Criteria so we know what needs to be done. (elaborate no general statements)
  • Create a checklist of what needs to be done on a user story before it can be implemented into next sprint
  • Guideline for what needs to be done during backlog refinement
  • Add and grow overtime
    • Ex. The user story is understood by the team :
      • Clear Business value
      • all dependencies are identified
      • story is small
      • AC is defined 
  • Feature is prioritized
  • Features:
  • Operations SOP:

Example of how we may want to write these( Social Contracts slides):

We need the backlog owner to understand the value and context of the work being refined, to help define work for prioritization, planning, and delivery. Before refinement:all work being included in each iteration:

  1. The Feature Owner understands the vision and the expected outcomes of the feature
  2. The Feature Owner The backlog author is prepared to clarify the requirements and context of the work in refinement and/or planning​
  3. The work item defined contains a value a value statement (who, what, why) (benefit hypothesis or use story statement)​
  4. The work item defined contains clear acceptance criteria that can be verified as pass/fail (success or acceptance criteria)
  5. The work defined will fit into the appropriate timebox


We will only make commitments for work that meets our standards of Ready

For each work item, before commitment:

  1. The work is prioritized
  2. The correct issue type is used
  3. If necessary or beneficial to cross-functionality, Mob/Pair team members are identified
  4. Peer review rigor and significant time commitments for peer review are defined and noted in the work item**
  5. All team members delivering have been added to a role
  6. There is an estimate
  7. Labels are accurate
  8. Links are accurate (clones, features, dependencies, etc)


We refuse to allow low quality requirements to impact our reliability. Before planning:

  1. The value is clear and understood (Why?)
  2. The desired outcome is clear (What?)
  3. The user/persona/beneficiary is defined and is the recipient of the value delivered (Who?)
  4. Binary acceptance criteria are present
  5. Relevant
  6. The work item contains potential risks, blockers, unknowns, and dependencies​
  7. The work item contains relevant guidance, information, and documentation links ​
  8. Defects are clearly defined with:
    1. Steps to reproduce​
    2. Expected results​
    3. Screenshots/logs​
    4. Test data
  9. The work item can be traced to its origin (Feature, Epic, OKR)​
  10. The work item is clearly categorized by value type
    1. Story​
    2. Bug/Defect​
    3. Enabler (Spike)
  11. The work item is sized​
  12. The work item is prioritized

We will only make commitments for work that meets our standards of Ready.

...

  1. are included
  2. Potential risks, blockers, unknowns, and dependencies​ are noted 
  3. Defect issues contain enough information to investigate



Reference for Feature

The Feature can be clearly described.The feature is well enough understood that its extent and purpose can be clearly explained by the Product Management / Product Ownership Team
Small enough to fit within a PIThe estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI).
The Feature is testableThe need for any unusual or novel testing is clear and factored into the estimates
The Feature is feasibleFor Business Features the architectural and technical risks are under control and it is expected that the Feature can be implemented without any significant technical issues. For experimental enablers and spikes the constraints are understood and the financial exposure is in-line with the probability of success.
The potential benefits are understoodThe Feature has a well understood, measurable benefits hypothesis.
The Feature has a clear ownerIt is clear who the team pulling the Feature should converse, and negotiate with, over the scope and extent of the Feature, and who will accept the Feature as done.
The level of key stakeholder involvement is understood.The details of any important external Stakeholders are known and the mechanisms to involve them in a timely way have been put in place.
The cost of delay is clearThe relative business / user value, time criticality, risk reduction and opportunity enablement are well enough understood that the Features cost of delay is clear. See the SAFe approach to Weighted Shortest Job First for more details.
Any ‘fixed’ requirements are knownAny specific, fixed, non-negotiable aspects of the Feature are known and their details are available. For example the specific actuarial calculations to be used in an insurance system.