ML23047A546
| ML23047A546 | |
| Person / Time | |
|---|---|
| Issue date: | 01/04/2022 |
| From: | NRC/OCIO |
| To: | |
| References | |
| Download: ML23047A546 (1) | |
Text
U.S. NRC Agile Delivery Cookbook MVP 1.0
Minimum Viable Product (MVP) Name:
Agile Delivery Cookbook Product Vision:
Provide standardized digital IT repurposable Agile delivery processes to align with the modern IT operations.
Product Objectives:
NRC is leading an effort to transition to modular approach to agile-based development and a significantly shortened time to value. The Agile Delivery Cookbook will address the challenges of inconsistent legacy processes across the teams and provide a reusable centralized framework for teams to inherit towards their Agile delivery strategy.
MVP success criteria:
Train the Product Managers and their teams on the Agile Delivery cookbook as a pilot.
Conduct the bi-weekly lessons learned check ins with individual teams. Collect the feedback on what is working well and what is not working well.
Evolve from the pilot.
Expand the pilot to other groups within NRC.
Record of Changes:
Version Number Date Author/Owner Description of Change 1.0 01-04-2022 Jyothi Padala Agile Delivery Cookbook MVP 1.0
Goal:
The goal of the Agile Delivery Playbook is to define standard operational norms and best practices that all teams within the program are expected to follow. Having consistent processes in place will help us collaborate more effectively with each other, our stakeholders, and other projects within the broader enterprise-wide initiatives.
Effective practices:
Start with Agile guidance and an Agile adoption strategy.
Enhance migration to Agile concepts using Agile terms, such as user stories (used to convey requirements) and Agile examples, such as demonstrating how to write a user story.
Continuously improve Agile adoption at both the project level and organization level.
Seek to identify and address impediments at the organization and project levels.
Obtain stakeholder/customer feedback frequently.
Empower small, cross-functional teams.
Include requirements related to security and progress monitoring in your queue of unfinished work (the backlog).
Gain trust by demonstrating value at the end of each iteration.
Track progress using tools and metrics.
Track progress daily and visibly.
Scrum Framework Why Scrum?
Scrum is a lightweight framework for agile software development, which allows us to collaborate on complex problems while remaining responsive to evolving business needs. We also believe that the scrum values align with the values we want to embrace as a program:
Scrum Lifecycle:
A project managed using the Scrum life cycle has several phases and when it is accomplished correctly, it improves the potential for project success. These phases are planned, designed, and executed using requirements discovered by the users and implemented by the Scrum Team.
Product Vision:
The Product Vision plays an important role in bringing a new product to life: it acts as the shared, overarching goal guiding everyone involved in the development effort.
Discovery:
The whole team is involved.
Gain Stakeholder acceptance on the requirements.
Outline the customer journey, mock-up product designs, map product dependencies and share work with the Stakeholders.
Product Backlog: Functional and Technical (Non-Functional) requirements.
Release strategy: Release strategies are used as a risk mitigation strategy for Scrum projects. Setting up a release strategy facilitates early demonstrations of software to the users, and it also permits the grouping of final acceptance activities which reduces schedule.
Sprint Planning:
Work targeted for completion in one iteration.
Sprint Review:
Users examine and approve working software before moving to production.
Deployment:
Each sprint could be delivered but would not be delivered to the customer until there is business value.
Roles Product team roles Overview Product Team - Core Product Owner (PO)
Scrum Master (SM)
Development Lead (DL)
Test Lead (TL)
BA Lead (BL)
Shared Resource Teams UX (Content, Art Direction, Usability Research, Information Architect, etc.)
Security Accessibility/508 Other roles supporting Operations Other Stakeholders (Business Owners, Leadership, End Users etc.)
The Product Manager (aka Product Owner)
At NRC, the Product Manager is the member of the Product Team charged with maximizing the value of the teams work. The Product Manager holds the product vision and works closely with stakeholders, such as end users, customers, and the business to cultivate and nurture a community around the product. They describe what should be built and why, but not how. Their responsibilities include:
Representing the needs and desires of the stakeholder community Establishing the products success criteria Prioritizing the product and sprint backlog Determining when initiatives, epics and stories are done Cultivate and matures epics and stories Responsible for keeping the products deliverable on schedule
The Scrum Master (aka Delivery Manager)
The Scrum Master is a servant leader, helping the rest of the Scrum team progress. In many cases the Scrum Master also serves as what NRC usually would consider a Project Manager (Contractor resource).
Their responsibilities include:
Ensuring the team adheres to NRCs Agile processes Runs Agile meetings (daily standups, sprint planning, program increment planning, retrospectives, etc.)
Resolution / escalation of inadequate or ill-defined user stories as well as ensuring Product Owner accountability Removing barriers and shielding the team from external interference Assists Product Owner with keeping the project on task and on target and manage risks Creates documentation and visuals that denote product status The Development Team Scrum framework does not define any other roles on the team besides the Product Owner and the Scrum Master. The rest of the team is all considered part of the Development Team, which is expected to be a cross-functional, self-organizing team, responsible for taking the highest priority items from the backlog and turning them into increments of potentially releasable functionality. The development team should be between 3 to 9 people.
The Development Lead The Development Lead is responsible for managing the Development Team. While the Development Team is focused 100% on development, the Development Lead is the face of the Development Team and acts as their proxy. Their responsibilities include:
Helps clarify user story requirements to development team Ensures development team is following coding best practices Works with Development team to determine story point estimates and works with them to deliver the items in the sprint backlog at the end each Sprint.
Attends Agile meetings (daily standups, sprint planning, program increment planning, retrospectives, etc.)
Removes barriers and shields the Development Team from external interference In limited cases provides technical support Writes or approves technical documentation and diagrams The Test Lead The Test Lead is responsible for coordinating the testing efforts required for a product. Their responsibilities include:
Work with Test Manager to ensure testing resources are allocated for releases and ticket level testing Write and manages test scenarios / test data / test scripts / regression suites required to have 100% test coverage for requirements Works with Test Manager to determine which type of regression suite should be run before a release Helps Product Owner know when to bring in other types of testing resources (Performance, Security etc.)
Attends Agile meetings (daily standups, sprint planning, program increment planning, retrospectives, etc.)
Validate stories and acceptance criteria to ensure they can be tested properly Teaches others how to test the product The Business Analyst Lead The Business Analyst Lead is responsible for the completeness and accuracy of a product's requirements (epics, stories, etc.). Their responsibilities include:
Helping to clarify user stories to the Product Team Ensures stories and epics adhere to Agile conventions Works with Product Owner and Stakeholders to capture requirements accurately and ensure acceptance criteria describes the done state.
Coordinates with other BAs and Shared Resource teams to assist with story and epic writing Helps Product Owner determine when a story is done Manages and maintains Product documentation (Confluence & Jira)
Shared Resources Shared Resources are responsible for different areas of expertise to ensure a product is following industry and federal best practices and standards. Leads for the different Shared Resources are experts in their specific area and can make decisions to assist the Product Owner with delivering a successful product. Examples of Shared Resources are as follows:
System Integrator (SI)
Visual Design / User Experience Analytics & Monitoring Accessibility & 508 Cloud & Infrastructure
Stakeholders End Users, NRC Leadership, Business Owners, Subject Matter Experts (SMEs), External Stakeholders (Other Agencies etc.)
Ceremonies All ceremonies in scrum are time-boxed with a set maximum duration. Other than the sprints themselves, each ceremony is intended to provide an opportunity to inspect and adapt, increasing transparency within the team and throughout the organization.
Sprint The sprint is time-boxed (two, three, or four weeks), during which the development team works towards creating a potentially shippable increment of the product. Each sprint includes Sprint Planning, Daily Stand-ups, work on the Sprint backlog, the Sprint Review, and the Sprint Retrospective. The team should work with the Product Owner to set a goal for each sprint. While scope can be re-negotiated as the team learns more during the sprint, these changes should not endanger the sprint goal.
Sprints are durations of time typically 2-weeks where requirements are locked, and the development team is completing user stories and NFRs.
Sprints are used for planning and completing user stories, NFRs and tasks Deployments/releases often happen at the end of a sprints - but they dont always have to; Release can happen whenever stories or NFRs are completed Estimating how many user stories and NFRs can be completed within a Sprint is based on the teams velocity For user stories and NFRs to be worked on in a sprint, they must have all the requirements and acceptance criteria and have a story point estimate Note: On a program, all teams can use two-week long sprints. Each Program Increment lasts for 3, two-week sprints. There is a one-week planning Sprint in between program increments, which includes Program Increment planning and additional time for teams to do a more detailed breakdown of the work they will need to do in support of the program features planned at PI Planning. Sprints could run at the same cadence across all the teams.
Sprint Planning The goal of the sprint planning ceremony is to plan the work that the team will do in the upcoming sprint. This plan is collaboratively created by the entire team and is not something the Scrum Master and/or Product Owner define for the Development Team. There are two main questions the team should focus on answering during sprint planning:
- 1. What are we able to deliver in this sprint?
- 2. How are we going to deliver that?
The first question should be answered by reviewing the overall product backlog, which has been prioritized by the Product Owner, ensuring these tickets are estimated appropriately, and then forecasting how many of the top priority items can be completed in the upcoming sprint based on the team's velocity. While discussing how the team is going to deliver the selected user stories, they should think through all of the work required to meet their definition of done, and ask clarifying questions of the Product Owner if the requirements for the user story are not clear.
The team should also set a sprint goal during sprint planning. The sprint goal is a higher-level objective for the sprint, that can be met by implementing the items selected for the sprint backlog. This helps the team stay focused throughout the sprint and allows them to renegotiate specific stories within the sprint if needed, so long as they are still able to achieve the overarching sprint goal.
Daily Standup The daily standup is time-boxed to 15 minutes and is intended to allow the Development Team to align on the progress they've made in the sprint so far and optimize their collaboration on the work remaining within the sprint. While there are multiple formats teams can use for their stand-ups, one common approach is for everyone to share their answers to the following three questions:
- 1. What work have I done towards achieving the sprint goal since our last standup?
- 2. What work do I plan on doing to help us achieve the sprint goal before our next standup?
- 3. What blockers are preventing me, or the larger team, from making the needed progress towards our sprint goal?
The daily standup is for the development team to coordinate their work as a self-organizing team. While others can (and often do) attend the standup, the Scrum Master should ensure they do not disrupt or derail the standup meeting.
Sprint Review The sprint review is held at the end of each sprint to inspect and adapt the work completed during the sprint, as well as any impact this has on the overall product backlog. The sprint review should include the full scrum team but can also include other Stakeholders that are invited by the Product Owner. The development team should demonstrate that work that has been "done". Any work that was not completed during the sprint should be returned to the product backlog and reprioritized by the Product Owner, since it may not automatically be the highest priority for the next sprint. Based on this conversation, and any other changes the Product Owner has for the product backlog, the group can begin to collaborate on what should be worked on next, providing valuable input into the Sprint Planning meeting for the next sprint.
Sprint Retrospective The sprint retrospective is an opportunity for the team to inspect and adapt how they are working and identify opportunities for continual improvement. The retrospective should occur after the sprint review, but before sprint planning. While the scrum master needs to ensure that this meeting occurs and is productive, the scrum meeting doesn't have to be the facilitator, and should also participate as a
peer member of the scrum team. One way to guide the conversation during the retrospective is to ask the team:
- 1. What went well during this past sprint?
- 2. What could have gone better?
- 3. What do we want to change or improve for next sprint?
At the end of the sprint retrospective, the team should agree on actionable improvements that they will implement in the next sprint. It is often better to pick a few improvements to focus on for each sprint, rather than try to tackle everything that comes up during the retrospective.
Artifacts Product Backlog The product backlog is a prioritized list of everything that is known to be needed in the product. The product owner is responsible for setting the priority of the items within the product backlog. The product backlog should list all known features, functionality, fixes, improvements, and enhancements that are planned for the product. However, the product backlog will never be complete, as it is continuously evolving based on product feedback, business or market changes, and emerging technologies or opportunities.
The backlog should be regularly refined in coordination with the scrum team and the product owner, ensuring that the description of the backlog items is clear and that the estimates are accurate. Items near the top of the product backlog should be clearer and more detailed than items with lower priority.
While items that are likely to be worked on in the next sprint or two should be at a detailed user story level, with clear point estimates, items near the bottom of the backlog may only exist at a feature level, with a vague sense of what needs to be done and how much work that will entail.
Teams' product backlogs should be maintained within their respective JIRA boards and are visible using JIRA's "Backlog" view within the project.
Sprint Backlog The sprint backlog is the set of user stories from the product backlog that the team has planned to work on for the Sprint. The sprint backlog comes out of the sprint planning meeting but may be updated throughout the sprint if new work is discovered that is required to meet the sprint goal. The development team should also use the sprint backlog to ensure their progress throughout the sprint is visible, tracking tickets from "To-Do" to "In Progress" to "Done" (note: some teams may use additional states for tracking the tickets during the sprint, but at a minimum those three should be included).
Teams' sprint backlogs should be maintained within their respective JIRA boards and are visible using JIRA's "Active sprints" view.
Artifact Transparency - Definition of "Done" Teams should define what it means for a backlog item or product increment to be "Done". Having a common definition for what it means to be "done" helps ensure alignment across the development team, the product owner, and other stakeholders. At the backlog item level, this should include meeting the ticket's acceptance criteria, completing appropriate testing, and passing required peer reviews. At a product increment level, this should include regression and integration testing, along with any other requirements needed to release the updated product into production.
Requirements Overview Initiatives Leadership decisions to commit to a large chunk of work for a specific product. Initiatives can either be related to business functionality for an end user or architectural in nature for example, work that would bring operational efficiency. Initiatives can take multiple programs increments to complete.
Epics Take Initiatives and unpack them into tangible deliverables that can be completed within a program increment. Epics are also either related to business functionality or architectural necessity.
User Stories Take business-related epics and unpack them into demo-able deliverable that can be completed within a sprint.
A recommended format for writing epics/user stories:
As a <role or user>,
I want <some feature or requirement>
In order to <do something or achieve some objective>.
Acceptance Criteria Acceptance criteria are requirements that must be met for a story to be considered complete. Acceptance criteria are incredibly important because they spell out what a Product Owner (aka Product Manager) expects and what a team needs to accomplish.
This <epic/user story> will be considered acceptable when the following outcomes have been provided:
- 1. Conditions of Satisfaction #1
- 2. Conditions of Satisfaction #2
- n. Conditions of Satisfaction #n
Tasks & Sub-Tasks Teams can choose to decompose the user stories to a more granular level. Typically, each user story will have multiple associated tasks and/or sub-tasks. Sometimes these will be created by function, such as design, code, test, document etc.
Non-Functional Requirements (NFRs)
Take architectural-related epics and unpack them into completable tasks that can delivered during a sprint.
NFR Type NFR Summary NFR Description Access Gain access as a user to an application/system.
Steps to follow to get access to an application/system Initial Setup Application (One time)
Infrastructure Setup Steps to follow including which team to reach out for support Initial Setup Application (One time)
Security: Penetration Testing Steps to follow including which team to reach out for support Initial Setup Application (One time)
Security: Compliance Scan Steps to follow including which team to reach out for support Initial Setup Application (One time)
Security: Vulnerability Scan Steps to follow including which team to reach out for support Initial Setup Application (One time)
Performance Testing Steps to follow including which team to reach out for support Initial Setup Application (One time) 508 Testing Steps to follow including which team to reach out for support Initial Setup Application (One time)
Setup Monitoring Steps to follow including which team to reach out for support Initial Setup Application (One time)
Setup logging Steps to follow including which team to reach out for support Repeatable NFRs for each release Security: Penetration Testing Steps to follow including which team to reach out for support Repeatable NFRs for each release Security: Compliance Scan Steps to follow including which team to reach out for support Repeatable NFRs for each release Security: Vulnerability Scan Steps to follow including which team to reach out for support Repeatable NFRs for each release Performance Testing Steps to follow including which team to reach out for support Repeatable NFRs for each release 508 Testing Steps to follow including which team to reach out for support Repeatable NFRs for each release Confirm Monitoring Steps to follow including which team to reach out for support Repeatable NFRs for each release Confirm logging Steps to follow including which team to reach out for support
Requirements Hierarchy Requirements Estimation Requirements are estimated based on a t-shirt size metaphor. Each t-shirt size is equal to an amount of story points:
1 story point - X-Small (XS) 3 story points - Small (S) 5 story points - Medium (M) 7 story points - Large (L) 13 story points - X-Large (XL)
The Product Teams associates a t-shirt size with all requirements to help determine a teams velocity.
Note: The story point estimate is not associated with hours or resources and is purely gut feeling of effort and complexity. Velocity over time is the method used for determining how much can be done in a program increment or sprint. The story point numerical value is only used to determine a velocity.
Story Point is an arbitrary measure used by the Scrum Teams to measure the effort required to implement a user story. Agile estimates are performed by the Scrum Team and are used to gauge complexity. Estimates are starting point from which releases and sprints can be planned and managed.
They become more accurate over time as the past performance information emerges throughout the
project. In simple terms, its a number that tells the team how hard the user story is to implement.
Consider the following when using story points:
Size is easier to estimate than duration Estimation works by comparing user stories Estimation works when hours, dollars, and people are eliminated When estimating story points for tickets, teams should use relative sizing to determine their estimate, considering the effort, risk, complexity, and unpredictability involved. The goal is to understand a high-level estimate for the work involved. This is encouraged using the Fibonacci sequence comprising of integers where each number is equal to the sum of the previous two. The modified Fibonacci sequence for Agile (normally used) is 1, 2, 3, 5, 8, 1, 15, 20, 35, 50.
The following table provides general guidelines that can be used to help teams get a sense for how to point their tickets. Since this table is only showing hours, this assumes that risk and unpredictability are minimal, and the primary factor driving the estimate is the effort involved. Please make sure to take all factors into account when pointing tickets.
Story Points Time Estimate
.5
~1/4 day, generally used in association with administrative tasks 1
~1/2 day 2
~1 day 3
~1.5 days 5
~1/2 week 8
~1 week, recommend breaking down into smaller pieces before pulling into a sprint 13
~1.5 weeks, recommend breaking down into smaller pieces before pulling into a sprint 20+
>2 weeks, needs to be broken down into smaller pieces before being pulled into a sprint