Column |
---|
|
Tabs Container |
---|
|
Tabs Page |
---|
| Welcome to the CCSQ Community! As an Application Development Organization (ADO) with CMS, your expertise is critical to delivering value to the American taxpayer. In alignment with the agile values and principles, CCSQ uses the Scrum and Scaled Agile Frameworks (SAFe) as a guide for standardized processes. The information provided in this Onboarding Guide highlights CCSQ's standards and expectations for operating within these frameworks. More comprehensive information is found in the Scrum Guide and the Scaled Agile Framework websites. Rely on your program leadership, Agile coaches, and Release Train Engineers to provide guidance and training when needed. |
Tabs Page |
---|
| ORGANIZATION Excerpt Include |
---|
| Organization |
---|
| Organization |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| WORK STRUCTURE
Tabs Container |
---|
title | Managing Work |
---|
direction | horizontal |
---|
|
Tabs Page |
---|
|
Work Item Management Basics
Ownership is taken, not given.
Scaled 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 quality.The Definition of Ready and theDefinition 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 theDefinition of Done defines when the work is done, and therefore ready, for the next phase of the process.Whoever is working it owns it.
At 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 status
Because 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:EpicsFeaturesStoriesTasks
Requirements that can exist at multiple levels of the hierarchy: ObjectivesEnablers
Use the menu at the top to see the CCSQ Standards for defining and managing each work item type |
---|
References used in this article:
HTML |
---|
1 - Scaled Agile Framework - Epic <a href="https://www.scaledagileframework.com/epic/" target="_blank">https://www.scaledagileframework.com/epic/</a>
<br/><br/>
2 - Scaled Agile Framework - Feature <a href="https://www.scaledagileframework.com/features-and-capabilities/" target="_blank">https://www.scaledagileframework.com/features-and-capabilities/</a>
<br/><br/>
3 - Scaled Agile Framework - Story <a href="https://www.scaledagileframework.com/story/" target="_blank">https://www.scaledagileframework.com/story/</a>
<br/><br/>
4 - Definition of Done <a href="https://qnetconfluence.cms.gov/display/LACE/Definition+of+Done" target="_blank">https://qnetconfluence.cms.gov/display/LACE/Definition+of+Done</a>
<br/><br/>
5 - Scaled Agile Framework - Strategic Themes <a href="https://www.scaledagileframework.com/strategic-themes/" target="_blank">https://www.scaledagileframework.com/strategic-themes/</a>
<br/><br/>
6 - Scaled Agile Framework - Continuous Delivery Pipeline <a href="https://www.scaledagileframework.com/continuous-delivery-pipeline/" target="_blank">https://www.scaledagileframework.com/continuous-delivery-pipeline/</a>
<br/><br/>
7 - Scaled Agile Framework <a href="https://www.scaledagileframework.com/" target="_blank">https://www.scaledagileframework.com/</a>
<br/><br/>
8 - Scaled Agile Framework - Portfolio Kanban <a href="https://www.scaledagileframework.com/portfolio-kanban/" target="_blank">https://www.scaledagileframework.com/portfolio-kanban/</a> |
|
Tabs Page |
---|
| Objectives
HTML |
---|
<img class="learning" alt="OKR Workshop" title="OKR Clinic" onclick="showTrainingPopup('okrs-training');"/>
|
"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. |
|
Tabs Page |
---|
| Epics
HTML |
---|
"An <a href="https://www.scaledagileframework.com/epic/" target="_blank">Epic </a><span class="sup">1</span> is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio." Epics are too large to fit into a single PI and may take multiple PIs to deliver.
<br/><br/>
<div>
Below is the recommended Portfolio Kanban configuration, taken from the <a href="https://www.scaledagileframework.com/" target="_blank">Scaled Agile Framework</a><span class="sup">7</span>. You can see that Epics move through the <a href="https://www.scaledagileframework.com/portfolio-kanban/" target="_blank">Portfolio Kanban </a><span class="sup">8</span> to bring visibility into the progress of the Epic work.
<br/><br/>
<img src="https://www.scaledagileframework.com/wp-content/uploads/2020/08/Portfolio-Kanban_F02_WEB-2.png" style="width:900px;height:546px"/>
</div>
|
|
Tabs Page |
---|
|
"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. At all levels, the work can be created as an Enabler issue type in Jira, but at the Epic and Feature level, enablers must use labels to align the work with SAFe standard enabler types. The appropriate label should be applied to all enabling features and epics, using one of the labels below:
|
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 |
|
Tabs Page |
---|
| Features"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. |
Feature OwnershipFeatures 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 Product 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 |
---|
Program / Team/ Anyone | New (Big Idea) | Funnel | Solution Management Team | New | Analyzing | PDM- Product Manager | New | Program Backlog | PDM/ Feature Owner | New | Implementing | PDM/ SMT | In progress/ ready | Validating on staging | PDM/ SMT | Deployment testing / prod environment | Deploying to Production | PDM/ Feature Owner | Definition of Done and meet acceptance criteria | Releasing | PDM/ SMT | Feature released to the customer | Done |
*Only the Feature Owner and Product Manager have the authority to abandon or close a feature
Jira Board ConfigurationGiven 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.
|
Tabs Page |
---|
| User Story Ownership
"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. |
The recommended story states, definition ands and mapping to the primary status categories in Jira are defined in the table below:
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 | Jira User Story Workflow Setup
Image Added | 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 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 Test: | All development tasks are complete, the code has been reviewed, integrated, and deployed to the test environment. | In Progress | 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 | Done: | The Product Owner has validated the Acceptance Criteria and approves the story for deployment | 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 | New | Ready | Developer | Ready | In Development | Developer 1 | Development | Ready for Peer Review | Developer 2 | Peer Review | Ready for Test, Development | Tester | Testing | In Development, Ready for Acceptance | Product Owner | Ready for Acceptance | Done | Product Owner | <any state> | Abandoned* |
|
Tabs Page |
---|
|
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 |
|
|
|
Tabs Page |
---|
| COLLABORATION Excerpt Include |
---|
| Collaboration |
---|
| Collaboration |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| SOCIAL CONTRACTS
Excerpt Include |
---|
| Social Contracts |
---|
| Social Contracts |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| VALUE DELIVERY Excerpt Include |
---|
| Value Delivery |
---|
| Value Delivery |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| FOUNDATIONAL VALUES Excerpt Include |
---|
| Foundational Values |
---|
| Foundational Values |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| EXPECTATIONS OF CMS Excerpt Include |
---|
| Expectations of CMS |
---|
| Expectations of CMS |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| PROVIDED TO CMS Excerpt Include |
---|
| Provided to CMS |
---|
| Provided to CMS |
---|
nopanel | true |
---|
|
|
Tabs Page |
---|
| Team Readiness Checklist Excerpt Include |
---|
| Team Readiness Checklist |
---|
| Team Readiness Checklist |
---|
nopanel | true |
---|
|
|
|
|
|