ORGANIZATION
.
How we organize the people is important. We want the right skillsets and the right size of teams to maximize value delivery.
Agile Team
The heart of the value delivery is built on the Agile Team 1. From the Scrum Guide 2:
"The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal."
Each of these roles are important and should not be dismissed or missing from the team. It is recommended that the Agile Team positions be filled by contract partners (ADOs).
Scrum Master
- Guides the team in Agile practices.
- Removes impediments the team experiences.
Product Owner
- Has content authority over the Team Backlog.
- Establishes and maintains product vision.
- Works with developers to provide alignment and remove ambiguity for the work to be done.
Team Members/Developers
- Does the work to create and deliver the value.
- Cross functional skills to be autonomous in doing the necessary work.
- Software Engineers
- UI/UX
- Technical Writers
- Testers
- Etc.
Agile Release Train
Release Train Engineer (RTE)
"The Release Train Engineer (RTE) 3 is a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement."Product Manager
"Product Management 4 is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle."The Product Manager 3 position is to be filled by a government partner. There may be more than one Product Manager on an ART.
Agile Coach
The Agile Coach assists the ART in identifying and addressing impediments, waste, Agile processes, and value delivery. The Agile Coach may or may not be a full-time member of the ART. Their engagement depends on the maturity and experience of the ART and the specific opportunities that need to be addressed.Contact the LACE for Agile Coaching Support
WORK STRUCTURE
Work Item Management BasicsOwnership is taken, not givenScaled Agile, Lean, and Agile development models leverage KanBan’s operating model to provide transparency, visibility, and shared understanding of work preparation and delivery progress. Owners of responsibility for a process step pull work from the upstream step as throughput allows. For example, a Product Owner pulls the highest priority feature from the program backlog as they become available to investigate the desired functionality and define requirements for the product backlog. Work is then pulled from the prioritized product backlog in priority order into the sprint backlog by the development team. Within the iteration, a developer pulls the highest priority story in the sprint backlog when they become available. Since we can’t predict who will be the first available to pull the highest priority item from appropriate backlog, the onus of changing ownership is on the person beginning the next phase of work. The exception to this rule is that work is pushed into the "Ready" states to support procedural communications and visibility.Social Contracts regulate qualityThe Definition of Ready and the Definition of Done regulate the quality of work throughout the process. Each business and product delivery team should develop their own definitions of what constitutes done and ready, holding themselves and others accountable to these contracts. The Definition of Ready defines what is acceptable for work to begin, and the Definition of Done defines when the work is done, and therefore ready, for the next phase of the process.Whoever is working it owns itAt any level of requirements, whoever is responsible for a phase of delivery of work retains ownership until the phase is complete. At the higher levels of requirements, ownership my never be transferred, For example, a solution manager owns one or more epics, and its associated draft features. When the feature drafts are done, it is also ready for a Product Owner to take ownership and begin more thorough requirements definition and refinement.Whoever owns it manages the statusBecause work item status management is the responsibility of the owner, the transfer of ownership throughout the process is key for both communications and visibility. As a result, the statuses that a specific owner can manage are limited to those within their domain authority. For example, a developer has authority to say a work item is in “development” or “ready for testing”, but may not change a Feature’s status to complete, as it is outside the developer's domain authority, and should only be closed by the Product Manager. | The Requirements Hierarchy
Work break down moves from large and goal oriented to small and deliberate.The 4 levels of requirements from largest to smallest:
Requirements that can exist at multiple levels of the hierarchy:
Use the menu at the top to see the CCSQ Standards for defining and managing each work item type |
---|
References used in this article:
2 - Scaled Agile Framework - Feature https://www.scaledagileframework.com/features-and-capabilities/
3 - Scaled Agile Framework - Story https://www.scaledagileframework.com/story/
4 - Definition of Done https://qnetconfluence.cms.gov/display/LACE/Definition+of+Done
5 - Scaled Agile Framework - Strategic Themes https://www.scaledagileframework.com/strategic-themes/
6 - Scaled Agile Framework - Continuous Delivery Pipeline https://www.scaledagileframework.com/continuous-delivery-pipeline/
7 - Scaled Agile Framework https://www.scaledagileframework.com/
8 - Scaled Agile Framework - Portfolio Kanban https://www.scaledagileframework.com/portfolio-kanban/
Objectives
"Objectives are strategic and tactical requirements used to associate value with the work being delivered, rather than describe the work itself". | Objectives can be used to map value to any level of requirement, and can be used by every level of the enterprise. Objectives defined at any level should be evaluated for progress at a minimum once per PI.Typically, you will see the Objective work item type used at the team level to show how the work in their PI Plan supports the program's business objectives, which should be introduced at the beginning of PI Planning. At this level, the Objective work item type should be linked as "Supports" to the corresponding PI Objective, rather than a Feature.At the Program Level, you may see the Objective Work Items as the parent items for Epics or Features, and are typically expressed as Objectives and Key Results (OKRs). To use objective at this level, you must manually add the Supports/Is Supported By or Parent/Child links in Jira. |
Epics

Enabler Management
"Enablers are work required to build business future functionality." | Enablers sit outside the hierarchy of work items and describe a specific type of work. Enablers can be defined at the Epics, Features, or User Story level. Programs use two primary enabler types: Feature and team enablers.These work item management practices align the work with SAFe standards, support enterprise metrics, and reporting standardization across CCSQ. |
Feature Enabler:
The Program Feature Backlog differentiates enabler work using labels tagged to
Enabler Type | Enabler Jira Label | Description |
Exploration enablers | Exploration_Enabler | Support research, prototyping, and other activities needed to develop an understanding of customer needs, including the exploration of prospective solutions, and evaluating alternatives. |
Architectural enablers | Architectural_Enabler | Define the Architectural Runway, which allows smoother and faster development. |
Infrastructure enablers | Infrastructure_Enabler | Define enhancements to and automations for the development, testing, and deployment environments to ensure higher-quality, and increase the speed of development and deployment. |
Compliance enablers | Compliance_Enabler | Facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals. |
Team Enablers:
Enablers at the team level should use the
work item type.Enabler Issue Management Standard
Status | Status Definition/Description | Status Category | Jira Enabler Workflow Setup |
New: | Has been created and can be in any state of refinement by the Product Owner and/or team, but has not met the definition of ready | To-do | |
Ready: | Has met the team’s Definition of Ready but has not been taken into an iteration commitment | To-do | |
In Development: | A developer has become available, taken ownership of the story and begun working on a task associated with the story | In Progress | |
Ready for Peer Review: | The developer has completed the story and needs it reviewed by a fellow engineer | In Progress | |
In Peer Review: | A fellow engineer is reviewing and discussing with the authoring engineer if/when changes need to be made | In Progress | |
Ready for Testing: | All development tasks are complete, the code has been reviewed, integrated, and deployed to the test environment | In Progress | |
In Testing: | Testing of the story has begun, test cases are being run against all business, functional an non-functional requirements | In Progress | |
Ready For Acceptance: | Testing is complete, and the story is awaiting the product owner to begin validating the Business and Functional requirements defined in the Acceptance Criteria | In Progress | |
Production Ready: | The Product Owner has validated the Acceptance Criteria and approves the story for deployment to the production environment | Done | |
Done: | The story has been deployed and validated in the production environment | Done | |
Abandoned: | The Product Owner has made the decision that the story is no longer necessary | Done |
Ownership by Status and Transition
Ownership Role | Status | Status Change |
Product Owner | ||
Developer | ||
Developer 1 | ||
Developer 2 | Or back to | |
Tester | Or back to | |
Product Owner | ||
Product Manager | ||
Product Owner | <any state> |
Spike (Research) Management
Since spikes do not directly deliver user value, use them sparingly | Spikes should be Quantifiable, Demonstrable, and Acceptable. Like other stories, spikes are put in the Team Backlog, estimated, and sized to fit in an iteration. Spike results are different from a story because spikes typically produce information rather than working code. They should develop only the necessary data to identify and size the stories that drive it confidently. The output of a spike is demonstrable, both to the team and to any other stakeholders, which brings visibility to the research and architectural efforts, and also helps build collective ownership and shared responsibility for decision-making. The Product Owner accepts spikes that have been demoed and meet its acceptance criteria. |
Tracking research using
Spikes are typically Technical or Functional
Functional spikes – They are used to analyze overall solution behavior and determine:
- How to break it down
- How to organize the work
- Where risk and complexity exist
- How to use insights to influence implementation decisions
Technical spikes – They are used to research various approaches in the solution domain. For example:
- Determine a build-versus-buy decision
- Evaluate the potential performance or load impact of a new user story
- Evaluate specific technical implementation approaches
- Develop confidence about the desired solution path
Use Jira Labels: Functional_Spike or Technical_Spike
Spike Management Standard
Status | Status Definition/Description | Status Category | Jira Story Workflow Setup |
Funnel: | Document any need for technical or functional research | To-do | |
Analyzing: | The Product Owner has documented the benefit hypothesis and acceptance criteria. WSFJ has been calculated | To-do | |
PI Ready: | Has met the team’s Definition of Ready for the PI but has not been taken into an iteration commitment | To-do | |
In Development: | A developer has become available, taken ownership of the Spike and begun working on a associated task | In Progress | |
Ready for Peer Review: | The developer has completed the Spike and needs it reviewed by a fellow engineer | In Progress | |
In Peer Review: | A fellow engineer is reviewing and discussing with the authoring engineer if/when changes need to be made | In Progress | |
Ready For Acceptance: | The Spike is awaiting the Product Owner to validate the Business Hypothesis and requirements defined in the Acceptance Criteria | In Progress | |
Done: | The Product Owner has validated the Acceptance Criteria and approves the Spike | Done | |
Abandoned: | The Product Owner has made the decision that the Spike is no longer necessary | Done |
Ownership by Status and Transition
Ownership Role | Status | Status Change |
Product Owner | ||
Product Owner | ||
Developer 1 | ||
Developer 1 | ||
Developer 2 | ||
Developer 2 | Or back to | |
Product Owner |
Feature Management
"A feature is a service that fulfills a stakeholder need." | Each Feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). Features are working software that solve problems. Partial features can be released to the users, as long as it solves a user's problem or helps a user complete their work. Features move through different statuses as they are being refined, developed, and released. Below is the recommended Program Kanban configuration, taken from the Scaled Agile Framework. You can see that as Features move through the Continuous Delivery Pipeline there are corresponding statuses to bring visibility into the progress of Feature work. |
Status | Status Definition/Description | Status Category | Jira Story Workflow Setup |
Funnel: | All big ideas are welcome here | To-do | |
Analyzing: | The Product Owner has documented the benefit hypothesis and acceptance criteria. WSFJ has been calculated | To-do | |
PI Ready: | Has met the team’s Definition of Ready for the PI but has not been taken into an iteration commitment | To-do | |
Program Backlog: | A program has accepted the work for a Program Increment | In Progress | |
Implementing: | As development team has started working on stories associated with the Feature | In Progress | |
Validating on Staging: | The Feature is being tested in a Staging environment | In Progress | |
Production Ready: | A Product Owner has validated that the Business Hypothesis and requirements defined in the Acceptance Criteria have been met | Done | |
Done: | The Product Manager has validated that the Feature has been deployed | Done | |
Abandoned: | The Product Owner has made the decision that the Feature is no longer necessary | Done |
Ownership by Status and Transition
Features are owned by the Feature Owner for a specific Feature and the role is assigned when more explicit requirements are needed and the Feature is being implemented and developed. Feature Owner works closely with the Solutions Management Team (SMT) and Product Owner (PO) who is a member of the Agile Team. Feature Owner works in identifying benefit hypothesis and how this Feature will need to be developed and guides the Product Owner and Agile Team with visioning and goal of the scope of work needed. Product Owner author stories in advance of backlog refinement with the assistance of the team to ensure the Agile Team understands "What" needs to get done and Agile Teams focus on "How" it will get done and "How much" will get done based on capacity and velocity.
Ownership Role | Status | Status Change |
Product Owner | ||
Product Owner/SMT | ||
Product Manager/SMT/RTE | ||
RTE/Development Team | ||
RTE/Development Team | ||
RTE/Dev Team/Product Manager | ||
Product Manager | ||
Product Owner | <any state> |
*Only the Feature Owner and Product Manager have the authority to abandon or close a feature
Jira Board Configuration
- Given that CCSQ has adopted the Scaled Agile Framework for Enterprise, ISG Programs should use the columns above to create transparency and allow enterprise measurement.
- While all programs have different processes to manage their work, Jira offers some flexibility in its board configuration, allowing custom processes to be shown on the program
- Most of the statuses your program needs are already created in Jira, but you may need to request the statuses be added to your project via a request in Atlassian Slack. When working with Atlassian to set up your project, request the core statuses from the Kanban board above and any other statuses you use in your workflow.
The Program Kanban Board configuration below illustrates the encouraged configuration. Labels can be added to support reporting or add visibility to issues on your board.
Click on image to enlarge
User Story Management
"A User story is a short, informal, plain language description of what a user wants to do to gain something they find valuable." | The user stories are owned by the product owner, from the time created until a work begins, and re-assumes ownership after work is complete. For User stories where task assignment is split, ownership should be assumed by the first person taking a task, and can be updated to the person working the last open task. |
User Story Issue Management Standard
Status | Status Definition/Description | Status Category | Jira Story Workflow Setup |
New: | Has been created and can be in any state of refinement by the Product Owner and/or team, but has not met the definition of ready | To-do | |
Ready: | Has met the team’s Definition of Ready but has not been taken into an iteration commitment | To-do | |
In Development: | A developer has become available, taken ownership of the story and begun working on a task associated with the story | In Progress | |
Ready for Peer Review: | The developer has completed the story and needs it reviewed by a fellow engineer | In Progress | |
In Peer Review: | A fellow engineer is reviewing and discussing with the authoring engineer if/when changes need to be made | In Progress | |
Ready for Testing: | All development tasks are complete, the code has been reviewed, integrated, and deployed to the test environment | In Progress | |
In Testing: | Testing of the story has begun, test cases are being run against all business, functional an non-functional requirements | In Progress | |
Ready For Acceptance: | Testing is complete, and the story is awaiting the product owner to begin validating the Business and Functional requirements defined in the Acceptance Criteria | In Progress | |
Production Ready: | The Product Owner has validated the Acceptance Criteria and approves the story for deployment to the production environment | Done | |
Done: | The story has been deployed and validated in the production environment | Done | |
Abandoned: | The Product Owner has made the decision that the story is no longer necessary | Done |
Ownership by Status and Transition
Ownership Role | Status | Status Change |
Product Owner | ||
Developer | ||
Developer 1 | ||
Developer 2 | Or back to | |
Tester | Or back to | |
Product Owner | ||
Product Manager | ||
Product Owner | <any state> |
To do: | A task/story has been created and is in the backlog | To-Do | To-Do |
In-Progress: | A task/story has been started by an engineer | In Progress | In Progress |
Awaiting Review | A task/story is ready for review by another engineer | In In Progress | Progress |
In Review | A task/story is being reviewed internally | In Progress | In Progress |
Awaiting Awaiting Validation | The task/story is awaiting confirmation of completion | In Progress | In Progress |
Done: | The task meets the release criteria defined in the team's definition of done | Done | Done |
Abandoned: | The team has made the decision that the task is no longer necessary. | Done | Done |
COLLABORATION
.
Collaboration is a key practice to maintaining alignment and removing impediments. Collaboration is necessary within a team between team members, teams with other teams (inside and outside of the ART 1), and teams and the ART with stakeholders and customers.
Cadence 2 of normalized collaboration sessions helps keep calendars uncluttered and minimizes disruption of focus time to get the work done.
Program
Program Increment
The Program Increment 1 (PI) is a medium term timebox between 8-12 weeks. This gives the program roughly a quarterly timeline to plan and deliver initiatives at the Feature level.
PI Planning
At the beginning of the PI, the Agile Release Train takes time to map and commit to the Features that will be completed in the PI during the PI Planning 2 event. This is an important ceremony that cannot be skimped on. All members of the ART and external stakeholders MUST participate to set the ART up for success in value delivery. To learn more about PI Planning, please request the LACE Explained: PI Planning Training. Futhermore, the success of a PI Planning depends on real-time access to information and tooling to support distributed planning or remote attendees. One of the tools at your disposal is LucidSpark. Learn how to leverage LucidsPark PI Planning Template.
ART Sync
During the PI, as the Agile Teams and ART members are executing to create and deliver value, it is important to align on execution and expose impediments that are impacting the ART. The ART Sync 5 is typically attended by Scrum Masters, Product Owners, Technical Leads, and various Program Stakeholders. The ART Sync is not a ceremony. It is a broad label that encompasses two ceremonies, the PO Sync and the Scrum of Scrums 6. These two ceremonies can be scheduled independently, back-to-back, or even simultaneously. However, the value of these two ceremonies is the ability to communicate progress and surface dependencies and risks. This means that outputs and discoveries from one ceremony are communicated to the other.
System Demo
During the PI, as the Agile Teams and ART members are executing to create and deliver value, it is important to show the actual value (working software) to customers and stakeholders in the System Demo 3. This is the time for the customers and stakeholders to view progress and give feedback.
Inspect & Adapt Workshop
At the end of the PI, the ART must take time to reflect on how it executed and how it can improve. The Inspect & Adapt Workshop 4 brings the entire ART together for a retrospective. Learn more about the LACE Inspect and Adapt Explained Training.
Team
Each Agile Team executes within an ART during a PI. The teams operate on their own work items, collaborating with other teams, as needed.
Iteration
Just as the PI is the timebox for the ART, the Sprint 1, or Iteration, is the timebox for the Agile Team. This is a shorter timebox, as several Iterations will occur in a given PI. Generally, an Iteration length is 2 weeks.
Iteration Planning
At the beginning of the Iteration, the team plans the work to be committed to from the Product Backlog. This is the Daily Scrum 2.
Daily Standup
Just as the ART Sync helps the ART align and expose impediments, the Daily Scrum 3, or Daily Standup, helps the team align and expose impediments. This happens on a daily basis, so the team doesn't fall too far out of alignment and impediments don't remain hidden.
Iteration Review
At the end of the Iteration, the team showcases their completed work. This is a review of the current state of the product. The Iteration Review 4 is a time for the customers and stakeholders to witness the completed work and provide feedback. It's important for team members to demo the actual deliverables - working software or documentation for example - so everyone is in sync and the Product Owner and team members can provide more useful feedback. In a virtual team environment, consider walking through each user story and it's associated deliverables via screen share.
Iteration Retrospective
At the end of the Iteration, the team reflects on how they accomplished their work and how they can improve. This is a review of the current state of the agile process. The Retrospective 5 is a time for the team members to provide feedback on what is working well and not working well in the agile process and create action items that the Scrum Master can track and report on during the following Sprint Retrospective. This is to ensure that changes are being made and the desired outcomes are being realized. If they're not, try something new to address the pain points and revisit it during the next Retrospective. Learn to facilitate a retrospective here
SOCIAL CONTRACTS
.
In order for teams to work together, and team members to work together, social contracts must be created and agreed upon. These contracts help focus the conversations and establish expectations. We recommend at least having the following three Social Contracts on every team. There can be more contracts, but these three should always exist.
Social Contracts should be reviewed and updated on a regular basis. Team member changes (new people join, existing members leave) are great opportunities to review the existing contracts, or create them, if they don't exist. The Iteration Retrospective is also an appropriate time to review and update the team Social Contracts.
Agile Release Trains can also create Social Contracts, as needed. Working Agreements, in general, are powerful tools to help eliminate waste in collaboration and driving to high value outcomes. Learn more about Social Contracts by requesting the LACE Explained: Social Contracts Training.
Working Agreement
The process of defining the Team’s working agreement is straightforward. The Scrum Master facilitates a session with the Agile Team and Product Owner, where they generate a number of team disciplines together. A working agreement should be recalled easily, so they will then vote on the top five to ten disciplines. Once the Team has agreed upon a set of disciplines, they should be posted in their designated area and/or stored in a virtual folder that is accessible to all members.
• Product Owner is available during core hours
• Be on time for all meetings
• Communicate individual schedules
• ALL changes to the Sprint / Backlog must be approved by the Product Owner
• Use the Impediment Backlog (or swimlane) for blocked issues
• Define and adhere to ‘DONE’ criteria for stories
• Define and adhere to Version Control rules
• Adhere to code documentation standards
• Update Backlog before Standup daily
• Respect your team member’s time
Definition of Ready
"Ready" stories should be clear, concise, and most importantly, actionable.
These considerations are often summarized as the Invest Criteria 2, and they provide us with a useful Definition of Ready which can be applied to Product Backlog Items. By actively participating in Product Backlog refinement, a good Development Team will collaborate with the Product Owner in making sure that a standard such as this is observed.
I (Independent). The PBI should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
N (Negotiable). A good PBI should leave room for discussion regarding its optimal implementation.
V (Valuable). The value a PBI delivers to stakeholders should be clear.
E (Estimable). A PBI must have a size relative to other PBIs.
S (Small). PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
T (Testable). Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.
• All stories have a value statement (As a
• All stories have acceptance criteria
• All stories have been refined by the team prior to Iteration Planning
• All stories have been sized by the team
Definition of Done
In software, a Definition of Done 1 describes the tasks needed for every new functionality, regardless of size or request.
• Every task under the User Story has been completed
• Unit tests all pass
• At least one other team member has performed a peer review
• User documentation is updated
• Deployed to UAT
In a non-development context, the DoD is still a list of non-functional requirements that are required to be completed before work is considered complete.
• Steps to recreate are documented
• Steps to solve the problem are documented
• Customer satisfaction rating is documented
VALUE DELIVERY
The entire goal of the work processes is to deliver value.
"Working software is the primary measure of progress." - Agile Principle #7 1
The events for review are Iteration Review 3 at the Team Level and System Demo 4 at the Program Level.
Iteration Review
System Demo
FOUNDATIONAL VALUES
.
All of the above practices and processes are based on the principles and values of Lean Thinking, Empiricism and Metrics, and The Agile Manifesto.
Empirical Data/Metrics
Without empirical data and metrics, decisions will be made with incomplete or erroneous information.
"Empiricism 1 asserts that knowledge comes from experience and making decisions based on what is observed."
Lean Thinking
Based on Lean Thinking in manufacturing, we can eliminate waste by mapping our processes and identifying areas of improvement.
"The Lean-Agile Mindset 1 is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices."
"Lean thinking 2 reduces waste and focuses on the essentials."
EXPECTATIONS OF CMS
.
As an Application Development Organization (ADO), you are expected to deliver value. However, CCSQ will provide you with the information and support you need to be successful.
Expected of CMS
The following artifacts should be created and maintained by CMS (Business Owners, Solution Management, Product Management) and should be provided to ADOs and other Stakeholders.
Vision
The Vision 1 is a description of the future state of the Solution under development. It reflects customer and stakeholder needs, as well as the Feature and Capabilities proposed to meet those needs.
Operational Value Stream Map
Operational Value Streams 1 (OVS) are the sequence of activities needed to deliver a product or service to a customer.
Objectives and Key Results (OKRs)
Objectives and Key Results, or OKRs, for short, are plain language goals and the measures of success for those goals. How do we know what the goal is? How do we know if reached the goal? Does everyone agree on what success is?
The goal of using OKRs for strategic themes 1 is to define and track their progress through concrete, specific, and measurable actions. “OKRs are frequently set, tracked, and re-evaluated – usually quarterly. OKRs exists to create alignment and to set the cadence for the organization. The goal is to ensure everyone is going in the same direction, with clear priorities, in a constant rhythm.”
Program Backlog
The Program Backlog 1 is the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train 3 (ART). It also contains the enabler features necessary to build the Architectural Runway 2.
The Program Backlog is created, refined, and prioritized by Product Management 4. To learn more about Program Backlog Management, the LACE offers the following trainings:
Expected of Software Development Partners
Team Backlog
Organizing your work into a digestible, transparent artifact is not difficult. The Team Backlog 1 is the primary repository for managing work items. Specifically, User Stories 2. User Stories are discreet value propositions of a larger Feature or Enabler 4 from the Program Backlog 3. All User Stories will be tracked in Jira. This is because the CMS Jira implementation is able to read Jira projects and collect and collate pertinent metrics associated with team effectiveness.
Value Artifacts
All of the source code, infrastructure as code, documentation, dependencies, and everything else used to create the Value belong to CMS. As such, all repositories, Confluence spaces, etc. are to be provided to CMS.
Required Artifacts:
Personas
"A Persona is a fictitious character embodying a segment of real-world users of your product, website or service. It is based on information gathered via research, both qualitative and quantitative."HCD Research Methods
HCD practices include many research and testing methods. All artifacts from these methods need to be stored, preferably in Confluence, and available for interested parties and stakeholders.
A comprehensive list of these practices can be found in the HCD Space.
DevOps Metrics
While Team effectiveness metrics are gleaned from Jira projects, DevOps metrics must be provided.
- Deployment Frequency
- Deployment Lead Time
- Mean Time To Restore
- Deployment Failure Rate
Development Value Stream Map
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence.
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence. Learn more about Value Stream Mapping to request the LACE Value Stream Mapping Workshop
PROVIDED TO CMS
.
Team Backlog
Organizing your work into a digestible, transparent artifact is not difficult. The Team Backlog 1 is the primary repository for managing work items. Specifically, User Stories 2. User Stories are discreet value propositions of a larger Feature or Enabler 4 from the Program Backlog 3. All User Stories will be tracked in Jira. This is because the CMS Jira implementation is able to read Jira projects and collect and collate pertinent metrics associated with team effectiveness.
Value Artifacts
All of the source code, infrastructure as code, documentation, dependencies, and everything else used to create the Value belong to CMS. As such, all repositories, Confluence spaces, etc. are to be provided to CMS.
Required Artifacts:
Personas
"A Persona is a fictitious character embodying a segment of real-world users of your product, website or service. It is based on information gathered via research, both qualitative and quantitative."HCD Research Methods
HCD practices include many research and testing methods. All artifacts from these methods need to be stored, preferably in Confluence, and available for interested parties and stakeholders.
A comprehensive list of these practices can be found in the HCD Space.
DevOps Metrics
While Team effectiveness metrics are gleaned from Jira projects, DevOps metrics must be provided.
- Deployment Frequency
- Deployment Lead Time
- Mean Time To Restore
- Deployment Failure Rate
Development Value Stream Map
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence.
Getting the software value into production is just as important as the software value, itself. Automation, quality gates, package bundling and installation, and software scanning help increase quality and speed of delivery.
Mapping out the Development Value Stream 1 is critical to understand the system and where to focus on improvement opportunities.
All ADOs are required to create and maintain a Development Value Stream Map. This should be available in Confluence. Learn more about Value Stream Mapping to request the LACE Value Stream Mapping Workshop
Team Readiness Checklist
.
As a Software Development Partner, the expectations explained above should be understood and achieved. Below is a checklist to understand the health and completeness of the team(s). This is by no means an exhaustive list, nor is it a measure of success, on it's own. This is a basic list to help teams get started. All the information and artifacts should be transparent and communicated to CMS.
Artifacts
Do all of the teams have:
- Definition of Done
- Working Agreement
- Definition of Ready
- Calendar of Scrum Ceremonies
- Team Roster with contact information
Work Management
Do all of the teams have:
- Jira Project with Team Backlog
- The Team Backlog feeds into the metrics dashboard
Source Code
Do all of the teams have:
- GitHub Repo(s)
- Documentation
- Technical
- Installation/Packaging
- Architecture
DevOps
Do all of the teams have:
- DevOps Metrics
- Development Value Stream
What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class? What is Mission Impact? How can we use it to determine the importance of the work we do? When every requirement is critical, it can be difficult to know what to do first. There is a common misconception that design and development are at odds. One prioritizes understanding and the other prioritizes solutioning. Lean, agile, and human-centered design philosophies are meant to be complementary approaches to getting work done. During this three-hour course, co-facilitated by the CCSQ Lean-Agile Center of Excellence (LACE) and the Human-Centered Design Center of Excellence (HCD CoE), attendees will discuss and explore how teams can thoughtfully integrate design and development needs, share responsibility, and achieve a balanced approach to delivery. Who is this training for? Are there any pre-requisites for taking this class?
Upcoming Events
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Scrum Master Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Product Owner Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Systems Architect Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Product Manager Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Product Manager Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Team Member Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) OKRs Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) DevOps Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) SAFe Basics Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Scrum Basics Training
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) Coaching Corner
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET) User Story Clinic
to schedule a private course, or to request that a public course be scheduled.
Training/Event
Description
Date(s)
Time
Registration
LACE Community Event: Mission Impact
Understanding Mission Impact creates essential face-to-face dialogue between teams and their key interested parties, ensuring everyone understands the priorities and the rationale behind them.
During this, Lean-Agile Center of Excellence Community Event, we will discuss how to interpret Mission Impact and how it can help the Civic Community stay focused on work that matters.1:00 PM - 2:00PM (ET) UX & Agile for Software Development
1:00 PM - 4:00PM (ET)