Attch J7 - Agile Methodology.pdf

1. Agile at the Library

1.1 The Agile Manifesto

1.2 12 Principles of Agile

1.3 Scrum

1.3.1 Getting Started with Scrum

1.3.1.1 The Product Vision

1.3.1.1.1 Minimal Viable Product (MVP)

1.3.1.2 Project Roadmaps

1.3.1.2.1 The Product Roadmap

1.3.1.2.2 The Feature Roadmap

1.3.1.3 Release Planning

1.3.1.4 Team Norms

1.3.1.5 Agile Coaching & User Story Mentoring

1.3.2 Roles and Responsibilities

1.3.2.1 Core and Extended Scrum Teams

1.3.2.2 Scrum Master

1.3.2.3 Scrum Team Member

1.3.2.4 Product Owner

1.3.2.5 Stakeholders

1.3.3 The Sprint Cycle

1.3.4 Scrum Ceremonies

1.3.4.1 Sprint Planning

1.3.4.2 Daily Standup

1.3.4.3 Backlog Refinement

1.3.4.4 Sprint Review

1.3.4.5 Sprint Retrospective

1.3.5 Scrum Artifacts

1.3.5.1 Sprint Backlog

1.3.5.2 Product Backlog

1.3.5.3 Product Backlog Items

1.3.5.3.1 Epics & Features

1.3.5.3.2 The User Story

1.3.5.3.3 Tasks

1.3.5.3.4 Splitting Techniques for Product Backlog Items

1.3.6 Definitions of Ready and Done

1.3.6.1 Definition of Ready for Refinement

1.3.6.2 Definition of Ready for Sprint Planning

1.3.6.3 Definition of Done (DoD)

1.3.6.3.1 Formal Acceptance of Work

1.3.6.3.2 User Acceptance Testing (UAT)

1.3.7 Estimation

1.3.7.1 Estimating Product Backlog Items

1.3.7.1.1 Relative Sizing

1.3.7.2 Team Capacity Planning

1.3.8 Metrics

1.3.8.1 Sprint Burndown

1.3.8.2 Version Report

1.3.8.3 Predictability

1.3.8.4 Productivity

1.3.8.5 Defects

1.3.8.6 Team Velocity

Attachment J7 - Agile Methodology 11/26/2025

Agile at the Library Welcome to Agile at the Library

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile methods or Agile processes generally promote a disciplined project management process that encourages frequent inspection, adaptation, and improvement, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Agile development refers to any development process that is aligned with the concepts of the Agile Manifesto.

Why Agile Works

Agile software development provides opportunities to assess the direction of a project throughout the software development lifecycle (SDLC), including creating a vision for the product and visualizing the work required to make it. Planning allows teams to identify the amount of work needed for a shippable product and when the product can potentially be released. Regular cadences of work allow teams to deliver incrementally. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, development teams are able to provide finished product frequently and continuously improve on the way the work is completed. In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc.

— is continually revisited throughout the SDLC. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.

Topics:

The Agile Manifesto 12 Principles of Agile

Agile Frameworks:

Scrum Kanban Scaling Agile at the Library DevOps

The Agile Manifesto

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

12.

The was created by a group of 17 experienced Manifesto for Agile Software Development software development practitioners in 2001. Using their combined experience and expertise, and despite differing views, the signatories of the were solidly in consensus onManifesto that comprise the whole of the document, which is as follows:four core values

"We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

over processes and tools Individuals and interactions over comprehensive documentation Working software over contract negotiation Customer collaboration over following a planResponding to change

That is, while there is value in the items on the right, we value the items on the left more."

12 Principles of Agile

The 12 Principles behind the are guiding practices that support teams in successful adaption and Manifesto for Software Development implementation of agility in software development.

Customer satisfaction by early and continuous delivery of valuable software.

Welcome changing requirements, even in late development.

Deliver working software frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the primary measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly

Scrum

Welcome to Scrum

Scrum is an Agile software development methodology used for managing complex work, which emphasizes small teams, collaboration and iterative development. The articles in this section describe Scrum practices.

Topics:

Further Reading

Agile Essentials https://www.agilealliance.org/agile-essentials/

Getting Started with Scrum

Roles and Responsibilities

The Sprint Cycle

Scrum Ceremonies

Scrum Artifacts

Definitions of Ready and Done

Estimation

Metrics

Getting Started with Scrum

Planning your Agile Project

Many teams believe that going Agile eliminates the need to plan out what they're going to work on. This is a common misconception. While Agile values "Responding to Change over Following a Plan", it's important to note that the comparative word used in this statement is "over" and not "instead of". Responding to change is important and Scrum provides the structure to allow this to happen in an orderly fashion, but planning is still a part of the Scrum methodology. The following articles will guide you and your team in identifying important goals and milestones to successfully build software that meets your mission and business objectives.

Articles in this section:

Further Reading

The Scrum Guide https://www.scrumguides.org/scrum-guide.html

Product Vision Project Roadmaps

Product Roadmap Feature Roadmap

Release Planning Team Norms Agile Coaching/User Story Mentoring

The Product Vision

The Product Vision is a short statement that describes the end goals, objectives, and benefits of a product. It is need to ensure the product is moving in the right direction and that strategies are aligned so the development team can focus on creating the right product.

The is responsible for creating the Product Vision statement and socializing Product Owner it with and the .stakeholders Core and Extended Scrum Teams

The statement should be compelling, align with the organization's mission and strategy, and consider business and product objectives. , at left, is an example of a Product Figure 1 Vision statement. It includes the following elements

Who: The customer who will use your product How: Description of how the customer will use the product What: The name of the product and a description of how the product meets the customer's needs Why: A description of why your product is valuable, and if applicable, a differential statement about how your product is more valuable than your competitors.

Minimal Viable Product (MVP)

What does Minimal Viable Product (MVP) really mean?

During the definition of the product vision, stakeholders will often begin to introduce a set of features to be developed for the solution. This set of features is sometimes referred to as "MVP." Below we explore the term to ensure alignment on its meaning.

Minimum Viable Product (MVP) is a term coined by Eric Ries over 10 years ago to define the lean startup concept of delivering to the market a solution for customers that can be quickly adapted based on user feedback. It is meant to be a solution delivering only core features for early adopters to use with a clear expectation that additional features will eventually emerge. The concept allows us to test an idea by exposing an early version of the product to the target users. There is an expectation that the developers will get feedback on the value of the initial features and in return will provide the next highest-value features in return. This is aligned to the Agile concept of fail early in that we are able to quickly see if our ideas about how to address a user's needs are accurate.

As the circumstances surrounding its creation suggest, MVP is meant to be applied to solutions that have no equal already in the marketplace. It's most appropriate a definition of core features applied to a new product that is just emerging in the market, though we often a pply it to replacements (or upgrade) of a solution that already has a complete feature set with established users. Typically, in these scenarios, friction is created between the development team that is keen on putting a product out that has only the most important features and the business team that believes it is important not to pull back the features already available to the end-user. In these situations, a compromise can be found by defining a MVP solution focused on a subset of features that can be delivered to a subset of the user base for feedback.

Explore more about the concept of Minimal Viable Product

Agile Alliance's definition of MVP

A link to Eric Ries in his own words, talking about the concept of MVP at the inaugural Lean Startup meetup in San Francisco, July 2009:

https://youtu.be/E4ex0fejo8w

Project Roadmaps

Planning and Creating Roadmaps for your Agile Project

A Roadmap, in Scrum, refers to a flexible planning technique (roadmapping) for attaining short- and long-term project goals. There are multiple types of roadmaps that are used to help product teams visualize what is needed to create the product and how those needs should be organized into iterative releases of working software.

Articles in this section:

Attachment J7 - Agile Methodology 11/26/2025 https://www.agilealliance.org/glossary/mvp/ https://youtu.be/E4ex0fejo8w

What is a Product Roadmap?

What is a Feature Roadmap?

The Product Roadmap

What is a Product Roadmap?

A Product Roadmap is a high-level strategic view of the prioritized goals and initiatives that are necessary to meet the end goals set forth in the . It should include , , and architectural and technical elements in a timeboxed format. The timebox should Product Vision Epics Features be broad, spanning the length of the project. Timeboxed Roadmaps help synchronize the activities involved in creating a product. Additions and adjustments to the Product Roadmap and timeboxing can be made to adapt to changing circumstances, however, the overarching objective of the product should be well-defined. is a key step in planning for any project. below is a Creating a Product Roadmap Figure 2 sample of a Product Roadmap with a release every four Sprints.

Creating a Product Roadmap

Creating a Product Roadmap begins with creating and based on the goals and strategic initiatives that needed to create a Epics Features product. The Epics and Features seed the , which is an organized list of all the work that needs to be completed within the Product Backlog span of the project. Product Roadmaps should be high-level and focus on top priority items driven by the . Follow the Product Vision guidelines below to create your Product Roadmap.

Timing: The Product Roadmap should be in place before the start of Sprint

0. This helps your team prioritize and organize for Sprint 0 spin up activities and in creating the , which should be Feature Roadmap completed just before the first meeting. The timeline Sprint Planning for the Product Roadmap should match the timeline set for all aspects of your project's development. For example, if you have five years to complete your project, the Product Roadmap should span five years from the start date.

What goes into a Product Roadmap? To begin the process of creating a Product Roadmap, first consider the goals and strategic initiatives that you want to accomplish within the timeline of your project:

Goals are measurable and time-bound objectives that show the critical accomplishments required to make the Product Vision a reality.

Strategic initiatives represent high-level efforts or big themes of work that need to be completed to achieve the goals.

Create Epics and Features: Break goals and initiatives out into clearly defined Epics and Features. Epics are large, high-level stories that describe the overall goal and Features are smaller pieces of functionality that can be completed within a single release to accomplish the goal described in the Epic.

Focus on High-Priority Epics: High-priority Epics should be scheduled first. When scheduling Epics, consider available resources and the minimum amount of work that would need to be completed to fulfill the Definition of Done for the Epic.

Who Creates the Product Roadmap: The takes the initiative in driving the process of Product Owner creating a Product Roadmap. As the owner of the Product Backlog, which contains the Epics, Features, and other User Stories Product required to build the product, the Product Owner is in Backlog Items the best position to organize information and obtain feedback from their stakeholders.

Setting up the Roadmap: Agile@Library recommends consideration of the Sprint length and release timing when setting up a Roadmap. Section the Roadmap by the number of Sprints in a release. The example in Figure 2 above shows a sample of a three-year Product Roadmap, for a team doing three-week Sprints, with releases every four Sprints, or approximately four releases per calendar year.

Update the Roadmap: Initial Product Roadmaps may need to be adjusted over time to accommodate new information, changing priorities, and resources.

Dates of important expected releases and milestones may be added as more information becomes available. You may also want to track progress of Features and Epics against the Product Roadmap to ensure your project remains on-track.

The Feature Roadmap

What is a Feature Roadmap?

A Roadmap of Features or Feature Roadmap is the detail of a . While the Product Roadmap provides a high-level, project-Product Roadmap long view of the work to be done, Feature Roadmaps detail pieces of functionality, with associated , that can be broken down User Stories into Releases during . Using a Feature Roadmap helps teams visualize the work for an entire release and also provides a Release Planning method of tracking the progress of the product being created. Before creating the Feature Roadmap, prioritize the and that Epics Features will meet the product objectives and goals for each release. Feature Roadmaps should be created three releases out. Creating a Feature enables teams to focus on immediate priorities and the work needed to accomplish them. shows a sample Feature Roadmap Figure 3 Roadmap with four planned releases.

Attachment J7 - Agile Methodology 11/26/2025 https://staff.loc.gov/wikis/display/AT/Pains https://staff.loc.gov/wikis/display/AT/Pains https://staff.loc.gov/wikis/display/AT/Olllllld+mac+error+sounds https://staff.loc.gov/wikis/display/AT/Epics+and+Features

Creating a Feature Roadmap

Feature Roadmaps provide a more in-depth look at the timeline for creating and delivering your Product. Narrowing the focus to Features and User Stories allows you to identify Release goals and ensures is in accordance with the Product Roadmap. Start with Sprint Planning the Product Roadmap you have already created and follow the guidelines below.

Timing: The Feature Roadmap for your product should be completed just before the first Sprint Planning meeting. As with the Product Roadmap, the Feature Roadmap should span the length of the project. While the Product Roadmap should remain as static as possible, Feature Roadmaps need to be updated more frequently as more Features are identified and User Stories are created. Feature Roadmaps should be planned at least three release out.

What goes into a Feature Roadmap? To begin the process of creating a Feature Roadmap, refer back to your Product Roadmap and the prioritized Epics you created. Your Feature Roadmap should contain the Features you created to complete the Epics you identified in your Product Roadmap.

Remember, Epics are the ultimate pieces of functionality, but the Features help you get there incrementally.

Add User Stories to your Features As you plan your Feature Roadmap, consider the work that needs to be done to accomplish the Feature. The Acceptance Criteria for the will become your User Stories to fill out your Feature Product .Backlog

Who Creates the Feature Roadmap: As with the Product Roadmap, the is responsible for Product Owner planning the Feature Roadmap. They will work closely with the Exten to ensure all the work that is required to complete ded Scrum Team a Feature is included in the plan.

Setting up the Roadmap: The Feature Roadmap should be an expansion of the Product Roadmap. Continue to focus on high-priority Epics and the priority Features and the architecture required to support them. Features should be completed in a single release. Features that may take longer than a release may need to be broken down further. In the sample roadmap in , note that none of the Features span Figure 3 more than a single release, while some Epics span multiple releases.

Update the Roadmap: New Features are continuously identified during the course of writing User Stories. As you identify new Features, prioritize them and add them to the Feature Roadmap. Always consider the impact of timing and level of effort on other planned Features when adding new ones to your Roadmap.

Release Planning

3.

Facilitated by: Product Owner

Required Attendees: Product Owner, , Extended Scrum Team Scr um Master

Optional Attendees: Stakeholders, at the request of the Product Owner

Occurrence/Duration: Every release (4 months), 1 day

Inputs/Outputs: Inputs:

Outline of Release Plan that includes Product Vision Release Goal Prioritized Product Backlog

Outputs:

4-Month Release Plan Sprint Goals for each Sprint during the Release Dependencies, risks, issues, assumptions Sprint Plan for current release

How to Play: Elaboration on the following steps can be found in . Figure 4, Release Planning Explained below is an example of a Release Roadmap with one release every four Sprints, planned three releases out.

Outline a basic Release Roadmap with goals Confirm Release Roadmap outline with Stakeholders Hold a Release Planning meeting

Review the Release Roadmap Review the Architecture Review and Sprint PlanVelocity Determine the Definition of Done for the Release Review Team Capacity Conduct for the first of the current Release Sprint Planning Sprint Finalize and share the Release Roadmap

Release Planning Explained

3.

1.

2.

3.

4.

5.

6.

Outline a Basic Roadmap with Goals: By this point, the Product Owner should have defined the Product Vision and ranked the Product Backlog to prioritize work items supporting the most immediate goals for a release. A Release Roadmap is an ordered list of vertical slices of functionality organized along a timeline of a single release (3-4 Sprint Cycles). The Product Owner creates a basic Release Roadmap outline to share with stakeholders during Release Planning.

Confirm the Release Roadmap outline with stakeholders: The Product Owner shares the Release Roadmap outline with stakeholders to obtain consensus. This provides the stakeholders with the opportunity to ask questions and request edits.

Hold a Release Planning meeting: The Product Owner schedules a Release Planning session with stakeholders and the Scrum Team to ensure all involved are in agreement on the Release Roadmap. During the meeting, the Product Owner and stakeholders complete the following:

Review Release Roadmap: The Product Owner and stakeholders review the updated Release Roadmap outline to confirm that everyone understand the overall goal for the project.

Review Architecture: Enterprise Architect should present the architecture and technical details for the release. This is the time to discuss any new information that could affect the release plan estimates and scope, including dependencies, assumptions, or gaps.

Review Velocity and Sprint schedule: The Scrum Master should provide an estimate of the team’s Velocity based on prior projects, if available. If there is no data to determine Velocity, the team can make a reasonable estimate, based on team capacity and working hours within the Sprint, and adjust the Roadmap as new information becomes available.

Determine Definition of Done for the Release: The Release Definition of Done is similar to the Definition of Done for a Product Backlog Item. The difference is the Acceptance Criteria is applied to the Release, rather than individual pieces of work.

Conduct Sprint Planning for Sprint 1 of the Release: The Scrum Team and Product Owner determines how much work needs to be completed in each Sprint to meet the project goals. The Scrum Master and Core Scrum Team plan the first Sprint in accordance with the Product Owner’s immediate goals.

Finalize and share the Release Roadmap: The Product Owner should finalize the release with stakeholders and share the Release calendar with everyone involved.

Team Norms

The Team Norms is a list of Standards for team interactions and development standard that help the work together effectively.Scrum Team

The list below is a starting point for teams working on Agile@Library projects. Teams should feel free to add to these norms as they mature.

Roles and Responsibilities Scrum Team Members’ roles and responsibilities will be well defined.

Ceremonies A parking lot time box shall be scheduled at the end of the to address open Daily Standup items after all the reporting is complete.

Jira shall be used to visually display all tasks for each team member, during the Daily Standup

Jira Jira updates will happen continuously throughout the Sprint.

Acceptance Criteria will be documented in Jira

Work Items Sprint – Majority of Sprint tasking of committed work shall be completed on Day 1 Tasking of the Sprint. Any departure from this needs to be brought to the ’ Product Owners attention for approval/reprioritization.

Sprint Disposition (shall be completed by midnight on the last day of the Sprint by Scrum

). Incomplete/unaccepted shall be split such that the completed tasks Master User Stories remain in the current Sprint while the original and the incomplete tasks are Story Points moved to the new Sprint. Ideally, after it is committed in a Sprint splitting a User Story during is not prescribed by Agile best practices. In order to align with this Sprint Planning best practice, effective and efficient and Sprint Planning sessions shall Backlog Grooming be conducted

Testing Promotion to Test Environment shall be accomplished at least twice during each Sprint Sprint Demo will be conducted by the lead developers on the last day of the Sprint.

Teams will promote to the <UAT> environment every Sprint (as coordinated with the Product Owner).

Unit testing shall be completed as code is checked in

Demos If a User Story has successfully passed QA and is in a completed state before the Sprint Demo then those stories can be demoed prior to Product Owner acceptance and accepted by the Product Owners after the demo Sprint demo shall be performed from Staging/UAT environment

Resources Webex will be provided at each meeting and to include remote team members.Ceremony

Defects Defects found in Dev shall be communicated to QA testers and developers ASAP. This communication shall highlight the critical/major defects and blockers via Jira.

Defect Pointing - Defects found in development and QA shall not be pointed if the defect is to be worked within the Sprint

Agile Coaching & User Story Mentoring

Agile Coaches are experienced in implementing Agile projects and can share that experience with an Agile team. The Agile Coach provides feedback to help Agile Teams improve their efficiency.

Agile Coaches are responsible for the following:

Providing feedback to team members to help them increase efficiency and eliminate wasteful practices Acting as an Agile Champion by helping the team “live” Agile Advise teams on best practices for their specific methodology (Scr or Kanban)um Acting as Mentor to guide teams in creating good User User Story Stories with solid and Acceptance Criteria Definitions of Ready and Done

Benefits of an Agile Coach

Invested in Team Success: An Agile Coach’s goal is to facilitate a transition to Agile that ultimately benefits the Library of Congress and allows individual teams to thrive. Agile Coaches are entirely focused on the Agile transition.

Adherence with Industry Standards: Agile Coaches provide recommendations and guidance in line with industry standards, best practices and the most recent developments in the Agile Community. This helps ensure that your team remains in compliance with Agile practices and avoid issues during any audits or external reviews.

Neutral (but helpful) Third Party: Agile Coaches provide a neutral view of your team, without preconceived notions or bias about the team.

Their observations, experience and knowledge can identify improvements and areas for growth that internal/invested parties within the organization may overlook.

Mentors for Agile in the Organization and Associated Roles: Agile Coaches are well-versed in the latest industry standards, practices, and approaches in Agile. They can use this knowledge and experience to help guide Leadership, , , Scrum Masters Product Owners teams that are new to Agile.and supporting groups Large scale Agile transformations require facilitation, monitoring and reporting: Agile coaches can remove much of the transition activities the team, allowing them to focus on ‘getting the work done’. Many of the materials Agile Coaching teams produce, revolve around monitoring and reporting on the current ‘health’ of the Agile transition, and provide recommendations to keep the transition on track with the organization’s goals

Roles and Responsibilities

The Players

A successful Scrum project is dependent on the people who make up the team. The following articles describe who is on a Scrum Team and their responsibilities within their roles.

Articles in this section:

Core and Extended Scrum Teams Scrum Master Product Owner Scrum Team Member Stakeholders

Core and Extended Scrum Teams

What is a Scrum Team?

Join the Conversation

Feel free to join our channel or our Slack ListServ

Attachment J7 - Agile Methodology 11/26/2025 https://app.slack.com/client/T0407MCCA/CDHNJQZ70 https://listserv.loc.gov/cgi-bin/wa?SUBED1=agileatlibrary&A=117

The Scrum Team is comprised of Core Scrum Team members, including developers, testers, business analysts, and other technical workers, the , and the Scrum Master Product Owner An Extended Scrum Team may also include , including Subject Matter Experts (SMEs), system architects, data architects, Stakeholders project managers and other personnel The Product Owner and Scrum Master frequently interact with both the Core and Extended Scrum Teams The Core Scrum Team should be sheltered by the Scrum Master at all times Figure 5 below illustrates the Core and Extended Scrum Teams as recommended by Agile@Library

Characteristics of a Scrum Team

Each key member is 100% allocated to the project (utilized at 100% of assignable hours during assigned duration) The team has a high degree of operating autonomy Self-organized: team is able to make decisions on how to operate without consulting others Cross-functional: team members are able to take on different types of work (i.e. DBA, Dev, QA) Team members pull and estimate the work to be done for a Sprint Raise issues and impediments to the Scrum Master as they occur Assess performance and makes process improvements

Scrum Master

Key Responsibilities

Ensures the Core Scrum Team can work uninterrupted during the Sprint Educates and guides the Scrum Team on Scrum practices Ensures that the Scrum Team lives Agile and follows the Team Norms they have agreed to use Resolves impediments in a timely manner, or escalates the impediments to the appropriate person, as applicable Facilitates , , , and ceremoniesDaily Standup Sprint Planning Sprint Review Sprint Retrospective Ensures Sprint Retrospective Action Items are incorporated into future Sprints

Characteristics of a Scrum Master

Servant-leader to the Scrum Team Handles no more than two teams at once Is not in a position of authority over Scrum Team Members

Scrum Team Member

Key Responsibilities

Commit to completing Items in each Sprint Backlog Sprint Deliver completed Sprint Backlog Items that are well-tested, and meet the and Acceptance Criteria Definition of Done Participate in and assist the in writing Acceptance Criteria and the for each Backlog Refinement Product Owner Definition of Ready User Story Provide for each User Story using Story Pointsestimations Create for each User StoryTasks Identify and report impediments to the in a timely mannerScrum Master Adhere to the Team Norms

Characteristics of a Scrum Team Member

Additional Information

To go even further, read more about about the Characteris tics of a Great Scrum Team by Barry Overeem on Scrum.

.org

Attachment J7 - Agile Methodology 11/26/2025 file://lcdataserver/LOCPROF.003/jemy/My%20Documents/Agile@Library.Playbook.v11112019.docx#ScrumMaster https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-08/Characteristics%20of%20a%20Great%20Scrum%20Team.pdf https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-08/Characteristics%20of%20a%20Great%20Scrum%20Team.pdf http://Scrum.org http://Scrum.org

Able to perform their role within the , but willing to Scrum Team help in other areas as needed Participates in all , and Scrum Ceremonies Release Planning Estimates work Adheres to the established Team Charter, including the Team Norms Escalates impediments as soon as possible

Product Owner

Key Responsibilities

Develops and Communicates the to theProduct Vision Scrum Team Acts as the representative for the customer Develops and Epics Features Participates in creating:

Feature Roadmap, Release Plan

Owns and prioritizes the Product Backlog Creates and facilitates User Story Workshops, as necessaryUser Stories Facilitates sessions with the Scrum Team to create Backlog Refinement Acceptance Criteria Defines the for the Scrum TeamDefinition of Done Accepts or rejects work performed during a Sprint Attends and , and the , as requiredSprint Planning Sprint Review Daily Standup

Characteristics of a Product Owner

Responsible for the successful completion of the product Handles no more than two projects at once Fully immersed with Core Scrum Team and stakeholders

Stakeholders

Characteristics of a Stakeholder

Can be Subject Matter Experts (SMEs), customers, System and Data Architects, Project Managers, leadership, and other personnel who have a vested interest in the Product May participate in at the invitation of the Sprint Reviews Product Owner May provide support for the creation of User StoriesThe Sprint Cycle

Training Opportunity

Agile for the Government Product Owner

If you’re a Product Owner in government and want to learn the basics of practicing Agile methods with your team, this study track is for you.

http://www.agilegovleaders.org/academy/product-owner/

Attachment J7 - Agile Methodology 11/26/2025 http://www.agilegovleaders.org/academy/product-owner/ http://www.agilegovleaders.org/academy/product-owner/

The Sprint Cycle is a timeboxed interval in which the completes their workScrum Team During a Sprint with Agile@Library, the Scrum Team works in three-week intervals, called Sprint Cycles, during which the team completes their work and participates in the following Scrum Ceremonies:

Sprint Planning – Day 1 Daily Standup – Days 2-14 Sprint Review – Day 15 Sprint Retrospective – Day 15

Days 2-14 are considered working days and should be devoted to completing the work pulled into the Sprint Backlog The may ask for a health check midway through the Sprint to ensure the Scrum Master Scrum Team feels confident about meeting the Sprint goal Backlog Refinement should occur at least twice during a single Sprint Cycle

Scrum Ceremonies

The Plays

In keeping with Agile values of promoting individuals and interactions, as well as customer collaboration, Scrum has regular meetings that facilitate discussion and collaboration. These meetings, called Ceremonies, are fixed within the Sprint Cycle to ensure all stakeholders are accomplishing the business objectives. The articles in this section describe each Scrum Ceremony.

Articles in this section:

Sprint Planning Daily Standup Backlog Refinement Sprint Review Sprint Retrospective

Sprint Planning

Facilitated by: Scrum Master

Required Attendees: Scrum Master, , Core Scrum Team Product Owner

Optional Attendees: N/A

Occurrence/Duration: At the beginning of each , 2 Sprint Cycle hours per week of Sprint

Ceremonies in Jira

3.

4.

5.

6.

7.

Inputs/Outputs: Inputs:

Refined , specifically Backlog Items User , with , and Stories Acceptance Criteria Defi and nitions of Ready Done Team Capacity

Outputs:

Sprint Backlog Understanding of how each item will be built

How to Play: Elaboration on the following steps can be found in Sprint Planning Explained.

Determine Team Capacity Validate the Definitions of Ready and Done for each User Story Review each User Story to ensure all team members have collective understanding of the work Estimate Story Points each User Story Commit to the Sprint

Sprint Planning Explained

Define the Sprint Goal: What do we want to achieve during this Sprint? Sprint Goals should be correlated with current Business and Product objectives. The Product Owner should come to Sprint Planning prepared to define the goal for each Sprint.

Determine Team Capacity: The Scrum Master performs prior to Sprint Planning. Team Capacity is determined Capacity Planning by calculating using the number of working hours for each team member.

Validate Definitions of Ready and Done: Each User Story should have clear Definitions of Ready and Done to be considered for a Sprint. These Definitions will be clarified during , but should be confirmed again prior to pulling work into Backlog Refinement the Sprint Backlog.

Review each User Story: The team should have a collective understanding of each User Story and the Acceptance Criteria. While User Stories are refined for a Sprint in Backlog Refinement, this is an opportunity for the team to ask any remaining questions and confirm their understanding of the Acceptance Criteria.

Story Points for each User Story:Estimate Team members should assign an estimate, in Story Points, for each User Story.

Estimation may also be performed during Backlog Refinement. If the Core Scrum Team has estimated their Stories prior to Sprint Planning, confirm the estimations during Sprint Planning.

Commit to the Sprint: The Core Scrum Team should agree on what will be pulled into the Sprint Backlog. Remember, the team should only commit to work that they believe they can complete within the Sprint. The Scrum Master may gauge the team’s commitment and confidence with a vote.

Core Team Members should Task out their User Stories immediately following the Sprint Planning meeting.

Daily Standup

Facilitated by: Scrum Master

Required Attendees: Core Scrum Team file://lcdataserver/LOCPROF.003/jemy/My%20Documents/Agile@Library.Playbook.v11112019.docx#CapacityPlanning

3.

4.

5.

Optional Attendees: Product Owner and , at Scum Stakeholders Master's discretion

Occurrence/Duration: Daily, 15 minutes

Inputs/Outputs: Inputs:

Sprint Backlog

Outputs:

List of accomplishments and blockers Action items for resolving blockers

How to Play: Elaboration on the following steps can be found in .Daily Standup Explained

Each Team member speaks Display the Scrum board the entire time for team members to reference Each team member provides an update on:

Their planned work for that day What they accomplished the day before Any impediments they have encountered

Daily Standup Explained

Scrum teams are encouraged to be self-organized. If the Scrum Master is not available to facilitate any ceremony, including Daily Standup, the team should be empowered to hold the ceremony themselves.

As with all ceremonies, the Daily Standup should be scheduled at the same time each day. It is the responsibility of each team member to make every effort to attend. If a team member is unable to attend, they may submit their updates in written form.

Each team member is responsible for keeping their Stories and Tasks updated in Jira. Ideally, this should happen in real-time, or at the very latest, during the Daily Standup.

The Daily Standup must be kept relevant to all team members; therefore, discussions that do not affect everyone should be tabled until after the Standup.

Keep the meeting to 15 minutes or less. A hard stop at 15 minutes helps the team learn to efficiently provide their updates. The time directly after the Daily Standup is perfect for continuing with tabled items and follow-up discussions between team members.

Backlog Refinement

Facilitated by: Product Owner

Required Attendees: Scrum Master, Product Owner (or Proxy), Co re Scrum Team

Optional Attendees: Stakeholders, at the request of the Product Owner, Extended Scrum Team members, as needed

Occurrence/Duration: As often as needed

3.

4.

5.

Inputs/Outputs: Inputs:

Prioritized, but unrefined User Stories

Outputs:

Shared understanding of the Refined Back log Items User Stories potentially Ready for Sprint Planning

How to Play: Elaboration on the following steps can be found in .Backlog Refinement Explained

Describe the User Stories Create and Confirm Acceptance Criteria Estimate each User Story Right-Size User Stories Define Ready and Done

Backlog Refinement Explained

Describe the Backlog Items: The Product Owner is ultimately responsible for each User Story in the Product Backlog. During Refinement, the Product Owner should be able to describe the desired functionality for the Scrum Team so they can ask clarifying questions.

Create and Confirm Acceptance Criteria: The Scrum Team should be able to help the Product Owner create or confirm Acceptance Criteria for each User Story based on the information the Product Owner provides. The goal is to create a shared understanding of the User Story and the work needed to be done.

Estimate each User Story: Team members provide a preliminary estimation for each User Story using Story Points. This can help with determining if the Story is too large to be completed in a Sprint. Any estimates added to User Stories during Refinement should be reviewed and confirmed during Sprint Planning.

Right-Size User Stories: If a User Story is too large to be completed in a Sprint, the Scrum Team should break the Story into smaller chunks.

Define Ready and Done: Team members work with the Product Owner to determine if the Story is ready to be worked on, and the circumstances under which the Story will be considered complete.

Sprint Review

Facilitated by: Scrum Master

Required Attendees: Scrum Master, , Core Scrum Team Product Owner

Optional Attendees: Stakeholders, Extended Scrum Team

Occurrence/Duration: At the end of each Sprint

3.

4.

5.

6.

Inputs/Outputs: Inputs:

Sprint Backlog and Objectives Work that satisfies the Sprint Backlog

Outputs:

Product Owner-certified work completed during the Sprint meets the definition of done List of defects on any accepted items and items not accepted Action items list based on feedback from the Product Owner

How to Play: Elaboration on the following steps can be found in .Sprint Review Explained

Review accomplishments for the Sprint Product Owner validates User Stories Demonstrate working software Solicit feedback from the Product Owner and stakeholders Determine the disposition of any unfinished work Discuss the Product Backlog

Sprint Review Explained

Review accomplishments for the Sprint: The Scrum Team gives an overview of the Sprint. This may include reviewing User Stories for acceptance from the Product Owner, reviewing , and emphasizing team successes during the Sprint.metrics Product Owner validates User Stories: The Product Owner formally validates the Stories completed during a Sprint according to the ; however, the Product Owner should accept work throughout the Sprint.Acceptance Criteria Demonstrate working software: The Scrum Team provides a demonstration of the vertical slice of functionality completed during the Sprint for the extended Scrum Team and stakeholders.

Solicit feedback from Product Owner and stakeholders: The Sprint Review provides the best opportunity for the Scrum Team to receive feedback from the Product Owner on how things went during the Sprint. The Scrum Master should keep track of action items for improvement resulting from Product Owner feedback obtained during the Sprint Review.

Determine the disposition of unfinished work: If the Scrum Team did not meet the Sprint goal and there is unfinished work, the Product Owner should review any work that was not completed to determine if the work is still a priority. Priority items should be pushed to the next Sprint, while non-priorities should be eliminated or placed in the Product Backlog to be re-prioritized. The Story should be split, so the completed work can move to Done and the unfinished work can move into the Product Backlog. In Jira, this can be accomplished by cloning the Story.

Discuss the Product Backlog: The Product Owner and Scrum Team discuss goals for the next Sprint and may finalize the top-priority items in the Product Backlog in preparation for the next sessionSprint Planning

Sprint Retrospective

Facilitated by: Scrum Master

Required Attendees: Scrum Master, Core Scrum Team

Optional Attendees: N/A

Occurrence/Duration: At the end of each , 1 hour per week Sprint of Sprint

3.

4.

5.

6.

Inputs/Outputs: Inputs:

Discuss Stop/Start/Continue Action Items from the prior Sprint Review Sprint from current and metrics prior sprints

Outputs:

List of Stop/Start/Continue Action Items for current Sprint

How to Play: Elaboration on the following steps can be found in .Sprint Retrospective Explained

Review what went well Review what didn’t go well Discuss what can be done to make improvements for the upcoming Sprint

Sprint Retrospective Explained

The Sprint Retrospective should be considered a safe place for team members to honestly discuss things that went well and areas needing improvement.

Review sprint metrics to identify improvement opportunities.

Use sticky notes, or a virtual space for team members to add their thoughts; sometimes it’s easier to write things down than say them outright.

Use dot voting or a similar method to determine the most important items that should be focused on for improvement in the next Sprint.

The Scrum Master should ensure that Action Items resulting from the Retrospective are resolved in a timely manner and absorbed into the next Sprint, if necessary.

Sprint Retrospectives should not be tacked on to the Sprint Review. The two ceremonies are have separate goals and should each be given their own timebox.

Scrum Artifacts

The Pieces

Scrum Artifacts refer to the lists of planned work and the individual work items completed during the . The articles in this section Sprint Cycle describe each Artifact and provides guidance on how to successfully plan, organize, and complete work.

Articles in this section:

Sprint Backlog Product Backlog Product Backlog Items

Epics and Features User Stories Tasks

Sprint Backlog

What it is: A list of prioritized, refined, and estimated Ba to be completed during a cklog Items Sprint

Owned By: Core Scrum Team

Rules:

Only the Scrum Team can add items to the Sprint Backlog During an active Sprint, there should be no additions to the Sprint Backlog If an addition is necessary, the Scrum should work with the Master Product to determine how the change can Owner be accommodated. Usually, this means that a work item of equal value is removed from the Sprint.

Product Backlog

What it is: A list of all the individual work items (Backlog and ) needed to complete Items User Stories the product

Owned By: Product Owner

Rules:

Anyone can write a User Story, but the Product Owner has the final say over what gets added to the Backlog The Product Owner should continuously prioritize the Backlog to accommodate changes to product objectives The Backlog should be regularly refined by the Product Owner with the help of the to ready them for the Scrum Team Sprint Backlog

Artifacts in Jira

Product Backlog Items

What they are: All the individual work items (including Epics , , and ) and Features User Stories Tasks needed to complete the product.

Owned By: Anyone can create a Product Backlog Item, but the has the final say in Product Owner what goes into the Product Backlog

Rules:

Backlog items can and should be refined to make them usable and ready for the Spr int Backlog Backlog Item creation should be in accordance with Agile@Library Standards for the type of Backlog Item, including User Story and bug reporting standards

Epics & Features

Product Building Blocks

Epics and Features are the building blocks of the Product Backlog. When starting a new Scrum project, most teams begin with creating Epics, which are high-level ideas that support the goal of the Product. Epics are then broken into Features, which are smaller chunks of functionality that can be completed within a single release cycle. Features are comprised of a short benefit statement that describe the business value of the desired functionality, along with Acceptance Criteria for the functionality. Feature Acceptance Criteria become the User Stories that support the functionality. Figure 7 below shows the hierarchy of Backlog Items from Epics to User Stories.

Articles in this section:

Epics Features

Epics

An Epic is a large chunk of work that describes a high-level goal of the Product. Although Epics are generally high-value, they are usually too large to be completed within a single Spr int, and are consequently broken down into smaller Features and User Stories. Epics are a good way to initially organize your work as you think of new ideas. When breaking Epics down into Features, consider using a technique like FEEDBACK or SPIDR.splitting

Features

3.

4.

5.

6.

7.

8.

9.

10.

11.

Features are distinct elements of functionality that provide parts of a business or technical capabilities in the overall process. They should include a title, one or more short benefit statements to represent the business value provided by the Feature, and Acceptance for each benefit statement. The Acceptance Criteria for the Features become Criteria User Stories.

Feature Creation Process:

Identify high-level Features Determine if Features are releasable; disaggregate into smaller Features, if necessary Identify architectural features Determine Feature dependencies Estimate Feature relative sizes in story points Identify Sprints per release and calculate Sprint and Release using historical team data (if this will be the first release for Velocity the team, use a rough estimate based on and the sizes of the Features included in the release)Team Capacity Prioritize Features and adjust based on dependencies Develop a (three releases out) based on Team CapacityFeature Roadmap Begin elaboration from FeaturesUser Story Adjust Features and User stories during and as neededRelease Planning Sprint Planning Update and Refine the continuously throughout the course of the project.Product Roadmap

The User Story

What is a User Story?

User Stories are short, simple descriptions of a feature told from the perspective of the person desires the new capability - the user of the system. User Stories follow a basic template:

As a <type of user>, I want <desired action>

So I can <valuable outcome>

User Stories should be thought of a reminder to have a conversation. The three "Cs" of User Stories are Cards, Conversation, and Confirmation; writing your ideas down on "cards" whether real or virtual, is the first step in the process. The "Conversation" should occur between the and the development team during and, to Product Owner Backlog Refinement a certain extent, so both parties completely understand the work to be done. Sprint Planning "Confirmation" is accomplished via .Acceptance Criteria

User Stories are generally created by the Product Owner, but can be written by anyone, with the understanding that the Product Owner has the final say on what goes into the Product

. They can be written at any time, but it is beneficial for the Product Owner to hold Backlog User Story Workshops with stakeholders to generate stories for a particular .Feature

Agile@Library recommends the model, described in Writing Good User Stories, INVEST below.

Writing Good User Stories

User Stories describe the role, action, and resulting value of a business need. Along with , a Story should contain all the Acceptance Criteria information required to complete it within a . When writing User Stories, keep the INVEST model in mind. This will help you ensure Sprint that the developer has everything they need to create the requested functionality. INVEST stands for Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

Independent User Stories Can a developer work this story as it is presented?

should stand on their own. Dependencies between stories lead to issues with estimation, prioritization, and planning.

Negotiable User Stories are reminders to have a conversation with the development team. While details on what is required are necessary, how the Story is implemented is up to the developers.

Valuable Ensure User Stories contain clear value in business language so they can be prioritized.

Estimatable User Stories should clearly state the desired action with SMART Acc that demonstrates the expected result of the action eptance Criteria so the development team can…