LACE (CCSQ Lean Agile Center of Excellence)

Page tree

We are committed to being there for our teammates ​
  1. Core Working  Hours: 10am-3pm​
  2. When asked for help, immediately acknowledge the request and schedule time to assist ​
  3. We will work in our collaboration space when not in meetings or in need of “Focus Time”
  4. We will have the courage to step out of our comfort zone to help with each others duties and responsibilities
  5. We will share our knowledge and pair work within the team to encourage growth/support


We promise to show each other respect, at all times​

  1. Assume Positive Intent when dealing with other team members​
  2. Speak from feelings (“I feel/felt like”) to move toward agreement and understand perspectives to avoid accusatory language​
  3. Wait for others to finish speaking before responding
  4. We take time to recognize/celebrate accomplishments as a team.


We value the time of all team members​

  1. Be on time to all meetings or provide notice and expected deliverables if you will be absent​
  2. Be fully engaged in meetings (no work or cell phones, cameras on in all meetings)


We hold ourselves to the highest standard of work ​

  1. We understand that our work quality reflects on every member of the team (LACE)​
  2. All LACE members are familiar with trainings, playbook, and onboarding guide 
  3. All work is peer reviewed by one other team member 
  4. All coaching recommendations are in alignment with the playbook and the training
  5. When there is no guidance in the playbook and training discuss with team before providing recommendations


We will be a model for vulnerability and transparency in our organization​

  1. The board is updated during the daily stand-up​
  2. Add outages to the team calendar​
  3. Communicate outages in iteration planning​
  4. Ask for help or peer reviews when needed
  5. We won't fear judgment/negative response keep us from being transparent 
  6. We welcome failure to encourage growth


We will prioritize continuous improvement above all other work​

  1. Examine problems blamelessly​
  2. Adapt Processes(mange Jira board, write user stories, etc.) for transparency and efficiency​
  3. Honor retrospective commitments​
  4. We will update team contracts bi-annually AND when a new team member joins (including support members)
  5. Mistakes are an opportunity for improvement​
  6. We will identify opportunities to improve this agreement during retrospectives, and make the changes then and there

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 to understand the value and context of 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 is prepared to clarify the requirements in refinement and/or planning​
  3. The work defined contains a value statement (who, what, why) (benefit hypothesis or use story statement)​
  4. The work 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.

  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 guidance, information, and documentation links are included
  6. Potential risks, blockers, unknowns, and dependencies​ are noted 
  7. 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.









The CCSQ LACE functions as an agile business team. The DoD for business teams is more general than a DoD for technical delivery teams. 

CCSQ LACE Definition of Done

(and example for agile business teams)



We prioritize delivering value to customers, which is our organizations highest priority

  1. We can demonstrate completed work to our customers and stakeholders

  2. We will respond to feedback to make the work we do more valuable

  3. Features are only complete when our business owners agree the value has been delivered


We believe that Quality is of the utmost importance

  1. Each Acceptance criteria has been met

  2. The work meets the goal of the user story

  3. All work is peer reviewed

  4. The status of the work item to “Done”


We believe that our work should be accessible to the community

  1. We will post all assets produced in confluence, for the benefit of the CCSQ Community or our stakeholders

  2. We will present similar content in a visually consistent manner, both visually and in a way the content is accessed



Example Definition of Done for product and service delivery teams



We promise the organization that we will uphold all technical standards

  1. Ensure all enterprise policies are observed

  2. Ensure all enterprise standards are met

  3. Ensure all organizational standards are met

  4. Ensure all team standards are met


We understand the value and importance of meeting non-functional requirements

  1. All work will be 508/screen reader compliant

  2. All work will meet security standards

  3. All applicable design library components are used

  4. All UI/UX guidelines are followed


We will develop sustainable code for the benefit of the organization

  1. Names for objects, classes and functions are human readable

  2. The code contains lean but descriptive comments


We believe that Code Quality is of the utmost importance

  1. Unit Tests coverage is XX%

  2. Code is peer reviewed

  3. Integration tests are included

  4. The code builds successfully into the integrated solution


We prioritize delivering value to customers, which is our organizations highest priority

  1. Each Acceptance criteria has been met

  2. The work meets the goal of the user story


We acknowledge that we cannot decide when work is complete without stakeholders

  1. The work has been demonstrated to the Product Owner

  2. The Product Owner has changed the status of the work item to “Done”




  • No labels