Develop Your Agile Approach for a Successful Transformation

Understand Agile fundamentals, principles, and practices so you can apply them effectively in your organization.

Analyst Perspective

Understand Agile fundamentals, principles, and practices so you can apply them effectively in your organization.

Alex Ciraco and Hans Eckman
Application Practice
Info-Tech Research Group

Executive Summary

Your Challenge

• Your organization wants to shorten delivery time and improve quality by adopting Agile delivery methods.
• You know that Agile transformations are complex and difficult to implement.
• Your organization may have started using Agile, but with only limited success.
• You want to maximize your Agile transformation's chances of success.

Common Obstacles

• People seem to have different, conflicting, or inadequate knowledge of Agile principles and practices.
• Your organization is not seeing the full benefits that Agile promises, and project teams aren't sure they are "doing Agile right."
• Confusion and misinformation about Agile is commonplace in your organization.

Info-Tech's Approach

• Use our Common Agile Challenges Survey to identify your organization's Agile pain points.
• Leverage this blueprint to level-set the organization on Agile fundamentals.
• Address your survey's biggest Agile pain points to see immediate benefits and improvements in the way you practice Agile in your organization.

Info-Tech Insight

Agile transformations are more likely to be successful when the entire organization genuinely understands Agile fundamentals, principles and practices, as well as the role each person plays in its success. Focus on developing a solid understanding of Agile practices so your organization can "Be Agile", not just "Do Agile".

Info-Tech's methodology

Develop your agile approach for a successful transformation

Everyone's Agile journey is not the same.

Application delivery continues to fall short

78% of IT professionals believe the business is "usually" or "always" out of sync with project requirements.
Source: "10 Ways Requirements Can Sabotage Your Projects Right From the Start"

Only 34% of software is rated as both important and effective by users.

Source: Info-Tech's CIO Business Vision Diagnostic

Agile DevOps is a progression of cultural, behavioral, and process changes. It takes time.

Enhancements and maintenance are misunderstood

Source: "IEEE Transactions on Software Engineering"

Why Agile/DevOps? It's about time to value

Leaders and stakeholders are frustrated with long lead times to implement changes. Agile/DevOps promotes smaller, more frequent releases to start earning value sooner.

Time to delivering value depends on Frequency of Releases

Embrace change, don't "scope creep" it

64% of IT professionals adopt Agile to enhance their ability to manage changing priorities.

71% of IT professionals found their ability to manage changing priorities improved after implementing Agile.

Info-Tech Insight

Traditional delivery processes work on the assumption that product requirements will remain constant throughout the SDLC. This results in delayed delivery of product enhancements which are critical to maintaining a positive customer experience.

Adapted from: "12th Annual State of Agile Report"

Agile's four core values

"…while there is value in the items on the right, we value the items on the left more."
– Source: "The Agile Manifesto"

Harness Agile's cultural advantages

Collaboration

• Team members leverage all their experience working toward a common goal.

Iterations

• Cycles provide opportunities for more product feedback.

Continual Improvement

• Self-managing teams continually improve their approach for the next iteration.

Prioritization

• The most important needs are addressed in the current iteration.

Compare Waterfall and Agile – the "what" (how are they different?)

A "One and Done" Approach (Planning & Documentation Based)
Elapsed time to deliver any value: Months to years

An "Iterative" Approach (Empirical/Evidence Based)
Elapsed time to deliver any value: Weeks

Be aware of common myths around Agile

1. … solve development and communication issues.
2. … ensure you will finish requirements faster.
3. … mean you don't need planning and documentation.

"Although Agile methods are increasingly being adopted in globally distributed settings, there is no panacea for success."
– "Negotiating Common Ground in Distributed Agile Development: A Case Study Perspective."

"Without proper planning, organizations can start throwing more resources at the work which spirals into the classic Waterfall issues of managing by schedule."
– Kristen Morton, Associate Implementation Architect,
OneShield Inc., Info-Tech Interview

Agile* SDLC

With shared ownership instead of silos, we can deliver value at the end of every iteration (aka sprint)

* There are many Agile methodologies to choose from, but Scrum is by far the most widely used (and is shown above).

Key Elements of the Agile SDLC

• You are not "one-and-done." There are many short iterations with constant feedback.
• There is an empowered product owner. This is a single authoritative voice that represents stakeholders.
• There is a fluid product backlog. This enables prioritization of requirements "just-in-time."
• Cross-functional, self-managing team. This team makes commitments and is empowered by the organization to do so.
• Working, tested code at the end of each sprint. Value becomes more deterministic along sprint boundaries.
• Demonstrate to stakeholders. Allow them to see and use the functionality and provide necessary feedback.
• Feedback is being continuously injected back into the product backlog. This shapes the future of the solution.
• Continuous improvement through sprint retrospectives.
• "Internally Governed" when done right (the virtuous cycle of sprint-demo-feedback).

A backlog stores and organizes PBIs at various stages of readiness

A well-formed backlog can be thought of as a DEEP backlog:

• Detailed Appropriately: Product backlog items (PBIs) are broken down and refined as necessary.
• Emergent: The backlog grows and evolves over time as PBIs are added and removed.
• Estimated: The effort a PBI requires is estimated at each tier.
• Prioritized: The PBIs value and priority are determined at each tier.

(Perforce, 2018)

Outline the criteria to proceed to the next tier via quality filters

Expand the concepts of defining "ready" and "done" to include the other stages of a PBIs journey through product planning.

Info-Tech Insight: A quality filter ensures quality is met and teams are armed with the right information to work more efficiently and improve throughput.

Deliverables

Many steps in this blueprint are accompanied by supporting deliverables to help you accomplish your goals.

Common Agile Challenges Survey
Survey the organization to understand which of the common Agile challenges the organization is experiencing

Roadmap for Transition to Agile
Identify steps you will take to move your organization toward Agile delivery

Blueprint benefits

Measure the value of this blueprint

Implementing quality and consistent Agile practices improves SDLC metrics and reduces time to value.

• Use Select and Use SDLC Metrics Effectivelyto track and measure the impact of Agile delivery. For example:
• Reduction in PBI wait time
• Improve throughput
• Reduction in defects and defect severity
• Phase 1 helps you prepare and send your Common Agile Challenges Survey.
• Phase 2 builds a transformation plan aligned with your top pain points.

Align Agile coaching and practices to address your key pain points identified in the Common Agile Challenges Survey.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks used throughout all four options

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 6 to 8 calls over the course of 1 to 2 months.

Workshop Overview

Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889

For additional assistance planning your workshop, please refer to the facilitation planning tool in the appendix.

Related Info-Tech Research

Mentoring for Agile Teams
Get practical help and guidance on your Agile transformation journey.

Implement DevOps Practices That Work
Streamline business value delivery through the strategic adoption of DevOps practices.

Deliver on Your Digital Product Vision
Build a product vision your organization can take from strategy through execution.

Deliver Digital Products at Scale
Deliver value at the scale of your organization through defining enterprise product families.

Phase 1

This phase will walk you through the following activities:

• Decide who will participate in the Common Agile Challenges Survey
• Compile the results of the survey to identify your organization's biggest pain points with Agile

This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Develop Your Agile Approach for a Successful Transformation

Step 1.1

Identify common Agile challenges

Activities

1.1 Distribute Common Agile Challenges Survey and collect results

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of your organization's Agile pain points.

Focus Agile support where it is most needed

Info-Tech Insight

There isn't one approach that cures all the problems your Agile teams are facing. First, understand these common challenges, then develop a plan to address the root causes.

Use Info-Tech's Common Agile Challenges Survey to determine common issues and what problems individual teams are facing. Use the Agile modules and supporting guides in this blueprint to provide targeted support on what matters most.

Exercise 1.1.1 Distribute Common Agile Challenges Survey

30 minutes

1. Download Survey Template: Info-Tech Common Agile Challenges Survey template.
2. Create your own local copy of the Common Agile Challenges Survey by using the template. The Common Agile Challenges Survey will help you to identify which of the many common Agile-related challenges your organization may be facing.
3. Decide on the teams/participants who will be completing the survey. It is best to distribute the survey broadly across the organization and include participants from several teams and roles.
4. Copy the link for your local survey and distribute it for participants to complete (we suggest giving them one week to complete it).
5. Collect the consolidated survey results in preparation for the next phase.
6. NOTE: Using this survey template requires having access to Microsoft Forms. If you do not have access to Microsoft Forms, an Info-Tech analyst can perform the survey for you.

Output

• Your organization's biggest Agile pain points

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Record the results in the Roadmap for Transition to Agile Template

Phase 2

Establish a Solid Foundation for Agile Delivery

This phase will walk you through the following activities:

• Gain a fundamental understanding of Agile
• Understand why becoming Agile is hard
• Identify steps needed to become more Agile
• Understand your biggest Agile pain points

This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Step 2.1

Align teams with Agile fundamentals

Activities

2.1.1 Share what Agile means to you
2.1.2 (Optional) Contrast two delivery teams
2.1.3 (Optional) Dissect the Agilist's Oath
2.1.4 (Optional) Create your prototype definitions of ready
2.1.5 (Optional) Create your prototype definitions of done
2.1.6 Identify the challenges of implementing agile in your organization

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of what Agile is and why we do it.

Exercise 2.1.1 Share what Agile means to you

30-60 minutes

1. What is Agile? Why do we do it?
2. As a group, discuss and capture your thoughts on:
   1. What is Agile (its characteristics, practices, differences from alternatives, etc.)?
   2. Why do we do it (its drivers, benefits, advantages, etc.)?
3. Capture your findings in the table below:

Output

• Your current understanding of Agile and its benefits

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Why Agile/DevOps? It's about time to value

Leaders and stakeholders are frustrated with long lead times to implement changes. Agile/DevOps promotes smaller, more frequent releases to start earning value sooner.

Time to delivering value depends on frequency of releases.
Source: 5Q Partners

The pandemic accelerated the speed of digital transformation

With the massive disruption preventing people from gathering, businesses shifted to digital interactions with customers.

Companies also accelerated the pace of creating digital or digitally enhanced products and services.

(McKinsey, 2020 )

"The Digital Economy incorporates all economic activity reliant on or significantly enhanced by the use of digital inputs, including digital technologies, digital infrastructure, digital services and data."
(OECD Definition)

What does "elite" DevOps look like?

Where are you now?
Where do You Want to Be?

* Google Cloud/Accelerate State of DevOps 2021

Realize and sustain value with DevOps

Businesses with elite DevOps practices…

Waterfall vs. Agile – the "what" (How are they different?)

A "One and Done" Approach (Planning & Documentation Based)
Elapsed time to deliver any value: Months to years

An "Iterative" Approach (Empirical/Evidence Based)
Elapsed time to deliver any value: Weeks

(Optional) Exercise 2.1.2 A tale of two teams

Discussion (5-10 minutes)

As a group, discuss how these teams differ

Team 1:

Team 2:

Image Credit: DVIDS

Output

• How your organization can support Agile behavior and mindset

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Dissect the Agilist's Oath

Read and consider each element of the oath.

• As a member of this Scrum team, I recognize that we are all equally and collectively responsible for the success of this project.
• Success is defined as achieving the best possible outcome for our stakeholders given the constraints of time, money, and circumstances we will face.
• We will achieve this by working collaboratively with our product owner to regularly deliver high-quality, working, tested code that can be demonstrated, and we will adjust our path forward based on the feedback we receive.
• I will holistically embrace the concept of "good enough for now" into my work practices, because I know that waiting for the best/perfect solution does not yield optimal results.
• Collectively, we will work to holistically minimize risk for the project across all phases and disciplines.
• My primary role will be _____ [PO, SM, BA, Dev, Arch, Test, Ops, etc.], but I will contribute wherever and however best serves the current needs of the project.
• I recognize that working in Agile/Scrum is not an excuse to ignore important things like adequate design and documentation. Collectively, we will ensure that these things are completed incrementally to a level of detail and quality which adequately serves the organization and stakeholders.
• We are a team, and we will succeed or fail as one.

Exercise 2.1.3 (Optional) Dissect the Agilist's Oath

30 minutes

1. Each bullet point in the Agilist's Oath is chosen to convey one of eight key messages about Agile practices and the mindset change that's required by everyone involved.
2. As a group, discuss the "message" for each bullet point in the Agilist's Oath. Then identify which of them would be "easy" and "hard" to achieve in your organization.

• As a member of this Scrum team, I recognize that we are all equally and collectively responsible for the success of this project.
• Success is defined as achieving the best possible outcome for our stakeholders given the constraints of time, money, and circumstances we will face.
• We will achieve this by working collaboratively with our product owner to regularly deliver high-quality, working, tested code that can be demonstrated, and we will adjust our path forward based on the feedback we receive.
• I will holistically embrace the concept of "good enough for now" into my work practices, because I know that waiting for the best/perfect solution does not yield optimal results.
• Collectively, we will work to holistically minimize risk for the project across all phases and disciplines.
• My primary role will be _____ [PO, SM, BA, Dev, Arch, Test, Ops, etc.], but I will contribute wherever and however best serves the current needs of the project.
• I recognize that working in Agile/Scrum is not an excuse to ignore important things like adequate design and documentation. Collectively, we will ensure that these things are completed incrementally to a level of detail and quality which adequately serves the organization and stakeholders.
• We are a team, and we will succeed or fail as one.

Output

• How your organization can support Agile behavior and mindset

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Be aware of common myths around Agile

Agile does not . . . .

1. … solve development and communication issues.
2. … ensure you will finish requirements faster.
3. … mean you don't need planning and documentation.

"Although Agile methods are increasingly being adopted in globally distributed settings, there is no panacea for success."
– "Negotiating Common Ground in Distributed Agile Development: A Case Study Perspective."

"Without proper planning, organizations can start throwing more resources at the work which spirals into the classic Waterfall issues of managing by schedule."
– Kristen Morton, Associate Implementation Architect,
OneShield Inc., Info-Tech Interview

Agile's four core values

"…while there is value in the items on the right, we value the items on the left more."
– Source: "The Agile Manifesto"

Consider the traditional/Waterfall SDLC

With siloes and handoffs, valuable product is delivered only at the end of an extended project lifecycle.

View additional transition models in the appendix

Agile* SDLC

With shared ownership instead of silos, we can deliver value at the end of every iteration (aka sprint)

Key Elements of the Agile SDLC

• You are not "one-and-done". There are many short iterations with constant feedback.
• There is an empowered product owner. This is a single authoritative voice that represents stakeholders.
• There is a fluid product backlog. This enables prioritization of requirements "just-in-time"
• Cross-functional, self-managing team. This team makes commitments and is empowered by the organization to do so.
• Working, tested code at the end of each sprint. Value becomes more deterministic along sprint boundaries.
• Demonstrate to stakeholders. Allow them to see and use the functionality and provide necessary feedback.
• Feedback is being continuously injected back into the product backlog. This shapes the future of the solution.
• Continuous improvement through sprint retrospectives.
• "Internally Governed" when done right (the virtuous cycle of sprint-demo-feedback).

* There are many Agile methodologies to choose from, but Scrum (shown above) is by far the most widely used.

Scrum roles and responsibilities

Scrum ceremonies

Sample delivery sprint calendar

The following calendar illustrates a two-week Scrum cadence (including ceremonies). This diagram is for illustrative purposes only. The length of the sprint and timing of ceremonies may differ from delivery team to delivery team based on their needs and schedules.

Sample delivery sprint calendar

The following calendar illustrates a three-week Scrum cadence (including ceremonies). This diagram is for illustrative purposes only. The length of the sprint and timing of ceremonies may differ from delivery team to delivery team based on their needs and schedules.

Ensure your teams have the right information

Implement and enforce your definition of ready at each stage of planning. Ensure your teams understand the required tasks by clarifying the definition of done.*

* Note that your definitions of ready and done may vary from project to project, and they should be decided on collectively by the delivery team at the beginning of the project (part of setting their "norms") and updated if/when needed.

Exercise 2.1.4 (Optional) Create definition of ready and done for an oil change

10-15 minutes

Step 1:

1. As a group, create a definition of ready and done for doing an oil change (this will help you to understand the nature and value of a definition of ready and done using a relatable example):

Exercise 2.1.4 (Optional) Create your prototype definitions of ready

30-60 minutes

Step 2:

1. As a group, review the two sample definitions of ready below and select the one you consider to be the best starting point for your prototype definition of ready.

Definition of Ready SAMPLE 1:

Definition of Ready SAMPLE 2:

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.1.4 (Optional) Create your prototype definitions of ready

30-60 minutes

Step 3:

1. As a group, using the selected sample as your starting point, decide what changes need to be made (keep/add/delete/modify):

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.1.4 (Optional) Create your prototype definitions of ready

30-60 minutes

Step 4:

1. As a group, capture and agree on your prototype definition of ready*:

Record the results in the Roadmap for Transition to Agile Template

* This checklist helps Agile teams determine if the stories in their backlog are ready for sprint planning. As your team gains experience with Agile, tailor this list to your needs and follow it until the practice becomes second nature.

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.1.5 (Optional) Create your prototype definitions of done

30-60 minutes

Step 5:

1. As a group, review the two sample definitions of ready below and select the one you consider to be the best starting point for your prototype definition of ready:

SAMPLE 1:

SAMPLE 2:

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.1.4 (Optional) Create your prototype definitions of done

30-60 minutes

Step 6:

1. As a group, using the selected sample as your starting point, decide what changes need to be made (keep/add/delete/modify):

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.1.4 (Optional) Create your prototype definitions of done

30-60 minutes

Step 7:

1. As a group, capture and agree on your prototype Definition of Done*:

Record the results in the Roadmap for Transition to Agile Template

* This checklist helps Agile teams determine if the stories in their backlog are ready for sprint planning. As your team gains experience with Agile, tailor this list to your needs and follow it until the practice becomes second nature.

Output

• Prototype definitions of ready and done for your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Getting to "Agile DevOps Nirvana" is hard, but it's worth it.

Agile DevOps is a progression of cultural, behavioral, and process changes.
It takes time.

Agile DevOps may be hard, but it's worth it…

It turns out Waterfall is not as good at reducing risk and ensuring delivery after all.

Standish Group; CHAOS REPORT 2015

"I believe in this [Waterfall] concept, but the implementation described above is risky and invites failure."

– Winston W. Royce

Compare Waterfall to Agile

Hybrid SDLC: Wagile/Agilfall/WaterScrumFall

Valuable product delivered in multiple releases

If moving directly from Waterfall to Agile is too much for your organization, this can be a valuable interim step (but it won't give you the full benefits of Agile, so be careful about getting stuck here).

Exercise 2.1.6 Identify the challenges of implementing Agile in your organization

30-60 minutes

1. As a group, discuss:
   1. Why being Agile may be difficult in your organization?
   2. What are some of the roadblocks and speed bumps you may face?
   3. What incremental steps might the organization take toward becoming Agile?

Record the results in the Roadmap for Transition to Agile Template

Output

• Why being Agile is hard in your organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Step 2.2

Align teams with Agile fundamentals

Activities

2.2.1 Review the results of your Common Agile Challenges Survey (30-60 minutes)
2.2.2 Align your support with your top five challenges

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your organization's biggest Agile pain points.

Be aware of common Agile challenges

The road to Agile is filled with potholes, speedbumps, roadblocks, and brick walls!

1. Establish an effective product owner role (PO)
2. Uncertainty about minimum viable product (MVP)
3. How non-Agile teams (like architecture, infosec, operations, etc.) work with Agile teams
4. Project governance/gating process
5. What is the role of a PM/PMO in Agile?
6. How to budget/plan Agile projects
7. How to contract and work with an Agile vendor
8. An Agile skills deficit (e.g. new-to-Agile teams who have difficulty "doing Agile right")
9. General resistance to change in the organization
10. Lack of Agile training, piloting, and coaching
11. Different Agile approaches are used by different teams
12. Backlog management and user story decomposition challenges
13. Quality assurance challenges
14. Hierarchical management practices and organization boundaries
15. Difficulty with establishing autonomous Agile teams
16. Lack of management support for Agile
17. Poor Agile estimation practices
18. Difficulty creating effective product roadmaps in Agile
19. How do we know when an Agile project is ready to go live?
20. Sprint goals are not being consistently met, or sprint deliverables that are full of bugs

Exercise 2.2.1 Review the results of your Common Agile Challenges Survey

30-60 minutes

1. Using the results of your Common Agile Challenges Survey, fill in the bar chart with your top five pain points:

Output

• Your organization's biggest Agile pain points identified and prioritized

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.2.2 Align your support with your top five challenges

30 minutes

Using the Agile Challenges support mapping on the following slides, build your transformation plan and supporting resources. You can build your plan by individual team results or as an enterprise approach.

Output

• Your organization's Agile Challenges transformation plan

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Map challenges to supporting modules

Note: Modules listed as (Future) are in development and may be available in draft format.

Map challenges to supporting modules

Note: Modules listed as (Future) are in development and may be available in draft format.

Map challenges to supporting modules

Note: Modules listed as (Future) are in development and may be available in draft format.

Map challenges to supporting blueprints

Note: Modules listed as (Future) are in development and may be available in draft format.

Map challenges to supporting blueprints

Map challenges to supporting blueprints

Step 2.3

Move stepwise to iterative Agile delivery (Optional)

Activities

2.3.1 (Optional) Identify a hypothetical project
2.3.2 (Optional) Capture your traditional delivery approach
2.3.3 (Optional) Consider what a two-phase delivery looks like
2.3.4 (Optional) Consider what a four-phase delivery looks like
2.3.5 (Optional) Consider what a four-phase delivery with monthly sprints looks like
2.3.6 (Optional) Decide on your target state and the steps required to get there

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand the changes that must take place in your organization to support a more Agile delivery approach.

Moving stepwise from traditional to Agile

Your transition to Agile and more frequent releases doesn't need to be all at once. Organizations may find it easier to build toward smaller iterations.

Exercise 2.3.1 (Optional) Identify a hypothetical project

15-30 minutes

1. As a group, consider some typical, large, mission-critical system deliveries your organization has done in the past (name a few as examples).
2. Imagine a project like this has been assigned to your team, and the plan calls for delivering the system using your traditional delivery approach and taking two years to complete.
3. Give this imaginary project a name (e.g. traditional project, our project).

Record this in the Roadmap for Transition to Agile Template

Info-Tech Best Practice

For best results, complete these sub-exercises with representatives from as many functional areas as possible
(e.g. stakeholders, project management, business analysis, development, testing, operations, architecture, infosec)

Output

• An imaginary delivery project that is expected to take 2 years to complete

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.2 (Optional) Capture your traditional delivery approach

30 minutes

1. As a group, discuss and capture the high-level steps followed (after project approval) in your traditional delivery approach using the table below and on the next page.

Output

• The high-level steps in your current (traditional) delivery approach and who is involved in each step

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.2 (Optional) Capture your traditional delivery approach

Output

• The high-level steps in your current (traditional) delivery approach and who is involved in each step

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.3 (Optional) Consider what a two-phase delivery looks like

30 minutes

1. As a group, imagine that project stakeholders tell you two years is too long to wait for the project, and they want to know if they can have something (even if it's not the whole thing) in production sooner.
2. Now imagine that you are able to convince the stakeholders to work with you to do the following:
   1. Identify their most important project requirements.
   2. Work with you to describe a valuable subset of the project requirements which reflect about ½ of all features they need (call this Phase 1).
   3. Work with you to get this Phase 1 of the project into production in about 1 year.
   4. Agree to leave the remaining requirements (e.g. the less important ones) until Phase 2 (second year of project).
3. As a group, identify:
   1. How hard this would be for your organization to do, on a scale of 1 to 10.
   2. Identify what changes are needed to make this happen (consider people, processes, and technology).
   3. Capture your results using the table on the following slide.

Output

• The high-level steps in your current (traditional) delivery approach and who is involved in each step

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.3 (Optional) Consider what a two-phase delivery looks like

30 minutes

1. What would be needed to let you deliver a two-year project in two one-year phases considering people, process, and technology?

How difficult would this be to achieve in your organization? (1-easy, 10-next to impossible)

e.g. 2

Output

• Understand how your organization would deliver a large project in two phases

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.4 (Optional) Consider what a four-phase delivery looks like

30 minutes

1. Now, imagine that project stakeholders tell you that even one year is still too long to wait for something of value in production, and they want to know if they can have something (even if it's not the whole thing) in production sooner.
2. Now imagine that you are able to convince the stakeholders to work with you to do the following:

1. From the "Phase 1" requirements in Exercise 2.3.3, they will identify the most important ones that they need first.
2. They will work with you to describe a valuable subset of these project requirements which reflect about ½ of all features they need (call this Phase 1A).
3. They will work with you to get this Phase 1A of the project into production in about six months.
4. Agree to leave all the remaining requirements (e.g. the less important ones) until later phases.

3. As a group, identify:

1. How hard this would be for your organization to do, on a scale of 1 to 10?
2. Identify what changes are needed to make this happen (consider people, processes, and technology).
3. Capture your results using the table on the following slide.

Output

• Understand how your organization would deliver a large project in two phases

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.4 (Optional) Consider what a four-phase delivery looks like

30 minutes

1. What more would be needed to let you deliver a two-year project in four, six-month phases considering people, process, and technology?

How difficult would this be to achieve in your organization? (1-easy, 10-next to impossible)

e.g. 5

Output

• Understand how your organization would deliver a large project in two phases

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.5 (Optional) Consider what a four-phase delivery with monthly sprints looks like

30 minutes

1. Now, imagine that project stakeholders tell you that they are happy with the six-month release approach (e.g. expect to go live four times over the two-year project, with each release providing increased functionality), but they want to see your team's progress frequently between releases.
2. Additionally, stakeholders tell you that instead of asking you to provide the traditional monthly project status reports, they want you to demonstrate whatever features you have built and work for the system on a monthly basis. This will be done in the form of a demonstration to a selected list of stakeholders each month.
3. Each month, your team must show working, tested code (not prototypes or mockups, unless asked for) and demonstrate how this month's deliverable brings value to the business.
4. Furthermore, the stakeholders would like to be able to test out the system each month, so they can play with it, test it, and provide feedback to your team about what they like and what they feel needs to change.
5. To help you to achieve this, the stakeholders designate their primary contact as the "product owner" (PO) who will be dedicated to the project and will help your team to decide what is being delivered each month. The PO will be empowered by the stakeholders to make decisions on scope and priority on an expedited basis and will also answer questions on their behalf when your team needs guidance.
6. You agree with the stakeholders these one-month deliverables will be called "sprints."

Output

• Understand how your organization would deliver a large project in two phases

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.5 (Optional) Consider what a four-phase delivery with monthly sprints looks like

30 minutes

1. What more would be needed to let you deliver a two-year project in 24 one-month sprints (plus four six-month releases) considering people, process, and technology?

How difficult would this be to achieve in your organization? (1-easy, 10-next to impossible)

e.g. 8

Output

• Understand how your organization would deliver a large project in two phases

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.6 (Optional) Define the steps to reach your target state

30 minutes

1. From Exercises 2.3.1-2.3.5, identify your current state on the stepwise transition from traditional to Agile (e.g. one-and-done).
2. Then, identify your desired future state (e.g. 24 one-month sprints with six-month releases).
3. Now, review your people, process, and technology changes identified in Exercises 2.3.1-2.3.5 and create a roadmap for this transition using the table on the next slide.

Output

• A roadmap and timeline for adopting a more Agile delivery approach

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.3.6 (Optional) Define the steps to reach your target state

30 minutes

1. Fill in the table below with your next steps. Identify who will be responsible for each step along with the timeline for completion: "Now" refers to steps you will take in the immediate future (e.g. days to weeks), "Next" refers to steps you will take in the medium term (e.g. weeks to months), and "Later" refers to long-term items (e.g. months to years).

Record the results in the Roadmap for Transition to Agile Template

Output

• A roadmap and timeline for adopting a more Agile delivery approach

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Step 2.4

Identify insights and team feedback

Activities

2.4.1 Identify key insights and takeaways
2.4.2 Perform an exit survey

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your key insights and takeaways from Phase 2

Exercise 2.4.1 Identify key insights and takeaways

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the intro to Agile presentation?
   2. What if any takeaways do participants feel are needed as a result of the presentation?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Exercise 2.4.2 Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Agile Modules

Prioritize Agile support with your top challenges

Organizations often struggle with numerous pain points around Agile delivery.
The Common Agile Challenges Survey results will help you identify and prioritize the organization's biggest (most cited) pain points. Treat these pain points like a backlog and address the biggest ones first.

Agile modules provide supporting activities:
Each module provides guidance and supporting activities related to a specific Agile challenge from your survey. These modules can be arranged to meet each organization's or team's needs while providing cohesive and consistent messaging. For additional supporting research, please visit the Agile / DevOps Resource Center.
This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Backlog Management Module

Manage your backlog effectively

Activities

Backlog 1.1 Identify your backlog and user story decomposition pains
Backlog 1.2 What are user stories and why do we use them?
Backlog 1.3 User story decomposition: password reset
Backlog 1.4 (Optional) Decompose a real epic

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of backlog management and user story decomposition.

Backlog Exercise 1.1 Identify your backlog and user story decomposition pains

30-60 minutes

1. As a group, discuss and capture your thoughts on:

1. What specific challenges you are facing with backlog management
2. What specific challenges you are facing with user story decomposition

2. Capture your findings in the table below:

Output

• Your specific backlog management and user story decomposition challenges

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

User stories and the art of decomposition

User stories are core to Agile delivery.

Good user story decomposition practices are key to doing Agile effectively.

Agile doesn't use traditional "shoulds" and "shalls" to capture requirements

Backlog Exercise 1.2 What are user stories and why do we use them?

30-60 minutes

1. User stories are a simple way of capturing requirements in Agile and have the form:

Example:
As a banking customer, I want to see the current balance of my accounts so that I can know how much money I have in each account.

Output

• A better understanding of user stories and why they are used in Agile delivery

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

User stories are "placeholders for conversations"

User stories enable collaboration and conversations to fully determine actual business requirements over time.

e.g. As a banking customer, I want to see the current balance of my accounts so that I can know how much money I have in each account.

Requirements, determined within the iterations, outline the steps to complete the story: how the user will access their account, the types of funds allowed, etc.

User stories allow the product owners to prioritize and manage the product needs (think of them as "virtual sticky notes").

User stories come in different "sizes"

These items form a four-level hierarchy: epics, features, user stories, and tasks.
They are collectively referred to as product backlog items or (PBIs)

The process of taking large PBIs (e.g. epics and features) and breaking them down in to small PBIs (e.g. user stories and tasks) is called user story decomposition and is often challenging for new-to-Agile teams

Backlog Exercise 1.3 User story decomposition: password reset

30-60 minutes

1. As a group, consider the following feature, which describes a high-level requirement from a hypothetical system:
   • FEATURE: As a customer, I want to be able to set and reset my password, so that I can transact with the system securely.
2. Imagine your delivery team tells you that this is user story is too large to complete in one sprint, so they have asked you to decompose it into smaller pieces. Work together to break this feature down into several smaller user stories:

User Story 1:	User Story 2:	User Story 3:

Output

• An epic which has been decomposed into smaller user stories which can be completed independently

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Backlog Exercise 1.3 User story decomposition: password reset

Epic: As a customer, I want to be able to set and reset my password, so that I can transact securely.

A single epic can be broken down into multiple user stories

User Story 1:	User Story 2:	User Story 3:	User Story 4:
Acceptance Criteria: Given that the customer has a password that they want to change, When the administrator clicks reset password on the admin console, Then the system will change the password and send it to the user.	Acceptance Criteria: Given that the customer has a password that they want to change, When they click reset password in the system, Then the system will allow them to choose a new password and will save it the password and send it to the user.	Acceptance Criteria: Given that the customer has not logged onto the system before, When they initially log in, Then the system will prompt them to change their password.	Acceptance Criteria: Given that a password is stored in the database, When anyone looks at the password field in the database, Then the actual password will not be visible or easily decrypted.

Are enablers included in your backlogs? Should they be?

An enabler is any support activity needed to provide the means for future functionality. Enablers build out the technical foundations (e.g. architecture) of the product and uphold technical quality standards.

Your audience will dictate the level of detail and granularity you should include in your enabler, but it is a good rule of thumb to stick to the feature level.

Consider the various types of enabler

Source: Scaled Agile, "Enablers."

Create, split, and bundle your PBIs

The following questions can be helpful in dissecting an epic down to the user story level. The same line of thinking can also be useful for bundling multiple small PBIs together.

Backlog Exercise 1.4 (Optional)
Decompose a real epic

30 minutes

1. As a group, select a real epic or feature from one of your project backlogs which needs to be decomposed:
2. Work together to decompose this epic down into several smaller features and/or user stories (user stories must be small enough to reasonably be completed within a sprint):

Epic to be decomposed:

As a ____ I want _____ so that ______

User Story 1:	User Story 2:	User Story 3:

Output

• A real epic from your project backlog which has been decomposed into smaller features and user stories

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Backlog Management Module

Manage your backlog effectively

Activities

Backlog 2.1 Identify enablers and blockers

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Backlog PBI filters.
• A better understanding of backlog types and levels.

Effective backlog management and refinement

Working with a tiered backlog

Use a tiered approach to managing your backlog, and always work on the highest priority items first.

Distinguish your specific goals for refining in the product backlog vs. planning for a sprint itself

Often backlog refinement is used interchangeably or considered a part of sprint planning. The reality is they are very similar, as the required participants and objectives are the same however, there are some key differences.

A better way to view them is "pre-planning" and "planning."

A backlog stores and organizes PBIs at various stages of readiness

A well-formed backlog can be thought of as a DEEP backlog:

• Detailed Appropriately: Product backlog items (PBIs) are broken down and refined as necessary.
• Emergent: The backlog grows and evolves over time as PBIs are added and removed.
• Estimated: The effort a PBI requires is estimated at each tier.
• Prioritized: The PBIs value and priority are determined at each tier.

(Perforce, 2018)

Backlog tiers facilitate product planning steps

Each activity is a variation of measuring value and estimating effort to validate and prioritize a PBI.

A PBI meets our definition of done and passes through to the next backlog tier when it meets the appropriate criteria. Quality filters should exist between each tier.

Backlog Exercise 2.1 Build a starting checklist of quality filters

60 minutes

1. Quality filters provide a checklist to ensure each Product Backlog Item (PBI) meets our definition of Done and is ready to move to the next backlog group (status).
2. Create a checklist of basic descriptors that must be completed between each backlog level.
3. If you completed this exercise in a different Module, review and update it here.
4. Use this information to start your product strategy playbook in Deliver on Your Digital Product Vision.

Output

• List of enablers and blockers to establishing product owners

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Outline the criteria to proceed to the next tier via quality filters

Expand the concepts of defining "ready" and "done" to include the other stages of a PBIs journey through product planning.

Info-Tech Insight: A quality filter ensures quality is met and teams are armed with the right information to work more efficiently and improve throughput.

Define product value by aligning backlog delivery with roadmap goals

In each product plan, the backlogs show what you will deliver. Roadmaps identify when and in what order you will deliver value, capabilities, and goals.

Facilitator slides: Explaining MVP

Facilitator slides: Explaining MVP

Understanding minimum viable product

Use iterations to maximize value delivery

Use iterations to reduce accumulated risk

Understanding MVP
(always be ready to go live)

A great and wise pharaoh hires two architects to build his memorial pyramids.

Understanding MVP
(always be ready to go live)

Several years go by, and then…

Backlog Management Module

Manage your backlog effectively

Activities

Backlog 3.1 Identify key insights and takeaways
Backlog 3.2 Perform exit survey and capture results

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your key insights and takeaways.

Backlog Exercise 3.1 Identify key insights and takeaways

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the Intro to Agile presentation?
   2. What if any takeaways do participants feel are needed as a result of the presentation?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Backlog Exercise 3.2 Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Agile Modules

Prioritize Agile support with your top challenges

Organizations often struggle with numerous pain points around Agile delivery.
The Common Agile Challenges Survey results will help you identify and prioritize the organization's biggest (most cited) pain points. Treat these pain points like a backlog and address the biggest ones first.

Agile modules provide supporting activities:
Each module provides guidance and supporting activities related to a specific Agile challenge from your survey. These modules can be arranged to meet each organization's or team's needs while providing cohesive and consistent messaging. For additional supporting research, please visit the Agile / DevOps Resource Center.
This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Scrum Simulation Module

Scrum sprint planning and retrospective simulation

Activities

1.1 Identify your scrum pains
1.2 Review scrum simulation intro
1.3 Create a mock backlog
1.4 Review sprint 0
1.5 Determine a budget and timeline
1.6 Understand minimum viable product
1.7 Plan your first sprint
1.8 Do a sprint retrospective
1.9 "What if" exercise (understanding what a fluid backlog really means)
1.10 A sprint 1 example
1.11 Simulate more sprints

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of Scrum (particularly backlog management and user story decomposition).

Facilitator slides: Scrum Simulation Introduction

Introduction Tab

Talk to the nature of the Scrum team:

• Collective ownership/responsibility for delivery.
• The organization has given you great power. With great power comes great responsibility.
• You may each be specialists in some way, but you need to be prepared to do anything the project requires (no one goes home until everyone can go home).
• Product owner: Special role, empowered by the organization to act as a single, authoritative voice for stakeholders (again great power/responsibility), determines requirements and priorities, three ears (business/stakeholders/team), holds the vision for the project, answer questions from the team (or finds someone who can answer questions), must balance autonomy with stakeholder needs, is first among equals on the Scrum team, is laser-focused on getting the best possible outcome with the resources, money, and circumstances ← PO acts as the "pathfinder" for the project.
• Talk about the criticality and qualities of the PO: well-respected, highly collaborative, wise decision maker, a "get it done" type (healthy bias toward immediacy), has a vision for product, understands stakeholders, can get stakeholders' attention when needed, is dedicated full-time to the project, can access help when needed, etc.
• The rest of you are the delivery team (have avoided singling out an SM for this – not needed for the exercise – but SM is the servant leader/orchestra conductor for the delivery team. The facilitator should act as a pseudo-SM for this exercise).

Speak about the "bank realizes that the precise scope of the first release can only be fully known at the end of the project" statement and what it means.

Discuss exercise and everyone's roles (make sure everyone clear), make it as realistic as possible. Your level of participation will determine how much value you get.

Discuss any questions the participants might have about the background section on the introduction tab. The exercise has been defined in a way that minimizes the scope and complexity of the work to be done by assuming there are existing web-capable services exposed to the bank's legacy system(s) and that the project is mostly about putting a deployable web front end in place.

Speak about "definition of done": Why was it defined this way? What are the boundaries? What happens if we define it to be only up to unit testing?

Facilitator slides: Scrum Simulation, Create a Mock Backlog

Create a Mock Backlog Tab

This exercise is intended to help participants understand the steps involved in creating an initial backlog and deciding on their MVP.

Note: The output from this exercise will not be used in the remainder of the simulation (a backlog for the simulation already exists on tab Sprint 0) so don't overdo it on this exercise. Do enough to help the participants understand the basic steps involved (brainstorm features and functions for the app, group them into epics, and decide which will be in- and out-of-scope for MVP). Examples have been provided for all steps of this exercise and are shown in grey to indicate they should be replaced by the participants.

Step 1: Have all participants brainstorm "features and functions" that they think should be available in the online banking app (stop once you have what feels like a "good enough" list to move on to the next step) – these do not need to be captured as user stories just yet.

Step 2: Review the list of features and functions with participants and decide on several epics to capture groups of related features and functions (bill payments, etc.). Think of these as forming the high-level structure of your requirements. Now, organize all the features and functions from Step 1, into their appropriate epic (you can identify as many epics as you like, but try to keep them to a minimum).

Step 3: Point out that on the Introduction tab, you were told the bank wants the first release to go live as soon as possible. So have participants go over the list of features and functions and identify those that they feel are most important (and should therefore go into the first release – that is, the MVP), and which they would leave for future releases. Help participants think critically and in a structured way about how to make these very hard decisions. Point out that the product owner is the ultimate decision maker here, but that the entire team should have input into the decision. Point out that all the features and functions that make up the MVP will be referred to as the "project backlog," and all the rest will be known as the "product backlog" (these are of course, just logical separations, there is only one physical backlog).

Step 4: This step is optional and involves asking the participants to create user stories (e.g. "As a __, I want ___ so that ___") for all the epics and features and functions that make up their chosen MVP. This step is to get them used to creating user stories, because they will need to get used to doing this. Note that many who are new to Agile often have difficulty writing user stories and end up overdoing it (e.g. providing a long-winded list of things in the "I want ___" part of the user story for an epic) or struggling to come up with something for the "so that ____" part). Help them to get good at quickly capturing the gist of what should be in the user story (the details come later).

Facilitator slides: Scrum Simulation, Budget and Timeline

Project Budget and Timeline

Total Number of Sprints = 305/20 = 15.25 → ROUND UP TO 16 (Why? You can't do a "partial sprint" – plus, give yourself a little breathing room.)

Cost Per Sprint = 6 x $75 x 8 x 10 = $36,000

Total Timeline = 16 * 2 = 32 Weeks

Total Cost of First Release = $36,000 x 16 = $572,000

Talk about the "commitment" a Scrum delivery team makes to the organization ("We can't tell you exactly what we will deliver, but based on what we know, if you give the team 32 weeks, we will deliver something like what is in the project backlog – subject to any changes our stakeholder tell us are needed"). Most importantly, the team commits to doing the most important backlog items first, so if we run out of time, the unfinished work will be the least valuable user stories. Lastly, to keep to the schedule/timeline, items may move in and out of the project backlog – this is part of the normal and important "horse trading" that takes place on health Agile projects.

Speak to the fact that this approach allows you to provide a "deterministic" answer about how long a project will take and how much it will cost while keeping the project requirements flexible.

Facilitator slides: Scrum Simulation, Sprint 0

Sprint 0 Tab

This is an unprioritized list, organized to make sense, and includes a user story (plus some stuff), and "good enough estimates" – How good?... Eh! (shoulder shrug)
Point out the limited ("lazy") investment → Agile principle: simplicity, the art of maximizing the work not done.
Point out that only way to really understand a requirement is to see a working example (requirements often change once the stakeholders see a working example – the "that's not what I meant" factor).

Estimates are a balancing act (good enough that we understand the overall approximate size of this, and still acknowledges that more details will have to wait until we decide to put that requirement into a Sprint – remember, no one knows how long this project is going to take (or even what the final deliverable will look like) so don't over invest in estimates here.)

Sprint velocity calculation is just a best guess → be prepared to find that your initial guess was off (but you will know this early rather than at the end of the project). This should lead to a healthy discussion about why the discrepancy is happening (sprint retrospectives can help here). Note: Sprint velocity doesn't assume working evenings and weekends!

Speak to the importance of Sprint velocity being based on a "sustainable pace" by the delivery team. Calculations that implicitly expect sustained overtime in order to meet the delivery date must be avoided. Part of the power of Agile comes from this critical insight. Critical → Your project's execution will need to be adjusted to accommodate the actual sprint velocity of the team!

Point out the "project backlog" and separation from the "product backlog" (and no sprint backlog yet!).

Point out the function/benefits of the backlog:

• A single holding place for all the work that needs to be done (so you don't forget/ignore anything).
• Can calculate how much work is left to do.
• A mechanism for prioritizing deliverables.
• A list of placeholders for further discussion.
• An evolving list that will grow and shrink over time.
• A "living document" that must be maintained over the course of the project.

Talk about large items in backlog (>20 pts) and how to deal with them (do we need to break them up now?).

Give participants time to review the backlog: Questions/What would you be doing if this were real/We're going to collectively work through this backlog.
Sprint 0 is your opportunity to: get organized as a team, do high level design, strategize on approach, think about test data, environments, etc. – it is the "Ready-Set" in "Ready-Set-Go."
Think about doing a High/Med/Low value determination for each user story.

Simulation Exercise 1.1 Identify your Scrum pains

30 minutes

1. As a group, discuss and capture your thoughts on:
   • What specific challenges are you facing with your Scrum practices?
2. Capture your findings in the table below:

What are your specific Scrum challenges?

• (e.g. We don't know how to decide on our minimum viable product (MVP), or what to start working on first)
• (e.g. We don't have a product owner assigned to the project)
• (e.g. Our daily standups often take 30-60 minutes to complete)
• (e.g. We heard Scrum was supposed to reduce the number of meetings we have, but instead, meetings have increased)
• (e.g. We don't know how to determine the budget for an Agile project)

Output

• Your specific Scrum related challenges

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.2 Review Scrum Simulation intro

30 minutes

1. Ask participants to read the Introduction tab in the Scrum Simulation Exercise(5 minutes)
2. Discuss and answer any questions the participants may have about the introduction (5 minutes)
3. Discuss the approach your org would use to deliver this using their traditional approach (5 minutes)

How would your organization deliver this using their traditional approach?

1. Capture all requirements in a document and get signoff from stakeholders
2. Create a detailed design for the entire system
3. Build and test the system
4. Deploy it into production

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Simulation Exercise 1.3 Create a mock backlog

30-60 minutes

Step 1: Brainstorm "Features and Functions" that the group feels would be needed for this app

Capture anything that you feel might be needed in the Online Banking Application:

• See account balances
• Pay a bill online
• Set up payees for online bill payments
• Make a deposit online
• See a history of account transactions
• Logon and logoff
• Make an e-transfer
• Schedule a bill payment for the future
• Search for a transaction by payee/date/amount/etc.
• Register for app
• Reset password

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Create a mock initial backlog for the simulated project

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.3 Create a mock backlog

30-60 minutes

Step 2: Identify your epics

1. Categorize your "Features and Functions" list into several epics for the application:

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Create a mock initial backlog for the simulated project

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.3 Create a mock backlog

30-60 minutes

Step 3: Identify your MVP

1. Decide which "Features and Functions" will be in your MVP and which will be delivered in future releases:

YOUR MVP (Project Backlog)

FOR FUTURE RELEASES (Product Backlog)

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Create a mock initial backlog for the simulated project

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.3 Create a mock backlog

30-60 minutes

Step 3: Identify your MVP

1. Decide which "Features and Functions" will be in your MVP and which will be delivered in future releases:

YOUR MVP EPICS

YOUR MVP USER STORIES

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Create a mock initial backlog for the simulated project

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.4 Review
Sprint 0

Step 1: Set aside the Mock Backlog just created (you will be using the Backlog on Sprint 0 for remainder of exercise).
Step 2: Introduce and walk through the Backlog on the Sprint 0 tab in the Scrum Simulation Exercise.
Step 3: Discuss and answer any questions the participants may have about the Sprint 0 tab.
Step 4: Capture any important issues or clarifications from this discussion in the table below.

Important issues or clarifications from the Sprint 0 tab:

• (e.g. What is the difference between the project backlog and the product backlog?)
• (e.g. What do we do with user stories that are bigger than our sprint velocity?)
• (e.g. Has the project backlog been prioritized?)
• (e.g. How do we decide what to work on first?)

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Understand Sprint 0 for Scrum Simulation Exercise

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.4 Review
Sprint 0

30-60 minutes

1. Using the information found on the Sprint 0 tab, determine the projected timeline and cost for this project's first release:

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• How to determine expected cost and timeline for an Agile project

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

The Estimation Cone of Uncertainty

Simulation Exercise 1.6 Understanding minimum viable products (MVP)

30 minutes

1. Discuss your current understanding of MVP.

How do you describe/define MVP?

• (Discuss/capture your understanding of minimum viable product)

Note: Refer to the facilitator slides for more guidance on how to deliver this exercise

Output

• Capture your current understanding of Minimum Viable Product

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Facilitator slides: Explaining MVP

Notes and Instructions

The primary intent of this exercise is to explain the complex notion of MVP (it is one of the most misunderstood and contentious issues in Agile delivery). The exercise is intended to explain it in a simple and digestible way that will fundamentally change participants' understanding of MVP.
Note that the slide contains animations.

Imagine that your stakeholder tells you they want a blue 4-door sedan (consider this our "MVP" at this point), and you decide to build it the traditional way. As you build it (tires, then frame, then body, then joint body with frame and install engine), the stakeholder doesn't have anything they can use, and so they are only happy (and able to get value) at the end when the entire car is finished (point out the stakeholder "faces" go from unhappy to happy in the end).

Animation 1:
When we use Agile methods, we don't want to wait until the end before we have something the stakeholders can use. So instead of waiting until the entire car is completed, we decide our first iteration will be to give the stakeholder "a simple (blue) wheeled transportation device"…namely a skateboard that they can use for a little while (it's not a car, but it is something the stakeholder can use to get places).

Animation 2:
After the stakeholder has tried out the skateboard, we ask for feedback. They tell us the skateboard helped them to get around faster than walking, but they don't like the fact that it is so hard to maintain your balance on it. So, we add a handle to the skateboard to turn it into a scooter. The stakeholder then uses the scooter for a while. stakeholder feedback says staying balanced on the scooter is much easier, but they don't have a place to put groceries when they go shopping, so can we do something about that?

(Continued on next slide…)

Facilitator slides: Explaining MVP

Notes and Instructions

Animation 3:
So next we build the stakeholder a bicycle and let them use it for a while before asking for feedback. The stakeholder tells us they love the bicycle, but they admit they get tired on long trips, so is there something we can do about that?

Animation 4:
So next we add a motor to the bicycle to turn it into a motorcycle, and again we give it to the stakeholder to use for a while. When we ask the stakeholder for feedback, they tell us that they LOVE the motorcycle so much, and that because they love the feeling of the wind in their hair, they've decided that they no longer want a 4-door sedan, but instead would prefer a blue 2-door convertible.

Animation 5:
And so, for our last iteration, we build the stakeholder what they wanted (a blue 2-door convertible) instead of what they asked for (a blue 4-door sedan), and we see that they are happier than they would have been if we had delivered the traditional way.

INSIGHTS:
An MVP cannot be fully known at the beginning of a project (it is the "journey" of creating the MVP with stakeholders that defines what it looks like in the end).
Sometimes, stakeholders don't (or can't) know what they want until they see it.
There is no "straight path" to your MVP, you determine the path forward based on what you learned in the previous iterations.
This approach is part of the "power of Agile" and demonstrates why Agile can produce better outcomes and happier stakeholders.

Understanding minimum viable product

Use iterations to maximize value delivery

Use iterations to reduce accumulated risk

Understanding MVP
(always be ready to go live)

A great and wise pharaoh hires two architects to build his memorial pyramids.

Understanding MVP
(always be ready to go live)

Several years go by, and then…

Simulation Exercise 1.7 Plan your first sprint

30-60 minutes

Step 1: Divide participants into independent Scrum delivery teams (max 7-8 people per team) and assign a PO (5 minutes)
Step 2: Instruct each team to work together to decide on their "MVP strategy" for delivering this project (10-15 minutes)
Step 3: Have each team decide on which user stories they would put in their first sprint backlog (5-10 minutes)
Step 4: Have each team report on their findings. (10 minutes)

Output

• Experience deciding on an MVP strategy and creating your first sprint backlog

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.8 Do a sprint retrospective

30-60 minutes

Step 1: Thinking about the work you did in Exercise 3.2.7, identify what worked well and what didn't
Step 2: Create a list of "Start/Stop/Continue" items using the table below
Step 3: Present your list and discuss with other teams

1. Capture findings in the table below:

Output

• Experience performing a sprint retrospective

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.9 "What if" exercise (understanding what a fluid backlog really means)

30-60 minutes

1. As a team, consider what you would do in each of the following scenarios (treat each one as an independent scenario rather than cumulative):

Output

• A better understanding of how to handle change using a fluid project backlog

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.10 A Sprint 1 example

30-60 minutes

1. Consider the following example of what your Sprint 1 deliverable could be:

Output

• Better understanding of an MVP strategy

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.10 A Sprint 1 example

30-60 minutes

1. As a group, discuss this approach, including:
   1. The pros and cons of the approach.
   2. Is this a shippable increment?
   3. What more would you need to do to make it a shippable increment?
2. Capture your findings in the table below:

Output

• Better understanding of an MVP strategy

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 1.11 Simulate more sprints

30-60 minutes

1. As a group, continue to simulate more sprints for the online banking app:
   1. Simulate the planning, execution, demo, and retro stages for additional sprints
   2. Stop when you have had enough
2. Capture your learnings in the table below:

Output

• Better understanding of an MVP strategy

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Scrum Simulation Module

Simulate effective scrum practices

Activities

2.1 Execute the ball passing sprints

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Model and understand behavioral blockers and patterns affecting Agile teams and organizational culture.

Pass the balls – sprint velocity game

Goal 1. Pass as many balls as possible (Story Points) through the system during each sprint.
Goal 2. Improve your estimation and velocity after each retrospective.

Backlog

Points Completed

Rules:

1. Two people cannot touch the ball at the same time.
2. Only the first and last person can hold more than one ball at a time.
3. Every person on the Delivery Team must touch the ball at least once per sprint.
4. Each team must record its results during the retrospective.

Scoring:

1. One point for every ball that completes the system.
2. Minus one point for every dropped ball.

Epic 1: 3 sprints

1. 1-minute Planning
2. 2-minute Sprints
3. 1-minute Retrospective

Group Retrospective
Epic 2: 3 sprints (repeat)

1. 1-minute Planning
2. 2-minute Sprints
3. 1-minute Retrospective

Simulation Exercise 1.11 Simulate more sprints

30-60 minutes

Goal 1: Pass as many balls (Story Points) through the system during each sprint.
Goal 2: Improve your estimation and velocity after each retrospective.

1. Epic 1: 3 sprints
   1. 1-minute Planning
   2. 2-minute Sprints
   3. 1-minute Retrospective
2. Group Retrospective
3. Epic 2: 3 sprints
   1. 1-minute Planning
   2. 2-minute Sprints
   3. 1-minute Retrospective
4. Group Retrospective
5. Optionally repeat for additional sprints with team configurations or scenarios

Rules:

1. Two people cannot touch the ball at the same time.
2. Only the first and last person can hold more than one ball at a time.
3. Every person on the delivery team must touch the ball at least once per sprint.
4. Each team must record its results during the retrospective.

Scoring:

1. One point for every ball that completes the system.
2. Minus one point for every dropped ball.

Output

• Understand basic estimation, sprint, and retrospective techniques.
• Experience common Agile behavior challenges.

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Facilitator slides: Sprint velocity game

Goal:

Pass as many balls as possible through the system during each cycle.

Game Setup

• Divide into teams of 8-16 people. If you have a smaller group, form one team rather than two smaller teams to start. The idea is to cause chaos with too many people in the delivery flow. See alternate versions for adding additional Epics with smaller teams.
• Read out the instructions and ensure teams understand each one. Note that no assistance will be given during the sprints.

Use your phone's timer to create 2-minute cycles:

• 1-minute sprint planning
• 2-minute delivery sprint
• 1-minute retrospective and results recording
• Run 3-4 cycles, then stop for a facilitated discussion of their observations and challenges.
• Begin epic 2 and run for 3-4 more cycles.

Facilitator slides: Sprint velocity game

• Game Cycles
• Epic 1: 3 complete cycles
• 1-minute Planning
• 2-minute Sprints
• 1-minute Sprint retrospective
• Group Retrospective
• Discuss each sprint, challenges, and changes made to optimize throughput.
• Epic 2: 3 complete cycles
• 1-minute Planning
• 2-minute Sprints
• 1-minute Sprint retrospective
• Group Retrospective
• Discuss each sprint, challenges, and changes made to optimize throughput.
• Game Rules
• Each ball must have airtime. No ball cannot touch two people at the same time.
• No person can hold more than one ball at a time.
• Ball must be passed by every person on a team.
• You may not pass a ball to a person directly to the person on your left or right.
• Each team must keep score and record their results during the Retrospective.
• Scoring
• 1 point for every ball that completes the system.
• Minus 1 point for every dropped ball.

Facilitator slides: Sprint velocity game

Facilitator Tips

• Create a feeling of competition to get the teams to rush and work against each other. The goal is to show how this culture must be broken in Agile and DevOps. Then challenge the teams against natural silos and not focus on enterprise goals.
• Create false urgency to increase stress, errors, and breakdowns in communication.
• Look for patterns of traditional delivery and top-down management that limit delivery. These will emerge naturally, and teams will fall back into familiar patterns under stress.
• Look for key lessons you want to reinforce and bring out ball game examples to help teams relate to something that is easier to understand.

Alternate Versions

• Run Epic 1 as one team, then have them break into typical Agile teams of 4-9 people. Compare results.
• Run Epics with different goals: How would their approach change?
• Fastest delivery
• Highest production
• Lowest defect rate
• Have teams assign a scrum master to coordinate delivery. A scrum master and product owner are part of the overall team, but not part of the delivery team. They would not need to pass balls during each sprint.
• Increase sprint time. Discuss right sizing sprint to complete work.
• Give each team different numbers of balls, but don't tell them. Alternately, start each team with half as many balls, then double for Epic 2. Discuss how the sprint backlog affected their throughput.

Facilitator slides: Sprint velocity game

Trends to Look For and Discuss

• False constraints - patterns where teams unnecessarily limited themselves.
• Larger teams could have divided into smaller working teams, passing the balls between working groups.
• Instructions did not limit that "team" meant everyone in the group. They could have formed smaller groups to process more work. LEAN
• Using the first sprint for planning only. More time to create a POC.
• Teams will start communicating but will grow silent, especially in later sprints. Stress interactions over the process.
• Borrowing best practices from other teams.
• Using retrospectives to share ideas with other teams. Stress needs to align with the company's goals, not just the team's goals.
• How did they treat dropped balls? Rejected as errors, started over (false constraint), or picked up and continued?

Trends to Look For and Discuss

• Did individuals dominate the planning and execution, or did everyone feel like an equal member of the team?
• Did they consider assigning a scrum master? The scrum master and product owner are part of the overall team, but not part of the Delivery Team. They would not need to pass balls during each Sprint.
• What impacted their expected number of balls completed? Did it help improve quality or was it a distraction?
• What caused their improvement in velocity? Draw the connection between how teams must work together and the need for stability.
• Discuss the overall goal and constraints. Did they understand what the desired outcome was? Where did they make assumptions? Add talking points:
• What if the goal was overall completed balls?
• What if it was zero defect? No dropped balls.
• What if it was the fastest delivery? Each ball through the system in the shortest time? Were they timing each ball?

Scrum Simulation Module

Simulate effective scrum practices

Activities

3.1 Identify key insights and takeaways

3.2 Perform exit survey and capture results

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your key insights and takeaways

Simulation Exercise 3.1
Identify key insights and takeaways

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the Intro to Agile presentation?
   2. What if any takeaways do participants feel are needed as a result of the presentation?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Simulation Exercise 3.2
Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Agile Modules

Prioritize Agile support with your top challenges

Organizations often struggle with numerous pain points around Agile delivery.
The Common Agile Challenges Survey results will help you identify and prioritize the organization's biggest (most cited) pain points. Treat these pain points like a backlog and address the biggest ones first.

Agile modules provide supporting activities:

Each module provides guidance and supporting activities related to a specific Agile Challenge from your survey. These modules can be arranged to meet each organization's or team's needs while providing cohesive and consistent messaging. For additional supporting research, please visit the Agile / DevOps Resource Center.

This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Estimation Module

Improve product backlog item estimation

Activities

1.1 Identify your estimation pains

1.2 (Optional) Why do we estimate?

1.3 How do you estimate now?

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of Agile estimation practices and how to apply them.

Establish consistent Agile estimation fundamentals

Know the truth about estimates and their potential pitfalls.

Then, understand how Agile estimation works to avoid these pitfalls.

Estimation Exercise 1.1 Identify your estimation pains

30-60 minutes

1. As a group, discuss and capture your thoughts on:
   1. What specific challenges are you facing with your estimation practices today
   2. Capture your findings in the table below:

Output

• Your specific estimation related challenges

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 1.2 (Optional) Why do we estimate?

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. Why do we do estimates?
   2. What value/merit do estimates have?
2. Capture your findings in the table below:

Output

• Better understanding of the need for estimates

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 1.2 (Optional) Why do we estimate?

30 minutes

1. Estimation has its merits
2. Here are some sample reasons for estimates:
   • "Estimates allow us to predict when a sprint goal will be met, and therefore when a substantial increment of value will be delivered."
   • "Our estimates help our stakeholders plan ahead. They are part of the value we provide."
   • "Estimates help us to de-risk scope of uncertain size and complexity."
   • "Estimated work can be traded in and out of scope for other work of similar size. Without estimates, you can't trade."
   • "The very process of estimation adds value. When we estimate we discuss requirements in more detail and gain a better understanding of what is needed."
   • "Demonstrates IT's commitment to delivering valuable products and changes."
   • "Supports business ambitions with customers and stakeholders."
   • "Helps to build a sustainable value-delivery cadence."

Source: DZone, 2013.

Output

• Better understanding of the need for estimates

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 1.3 How do you estimate now?

30 minutes

1. As a group, speak about now you currently estimate in your organization.
2. Capture your findings in the table below:

Output

• Your current estimation approach

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Module

Improve product backlog item estimation

Activities

2.1 (Optional) Estimate a real PBI

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of Agile estimation practices and how to apply them.

Don't expect your estimates to be accurate!

The average rough order of magnitude estimates for software are off by is up to 400%.
Source: Boehm, 1981

Estimate inaccuracy has many serious repercussions on the project and organization

(1) % of software projects with given issue

Source: McKinsey & Company, 2012

The Estimation Cone of Uncertainty

What is Agile estimation?

There is no single Agile estimation technique. When selecting an approach, adopt an Agile estimation technique that works for your organization, and don't be afraid to adapt it to your circumstances. Remember: all estimates are wrong, so use them with care and skepticism.

• Understands and accepts the limitations of any estimation process.
• Leverages good practices to counteract these limitations (e.g. wisdom of crowds, quality-first thinking).
• Doesn't over-invest in individual estimate accuracy (but sees their value "in aggregate").
• Approach can change from project to project or team to team and evolves/matures over the project lifespan.
• Uses the estimation process as an effective tool to:
• Make commitments about what can be accomplished in a sprint (to establish capacity).
• Convey a measure of progress and rough expected completion dates to stakeholders (including management).

Info-Tech Insight

All estimates are wrong, but some can be useful (leverage the "wisdom of crowds" to improve your estimation practices).

There are many Agile estimation techniques to choose from…

Ensure your teams have the right information

Estimate accuracy and consistency improve when it is clear what you are estimating (definition of ready) and what it means to complete the PBI (definition of done).
Be sure to establish and enforce your definition of ready/done throughout the project.

What are story points?

Many organizations use story point sizing to estimate their PBIs
(e.g. epics, features, user stories, and tasks)

• A story point is a (unitless) measure of the relative size, complexity, risk, and uncertainty, of a PBI.
• Story points do not correspond to the exact number of hours it will take to complete the PBI.
• When using story points, think about them in terms of their size relative to one another.
• The delivery team's sprint velocity and capacity should also be tracked in story points.

How do you assign a point value to a user story? There is no easy answer outside of leveraging the experience of the team. Sizes are based on relative comparisons to other PBIs or previously developed items. Example: "This user story is 3 points because it is expected to take 3 times more effort than that 1-point user story."Therefore, the measurement of a story point is only defined through the team's experience, as the team matures.

Can you equate a point to a unit of time? First and foremost, for the purposes of backlog prioritization, you don't need to know the time, just its size relative to other PBIs. For sprint planning, release planning, or any scenario where timing is a factor, you will need to have a reasonably accurate sprint capacity determined. Again, this comes down to experience.

"Planning poker" estimation technique

Leverage the wisdom of crowds to improve your estimates

Planning poker: This approach uses the Delphi method, where a group collectively estimates the size of a PBI or user story, using cards with story points on them.

Materials: Each participant has deck of cards, containing the numbers of the Fibonacci sequence.

Typical Participants: Product owner, scrum master (usually acts as facilitator), delivery team.

Steps:

1. The facilitator will select a user story.
2. The product owner answers any questions about the user story from the group.
3. The group makes their first round of estimates, where each participant individually selects a card without showing it to anyone, and then all selections are revealed at once.
4. If there is consensus, the facilitator records the estimate and moves onto step 1 for another user story.
5. If there are discrepancies, the participants should state their case for their selection (especially high or low outliers) and engage in constructive debate.
6. The group makes an additional round of estimates, where step 3-6 are completed until there is a reasonable consensus.
7. If the consensus is the user story is too large to fit into a sprint or too poorly defined, then the user story should be decomposed or rewritten.

Estimation Exercise 2.1 (Optional) Estimate a real PBI

30-60 minutes

Step 1: As a group, select a real epic, feature, or user story from one of your project backlogs which needs to be estimated:

Step 2: Select one person in your group to act as the product owner and discuss/question the details of the selected PBI to improve your collective understanding of the requirement (the PO will do their best to explain the PBI and answer any questions).
Step 3: Make your first round of estimates using either T-shirt sizing or the Fibonacci sequence. Be sure to agree on the boundaries for these estimates (e.g. "extra-small" (XS) is any work that can be completed in less than an hour, while "extra-large" (XL) is anything that would take a single person a full sprint to deliver – a similar approach could be used for Fibonacci where a "1" is less than an hour's work, and "21" might be a single person for a full sprint). Don't share your answer until everyone has had a chance to decide on their Estimate value for the PBI.
Step 4: Have everyone share their chosen estimate value and briefly explain their reasoning for the estimate. If most estimate values are the same/similar, allow the group to decide whether they have reached a "collective agreement" on the estimate. If not, repeat step 3 now that everyone has had a chance to explain their initial Estimate.
Step 5: Capture the "collective" estimate for the PBI here:

Output

• A real PBI from your project backlog which has estimated using planning poker

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Module

Improve product backlog item estimation

Activities

3.1 Guess the number of jelly beans (Round 1) (15 minutes)
3.2 Compare the average of your guesses (15 minutes)
3.3 Guess the number of gumballs (Round 2) (15 minutes)
3.4 Compare your guesses against the actual number

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• A better understanding of why Agile estimation and reconciliation provides reliable estimates for planning.

Facilitator Slides: Agile Estimation (Wisdom of Crowds Exercise – Rounds 1 and 2)

Notes and Instructions

The exercise is intended to mimic the way Planning Poker is performed in Agile Estimation. Use the exercise to demonstrate the power of the Wisdom of Crowds and how, in circumstances where the exact answer to a question is not known, asking several people for their opinion often produces more accurate results than most/any individual opinion.

Some participants will tend to "shout out an answer" right away, so be sure to tell participants not to share their answers until everyone has had an opportunity to register their guess (this is particularly important in Round 1, where we are trying to get unvarnished guesses from the participants).

In Round 1:

• Be sure to emphasize that participants are guessing the total number of jelly beans in the jar (sometimes people think it is just the number visible)
• Once all guesses are gathered and you've calculated the error for them (and the average guess), review the results with participants (Note: the actual number of jelly beans in the jar is 1600 (it is "greyed out" on the bottom line of the table – you can make it visible by turning off the grey highlight on that cell in the table)
• Most of the time, the average guess will be closer to the actual than most (if not all) individual guesses (but be prepared for the fact that this doesn't always happen – this is especially true when the number of participants is small)
• When discussing the results, ask participants to share the "method" they used to make their guess (particularly those who were closest to the actual). This part of the exercise can help them to make more accurate guesses in Round 2

In Round 2:

• Note that this time, participants are guessing the total number of visible gumballs in the image (both whole and partial gumballs are counted)
• Once all guesses are gathered and you've calculated the error for them (and the average guess), review the results with participants (Note: the actual number of visible gumballs is 1600 (it is "greyed out" on the bottom line of the table – you can make it visible by turning off the grey highlight on that cell in the table)
• Most of the time, the average guess will be closer to the actual in Round 2 than it was in Round 1
• Talk to participants about the outcomes and how the results varied from Round 1 to Round 2, along with any interesting insights they may have gained from the exercise

Estimation Exercise 3.1 Guess the number of jelly beans (Round 1)

15 minutes

1. Option 1: Microsoft Forms
   1. Create your own local survey by copying the template using the link below.
   2. Add the local Survey link to the exercise instructions or send the link to the participants.
   3. Give the participants 2-3 minutes to complete their guesses.
   4. Collect the consolidated Survey responses and calculate the results on the next slide.
   5. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst or Workshop Specialist can set up the survey for you.
2. Option 2: Embedded Excel table
   1. On the results slide, double-click the table to open the embedded Excel worksheet.
   2. Record each participant's guess in the table.
3. Alternatively, this survey can be done with sticky notes, a pen, paper, and a calculator to determine the outcomes.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 3.1 Guess the number of jelly beans (Round 1)

15 minutes

1. Guess the total number of jelly beans in the entire container (not just the ones you can see).
2. Be sure not to share your guess with anyone else.
3. It doesn't matter how you settle on your guess ("gut feel" is fine, so is being "scientific" about it, as well as everything in between).
4. Again, please don't share your guess (or even how you settled on your guess) with anyone else (this exercise relies on independent guesses).

See slide notes for instructions.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 3.2 Compare the average of your guesses

15 minutes

See slide notes for instructions.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Guess the number of gumballs

• Option 1: Microsoft Forms
• Create your own local survey by copying the template using the link below.
• Add the local Survey link to the exercise instructions or send the link to the participants.
• Give the participants 2-3 minutes to complete their guesses.
• Collect the consolidated Survey responses and calculate the results on the next slide.
• NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst or Workshop Specialist can set up the survey for you.
• Option 2: Embedded Excel table
• On the results slide, double-click the table to open the embedded Excel worksheet.
• Record each participant's guess in the table.
• Alternatively, this survey can be done with sticky notes, a pen, paper, and a calculator to determine the outcomes.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• PM's, PO's and SM's
• Delivery Managers
• Delivery Teams
• Business Stakeholders
• Senior Leaders
• Other Interested Parties

Estimation Exercise 3.3 Guess the number of gumballs (Round 2)

15 minutes

1. Guess the total number of gumballs visible in the photo shown on the right.
2. Again, please don't share your guess with anyone.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• PM's, PO's and SM's
• Delivery Managers
• Delivery Teams
• Business Stakeholders
• Senior Leaders
• Other Interested Parties

Estimation Exercise 3.2 Compare the average of your guesses

15 minutes

See slide notes for instructions.

Output

• An appreciation for the power of the wisdom of crowds

Participants

• PM's, PO's and SM's
• Delivery Managers
• Delivery Teams
• Business Stakeholders
• Senior Leaders
• Other Interested Parties

Estimation Module

Improve product backlog item estimation

Activities

4.1 Identify key insights and takeaways
4.2 Perform exit survey and capture results

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your key insights and takeaways.

Estimation Exercise 4.2
Identify key insights and takeaways

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the Intro to Agile presentation?
   2. What if any takeaways do participants feel are needed as a result of the presentation?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Estimation Exercise 4.2
Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Agile Modules

Prioritize Agile support with your top challenges

Organizations often struggle with numerous pain points around Agile delivery.
The Common Agile Challenges Survey results will help you identify and prioritize the organization's biggest (most cited) pain points. Treat these pain points like a backlog and address the biggest ones first.

Agile modules provide supporting activities:

Each module provides guidance and supporting activities related to a specific Agile Challenge from your survey. These modules can be arranged to meet each organization's or team's needs while providing cohesive and consistent messaging. For additional supporting research, please visit the Agile / DevOps Resource Center.

This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Product Owner Module

Establish an effective product owner role

Activities

1.1 Identify your product owner pains
1.2 What is a "product"? Who are your "consumers"?
1.3 Define your role terminology

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand product management fundamentals.
• Define your product management roles and terms.

Product owners ensure we delivery the right changes, for the right people, at the right time.

The importance of assigning an effective and empowered product owner to your Agile projects cannot be overstated.

What is a product?

A tangible solution, tool, or service (physical or digital), which enables the long-term and evolving delivery of value to customers, and stakeholders based on business and user requirements.

Info-Tech Insight

A proper definition of a product recognizes three key facts.

1. A clear recognition that products are long-term endeavors that don't end after the project finishes.
2. Products are not just 'apps', but can be software or services that drive value.
3. There is more than one stakeholder group that derives value from the product or service.

Estimation Exercise 4.2
Perform an exit survey

30-60 minutes

1. As a group, discuss and capture your thoughts on:
   • What specific challenges are you facing with your product owner practices today?
2. Capture your findings in the table below:

Output

• Your specific product owner challenges

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Product Owner Exercise 1.2 What is a "product"? Who are your "consumers"?

30-60 minutes

1. Discussion:
   1. How do you define a product, service, or application?
   2. Who are the consumers that receive value from the product?

Input

• Organizational knowledge
• Internal terms and definitions

Output

• Our definition of products and services
• Our definition of product and service consumers/customers

Products and services share the same foundation and best practices

The term "product" is used for consistency but would apply to services as well.

"Product" and "Service" are terms that each organization needs to define to fit its culture and customers (internal and external). The most important aspect is consistent use and understanding of:

• External products
• Internal products
• External services
• Internal services
• Products as a service (PaaS)
• Productizing services (SaaS)

Recognize the different product owner perspectives

• Business
• Customer facing, revenue generating
• Operations
• Keep the lights on processes
• Technical
• IT systems and tools

"A product owner in its most beneficial form acts like an Entrepreneur, like a 'mini-CEO'. The product owner is someone who really 'owns' the product."

– – Robbin Schuurman,
"Tips for Starting Technical Product Managers"

Info-Tech Best Practice

Product owners must translate needs and constraints from their perspective into the language of their audience. Kathy Borneman, Digital Product Owner at SunTrust Bank, noted the challenges of finding a common language between lines of business and IT (e.g. what is a unit?).

Implement Info-Tech's product owner capability model

Unfortunately, most product owners operate with an incomplete knowledge of the skills and capabilities needed to perform the role. Common gaps include focusing only on product backlogs, acting as a proxy for product decisions, and ignoring the need for key performance indicators (KPIs) and analytics in both planning and value realization.

Scale products into families to improve alignment

Operationally align product delivery to enterprise goals

The Info-Tech difference:

Start by piloting product families to determine which approaches work best for your organization.

Create a common definition of what a product is and identify products in your inventory.

Use scaling patterns to build operationally aligned product families.

Develop a roadmap strategy to align families and products to enterprise goals and priorities.

Use products and families to evaluate the delivery and organizational design improvements.

Select the right models for scaling product management

• Pyramid
• Logical hierarchy of products rolling into a single service area.
• Lower levels of the pyramid focus on more discrete services.
• Example: Human resources mapping down to supporting applications.
• Service Grouping
• Organization of related services into service family.
• Direct hierarchy does not necessarily exist within the family.
• Example: End user support and ticketing.
• Technical Grouping
• Logical grouping of IT infrastructure, platforms, or applications.
• Provides full lifecycle management when hierarchies do not exist.
• Example: Workflow and collaboration tools.
• Market Alignment
• Grouping of products by customer segments or market strategy.
• Aligns product to end users and consumers.
• Example: Customer banking products and services.
• Organizational Alignment
• Used at higher levels of the organization where products are aligned under divisions.
• Separation of product management from organizational structure no longer distinct.

Match your product management role definitions to your product family levels

Product Ownership exists at the different operational tiers or levels in your product hierarchy. This does not imply or require a management relationship.

Product Portfolio
Groups of product families within an overall value stream or capability grouping.
Product Portfolio Manager

Product Family
A collection of related products. Products can be grouped along architectural, functional, operational, or experiential patterns.
Product Family Manager

Product
Single product composed of one or more applications and services.
Product Owner

Info-Tech Insight

The primary role conflict occurs when the product owner is a proxy for stakeholders or responsible for the delivery team. The product owner owns the product backlog. The delivery team owns the sprint backlog and delivery.

Examine the differences between product managers and product owners

Product management terminology is inconsistent, creating confusion in organizations introducing these roles. Understand the roles, then define terms that work best for you.

Define who manages key milestone

Key milestones must be proactively managed. If a project manager is not available, those responsibilities need to be managed by the Product Owner or Scrum Master. Start with responsibility mapping to decide which role will be responsible.

Product Owner Exercise 1.3 Define your role terminology

30-60 minutes

1. Using consistent terms is important for any organizational change and evergreen process. Capture your preferred terms to help align teams and expectations.

Output

• Product management role definitions

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Product Owner Module

Establish an effective product owner role

Activities

2.1 Identify enablers and blockers

2.2 (Optional) Dissect this definition of the product owner role

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify cultural enablers and blockers for product owners.
• Develop a deeper understanding of the product owner role.

The importance of establishing an effective product owner role

The critical importance of establishing an effective product owner role (PO) for your Agile projects cannot be overstated.

Many new-to-Agile organizations do not fully appreciate the critical role played by the PO in Scrum, nor the fundamental changes the organization will need to make in support of the PO role. Both mistakes will reduce an organization's chances of successfully adopting Agile and achieving its promised benefits.

The PO role is critical to the proper prioritization of requirements and efficient decision-making during the project.

The PO role helps the organization to avoid "analysis paralysis" challenges often experienced in large command-and-control-style organizations.

A poorly chosen or disengaged product owner will almost certainly stifle your Agile project.

Note that for many organizations, "product owner" is not a formally recognized role, which can create HR issues. Some organizational education on Agile may be needed (especially if your organization is unionized).

Info-Tech Insight

Failing to establish effective product owners in your organization can be a "species-killing event" for your Agile transformation.

The three A's of a product owner

To ensure the effectiveness of a product owner, your organization should select one that meets the three A's:

Available: Assign a PO that can focus full-time on the project. Make sure your PO can dedicate the time needed to fulfill this critical role.
Appropriate: It's best for the PO to have strong subject matter expertise (so-called "super users" are often selected to be POs) as well as strong communication, collaboration, facilitation, and arbitration skills. A good PO will understand how to negotiate the best outcomes for the project, considering all project constraints.
Authoritative: The PO must be empowered by your organization to speak authoritatively about priorities and goals and be able to answer questions from the project team quickly and efficiently. The PO must know when decisions can be made immediately and when they must be made in collaboration with other stakeholders – choosing a PO that is well-known and respected by stakeholders will help to make this more efficient.

Info-Tech Insight

It's critical to assign a PO that meets the three A's:

• Available
• Appropriate
• Authoritative

The three ears of a product owner*

An effective product owner listens to (and effectively balances) the needs and constraints of three different groups:

Organizational needs/constraints represent what is most important to the organization overall, and typically revolve around things like cost, schedule, return on investment, time to market, risk mitigation, conforming to policies and regulations, etc.

Stakeholder needs/constraints represent what is most important to those who will be using the system and typically revolve around the delivery of value, ease of use, better outcomes, making their jobs easier and more efficient, getting what they ask for, etc.

Delivery Team needs/constraints represent what is most important to those who are tasked with delivering the project and cover a broad range that includes tools, skills, capabilities, technology limitations, capacity limits, adequate testing, architectural considerations, sustainable workload, clear direction and requirements, opportunities to innovate, getting sufficient input and feedback, support for clearing roadblocks, dependencies on other teams, etc.

Info-Tech Insight

An effective PO will expertly balance the needs of:

• The organization
• Project stakeholders
• The delivery team

* For more, see Understanding Scrum: Why do Product Owners Have Three Ears

A product owner doesn't act alone

Although the PO plays a unique and central role in the success of an Agile project, it doesn't mean they "act alone."

The PO is ultimately responsible for managing and maintaining an effective backlog over the project lifecycle, but many people contribute to maintaining this backlog (on large projects, BA's are often the primary contributors to the backlog).

The PO role also relies heavily on stakeholders (to help define and elaborate user stories, provide input and feedback, answer questions, participate in sprint demos, participate in testing of sprint deliverables, etc.).

The PO role also relies heavily on the delivery team. Some backlog management and story elaboration is done by delivery team members instead of the PO (think: elaborating user story details, creating acceptance criteria, writing test plans for user stories, etc.).

The PO both contributes to these efforts and leads/oversees the efforts of others. The exact mix of "doing" and "leading" can be different on a case-by-case basis and is part of establishing the delivery team's norms.

Given the importance of the role, care must be taken to not overburden the product owner, especially on large projects.

Info-Tech Insight

While being ultimately responsible for the product backlog, a PO often relies on others to aid in backlog management and maintenance.

This is particularly true on large projects.

The use of a proxy PO

Sometimes, a proxy product owner is needed.

It is always best to assign a product owner "from the business," who will bring subject matter expertise and have established relationships with stakeholders.

When a PO from the business does not have enough time to fulfill the needs of the role completely (e.g. can only be a part-time PO, because they have a day job), assigning a proxy product owner can help to compensate for this.

The proxy PO acts on behalf of the PO in order to reduce the PO's workload or to otherwise support them.

Project participants (e.g. delivery team, stakeholders) should treat the PO and proxy PO as roughly equivalent.

Project managers (PMs) and business analysts (BAs) are often good candidates for the proxy PO role.

NOTE: It's highly advisable for the PO to attend all/most sprint demos in order to observe progress for themselves, and to identify any misalignment with expectations as early as possible (remember that the PO still has ultimate responsibility for the project outcomes).

Info-Tech Insight

Although not ideal, assigning a proxy PO can help to compensate for a PO who doesn't meet all three A's of Product Ownership.

It is up to the PO and proxy to decide how they will work together (e.g. establish their norms).

The use of a proxy PO

The PO and proxy must work together closely and in a highly coordinated way.

The PO and proxy must:

• Work closely at the start of the project to agree on the overall approach they will follow, as well as any needs and constraints for the project.
• Communicate frequently and effectively throughout the project, to ensure progress is being made and to address any challenges.
• Have a "meeting of the minds" about how the different "parts" of the PO role will be divided between them (including when the proxy must defer to the PO on matters).
• Focus on ensuring that all the responsibilities of the PO role are fulfilled effectively by the pair (how this is accomplished is up to the two of them to decide).
• Ensure all project participants clearly understand the POs' and proxies' relative responsibilities to minimize confusion and mistakes.

The use of multiple POs

Sometimes, having multiple product owners makes sense.

It is always best to assign a single product owner to a project. However, under certain circumstances, it can make sense to use multiple POs.

For example, when implementing a large ERP system with many distinct modules (e.g. Finance, HR) it can be difficult to find a single PO who has sufficient subject matter expertise across all modules.

When assigning Multiple POs to a project, be sure to identify a "Lead PO" (who is given ultimate responsibility for the entire project) and have the remaining POs act like Proxy POs.

NOTE: Not surprisingly, it's highly advisable for the Lead PO to attend as many Sprint Demos as possible to observe progress for themselves, and to identify any misalignment with expectations as early as possible (remember that the Lead PO has ultimate responsibility for the project outcomes).

Info-Tech Best Practice

Although not ideal, assigning multiple POs to a project sometimes makes sense.

When needed, be sure to identify a "Lead PO" and have the other PO's act like Proxies.

Product Owner Exercise 2.1 Identify enablers and blockers

30-60 minutes

1. Brainstorm and discuss the key enablers that can help promote and ease your implementation of Product Ownership.
2. Brainstorm and discuss the key blockers (or risks) that may interrupt or derail your efforts.
3. Brainstorm mitigation activities for each blocker.

Output

• List of enablers and blockers to establishing product owners

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Establish an effective product owner role

• The nature of a PO role can be somewhat foreign to many organizations, so candidates for the role will benefit from training along with coaching/mentoring support when starting out.
• The PO must be able to make decisions quickly around project priorities, goals, and requirements.
• A PO who is simply a conduit to a slow-moving steering committee will stifle an Agile project.
• Establish clear boundaries and rules regarding which project decisions can be made directly by the PO and which must be escalated to stakeholders. Lean toward approaches that support the quickest decision-making (e.g. give the PO as much freedom as they need to be effective).
• An effective PO has a good instinct for what is "good enough for now."
• The organization can support the PO by focusing attention on goals and accomplishments rather than pushing processes and documentation.
• Understand the difference between a project sponsor and a PO (the PO role is much more involved in the details, with a higher workload).
• Agree on and clearly define the roles and responsibilities of PO, PM, dev manager, SM, etc. at the start of the project for clarity and efficiency.

Characteristics to look for when selecting a product owner

Here are some "ideal characteristics" for your POs (the more of these that are true for a given PO, the better):

• Knows how to get things done in your organization
• Has strong working relationships with project stakeholders (has established trust with them and is well respected by stakeholders as well as others)
• Comes from the stakeholder community and is invested in the success of the project (ideally, will be an end user of the system)
• Has proven communication, facilitation, mediation, and negotiation skills
• Can effectively balance multiple competing priorities and constraints
• Sees the big picture and strives to achieve the best outcomes possible (grounded in realistic expectations)
• Works with a sense of urgency and welcomes ongoing feedback and collaboration with stakeholders
• Understands how to act as an effective "funnel and filter" for stakeholder requests
• Acts as an informal (but inspirational) leader whom others will follow
• Has a strong sense of what is "good enough for now"
• Protects the delivery team from distractions and keeps them focused on goals
• Thinks strategically and incrementally

Product Owner Exercise 2.2 (Optional) Dissect this definition of the product owner role

30-60 minutes

1. Take a minute or two to review the bullet points below, which describe the product owner's role.
2. As a group, discuss the "message" for each bullet point in the description, and then identify which aspects would be "easy" and "hard" to achieve in your organization.
   • The product owner is a project team member who has been empowered by both the organization and stakeholders to act on their behalf and to guide the project directly with a single voice (supported by appropriate consultations with the organization and stakeholders).
   • The product owner must be someone with a good understanding of the project deliverable (they are often considered to be a subject matter expert in an area related to the project deliverable) and ideally is both well-known and respected by both the organization and stakeholders.
   • During the project, requirements clarification, prioritization, and scope changes are ultimately decided by the product owner, who must perform the important balancing act required by the project to adequately reflect the needs and constraints of the organization, its stakeholders, and the project team.
   • The product owner role can only be successful in an organization that has established a trusting and supportive culture. Great trust must be placed in the product owner to adequately balance competing needs in a way that leads to good outcomes for the organization. This trust must come with some authority to make important project decisions, and the organization must also support the product owner in addressing risks and roadblocks outside the control of the project team.
   • The product owner is first among equals when it comes to ultimate ownership of success for the project (along with the project delivery team itself). Because of this, any project of any significance will require the full-time effort of the product owner (don't shortchange yourself by under-investing in a willing, able, and available product owner)

Output

• Better understanding of the product owner role.

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Product Owner Exercise 2.2 (Optional) Dissect this definition of the product owner role

Product Owner Module

Establish an effective product owner role

Activities

3.1 Build a starting checklist of quality filters

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand the levels in a product backlog and how to create quality filters for PBIs moving through the backlog.
• Define your product roadmap approach for key audiences.

Product Owner Step 3: Managing effective product backlogs and roadmaps

The primary role of the product owner is to manage the backlog effectively.

When managed properly, the product backlog is a powerful project management tool that directly contributes to project success.

The product owner's primary responsibility is to ensure this backlog is managed effectively.

A backlog stores and organizes PBIs at various stages of readiness

A well-formed backlog can be thought of as a DEEP backlog:

• Detailed Appropriately: Product backlog items (PBIs) are broken down and refined as necessary.
• Emergent: The backlog grows and evolves over time as PBIs are added and removed.
• Estimated: The effort a PBI requires is estimated at each tier.
• Prioritized: The PBIs value and priority are determined at each tier.

(Perforce, 2018)

Backlog tiers facilitate product planning steps

Each activity is a variation of measuring value and estimating effort to validate and prioritize a PBI.

A PBI meets our definition of done and passes through to the next backlog tier when it meets the appropriate criteria. Quality filters should exist between each tier.

Backlog Exercise 2.1 Build a starting checklist of quality filters

60 minutes

1. Quality filters provide a checklist to ensure each Product Backlog Item (PBI) meets our definition of Done and is ready to move to the next backlog group (status).
2. Create a checklist of basic descriptors that must be completed between each backlog level.
3. If you completed this exercise in a different Module, review and update it here.
4. Use this information to start your product strategy playbook in Deliver on Your Digital Product Vision.

Output

• List of enablers and blockers to establishing product owners

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Outline the criteria to proceed to the next tier via quality filters

Expand the concepts of defining "ready" and "done" to include the other stages of a PBIs journey through product planning.

Info-Tech Insight: A quality filter ensures quality is met and teams are armed with the right information to work more efficiently and improve throughput.

Define product value by aligning backlog delivery with roadmap goals

In each product plan, the backlogs show what you will deliver.

Roadmaps identify when and in what order you will deliver value, capabilities, and goals.

Product roadmaps guide delivery and communicate your strategy

In Deliver on Your Digital Product Vision, we demonstrate how the product roadmap is core to value realization. The product roadmap is your communicated path, and as a product owner, you use it to align teams and changes to your defined goals while aligning your product to enterprise goals and strategy.

Adapted from: Pichler, "What Is Product Management?"

Info-Tech Insight

The quality of your product backlog – and your ability to realize business value from your delivery pipeline – is directly related to the input, content, and prioritization of items in your product roadmap.

Product delivery realizes value for your product family

While planning and analysis are done at the family level, work and delivery are done at the individual product level.

Leverage the product family roadmap for alignment

It's more than a set of colorful boxes. It's the map to align everyone to where you are going.

• Your product family roadmap:
• Lays out a strategy for your product family.
• Is a statement of intent for your family of products.
• Communicates direction for the entire product family and product teams.
• Directly connects to the organization's goals.
• However, it is not:
• Representative of a hard commitment.
• A simple combination of your current product roadmaps.

Your ideal roadmap approach is a spectrum, not a choice!

Match your roadmap and backlog to the needs of the product.

Product Managers do not have to choose between being tactical or strategic.
– Aha!, 2015

Multiple roadmap views can communicate differently yet tell the same truth

Product Owner Exercise 3.1 Build a starting checklist of quality filters

60 minutes

1. Views provide roadmap information to different audiences in the format and level of detail that is fit to their purpose.
2. Consider the three primary audiences for roadmap alignment.
3. Define the roles or people who the view best fits.
4. Define the level of detail or artifacts shared in the view for each audience.
5. Use this information to start your product strategy playbook in Deliver on Your Digital Product Vision.

Output

• List of enablers and blockers to establishing product owners

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Connecting your product family roadmaps to product roadmaps

Your product and product family roadmaps should be connected at an artifact level that is common between both. Typically, this is done with capabilities, but it can be done at a more granular level if an understanding of capabilities isn't available.

Use product roadmaps to align cross-team dependencies

Regardless of how other teams operate, teams need to align to common milestones.

Product Owner Module

Establish an effective product owner role

Activities

4.1 Identify key insights and takeaways

4.2 Perform exit survey and capture results

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Identify your key insights and takeaways.

Product Owner Exercise 4.1
Identify key insights and takeaways

30 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the Intro to Agile presentation?
   2. What if any takeaways do participants feel are needed as a result of the presentation?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Product Owner Exercise 4.2
Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Agile Modules

Prioritize Agile support with your top challenges

Organizations often struggle with numerous pain points around Agile delivery.
The Common Agile Challenges Survey results will help you identify and prioritize the organization's biggest (most cited) pain points. Treat these pain points like a backlog and address the biggest ones first.

Agile modules provide supporting activities:

Each module provides guidance and supporting activities related to a specific Agile challenge from your survey. These modules can be arranged to meet each organization's or team's needs while providing cohesive and consistent messaging. For additional supporting research, please visit the Agile / DevOps Resource Center.

This phase involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Product Roadmapping

Create effective product roadmaps

Activities

Roadmapping 1.1 Identify your product roadmapping pains
Roadmapping 1.2 The six "tools" of product roadmapping
Roadmapping 1.3 Product roadmapping exercise

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand product management fundamentals
• Understand the six "tools" of roadmapping and how to use them

Roadmapping Exercise 1.1: Tell us what product management means to you and how it differs from a project orientation

10-15 minutes

1. Share your current understanding of product management.

Output

• Your current understanding of product management and its benefits

Participants

• PMs, Pos, and SMs
• Delivery managers
• Delivery teams
• Business stakeholders
• Senior leaders
• Other interested parties

Definition of terms

Project

"A temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates a beginning and an end to the project work or a phase of the project work. Projects can stand alone or be part of a program or portfolio."

– PMBOK, PMI

Product

"A tangible solution, tool, or service (physical or digital) that enables the long-term and evolving delivery of value to customers and stakeholders based on business and user requirements."
– Deliver on Your Digital Product Vision,
Info-Tech Research Group

Info-Tech Insight

Any proper definition of product recognizes that they are long-term endeavors that don't end after the project finishes. Because of this, products need well thought out roadmaps.

Match your product management role definitions to your product family levels

Product ownership exists at the different operational tiers or levels in your product hierarchy. This does not imply or require a management relationship.

Product Portfolio
Groups of product families within an overall value stream or capability grouping.
Product Portfolio Manager

Product Family
A collection of related products. Products can be grouped along architectural, functional, operational, or experiential patterns.
Product Family Manager

Product
Single product composed of one or more applications and services.
Product Owner

Info-Tech Insight

The primary role conflict occurs when the product owner is a proxy for stakeholders or responsible for the delivery team. The product owner owns the product backlog. The delivery team owns the sprint backlog and delivery.

Roadmapping Exercise 1.2 (Optional): Define "product" in your context*

15-30 minutes

1. Discuss what "product" means in your organization.
2. Create a common, enterprise definition for "product."

For example,

• An application, platform, or application family.
• Discrete items that deliver value to a user/customer.

* For more on Product Management see Deliver on Your Digital Product Vision

Output

• Your enterprise/ organizational definition of products and services.

Participants

• PMs, Pos, and SMs
• Delivery managers
• Delivery teams
• Business stakeholders
• Senior leaders
• Other interested parties
  

Product Roadmapping

Create effective product roadmaps

Activities

The six "tools" of product roadmapping

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand product management fundamentals
• Understand the six "tools" of roadmapping and how to use them

The six "tools" of product roadmapping

Product Roadmapping

Create effective product roadmaps

Activities

Roadmapping 3.1 Product roadmapping exercise
Roadmapping 3.2 Identify key insights and takeaways
Roadmapping 3.3 Perform an exit survey

This step involves the following participants:

• Product owners, product managers, and scrum masters
• Delivery managers and senior leaders
• Stakeholders and delivery teams

Outcomes of this step

• Understand product management fundamentals
• Understand the six "tools" of roadmapping and how to use them

Roadmapping Exercise 1.2 (Optional): Define "product" in your context*

30 minutes

1. As a team, read through the exercise back story below:

The city of Binbetter is a picturesque place that is sadly in decline because local industry jobs are slowly relocating elsewhere. So, the local government has decided to do something to reinvigorate the city. Binbetter City Council has set aside money and a parcel of land they would like to develop into a venue that will attract visitors and generate revenue for the city.

Your team was hired to develop the site, and you have already spent time with city representatives to create a vision, goals and strategy for building out this venue (captured on the following slides). The city doesn't want to wait until the entire venue is completed before it opens to visitors, and so you have been instructed to build it incrementally in order to bring in much needed revenue as soon as possible.

Using the vision, goals, and strategy you have created, your team will need to plan out the build (i.e. create a roadmap and release plan for which parts of the venue to build and in which order). You can assume that visitors will come to the venue after your "Release 1", even while the rest is still under construction. Select one member of your team to be designated as the product owner. The entire team will work together to consider options and agree on a roadmap/release plan, but the product owner will be the ultimate decision-maker.

* Adapted from Rautiainen et al, Toward Agile Product and Portfolio Management, 2015

Output

• Practical understanding of how to apply the six tools of product roadmapping.

Participants

• PMs, Pos, and SMs
• Delivery managers
• Delivery teams
• Business stakeholders
• Senior leaders
• Other interested parties
  

Roadmapping Exercise 3.1: Continued

2. As a team, review vision, goal, and strategy:
   • Is this a "good" vision statement, and if so, why?
   • Does it live up to its definition of being: "notional and inspirational, while also calling out key guidance and constraints"?
   • Does it help you to rule in/out options for the Product?
   • e.g. Would a parking lot fit the vision?
   • What about a bunch of condominiums?
   • What about a theme park?

Roadmapping Exercise 3.1: Continued

2. As a team, review vision, goal, and strategy:

Roadmapping Exercise 3.1: Continued

3. As a team, review the following exercise rules:

• Your construction team has told you that they can divide the structures into 17 "equal" components (see below)
• Each component will require about the same amount of time and resources to complete
• You can ask the team to build these components in any order and temporary roofs can be built for components that are not at the top of a "stack" (e.g. you can build C3 without having to build C4 and C5 at the same time)
• However, you cannot build the tops of any buildings first (e.g. don't build M3 until M2 and M1 are in place)

Roadmapping Exercise 3.1: Continued

4. As a team, review vision, goal, and strategy:
   • The city has asked you to decide on your "Release 1 MVP" and has limited you to selecting between 4 and 8 components for this MVP (fewer components = earlier opening date).
   • As a team, work together to decide which components will be in your MVP (remember, the PO makes the ultimate decision).
   • Drag your (4-8) selected MVP components over from the right and assemble them below (and explain your reasoning for your MVP selections):

Roadmapping Exercise 3.1: Continued
(magnified venue)

Roadmapping Exercise 3.1: Continued

5. As a team, decide the rest of your roadmap:

• The city has asked you to decide on the remainder of your roadmap
• They have limited you to selecting between 2 and 4 components for each additional release (drag your selected component into each release below):

Roadmapping Exercise 3.1: Continued

Roadmapping Exercise 3.2:
Identify key insights and takeaways

15 minutes

1. As a group, discuss and capture your thoughts on:
   1. What key insights have participants gained from the product roadmapping module?
   2. What if any takeaways do participants feel are needed as a result of the module?
   3. What changes need to be made in the organization to support/enhance Agile adoption?
2. Capture your findings in the table below:

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Roadmapping Exercise 3.3
Perform an exit survey

30 minutes

1. Wrap up this section by addressing any remaining questions participants still have.
2. Create your local exit survey by copying the template using the link below. Then copy and distribute your local survey link.
3. Collect the consolidated survey results in preparation for your next steps.
4. NOTE: Using this survey template requires having access to Microsoft Forms. If you cannot access Microsoft Forms, an Info-Tech analyst can send the survey for you. Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Output

• A better understanding of Agile principles and practices
• Action items that will help solidify Agile practices in the organization

Participants

• Product owners, product managers, and scrum masters
• Delivery managers
• Delivery teams
• Stakeholders
• Senior leaders

Appendix

Additional research to start your journey

Related Info-Tech Research

Mentoring for Agile Teams

• Get practical help and guidance on your Agile transformation journey.

Implement DevOps Practices That Work

• Streamline business value delivery through the strategic adoption of DevOps practices.

Deliver on Your Digital Product Vision

• Build a product vision your organization can take from strategy through execution.

Deliver Digital Products at Scale

• Deliver value at the scale of your organization through defining enterprise product families.

Bibliography

"Agile Estimation Practice." DZone.com, 13 May 2013. Web.
"Announcing DORA 2021 Accelerate State of DevOps Report." Google Cloud Blog. Accessed 8 Nov. 2022.
"Are Your IT Strategy and Business Strategy Aligned?" 5Q Partners, 8 Jan. 2015. Accessed Oct. 2016.
A, Karen. "20 Mental Models for Product Managers." Medium, Product Management Insider, 2 Aug. 2018 . Web.
ADAMS, PAUL. "Product Teams: How to Build & Structure Product Teams for Growth." Inside Intercom, 30 Oct. 2019. Web.
Agile Alliance. "Product Owner." Agile Alliance. n.d. Web.
Ambysoft. "2018 IT Project Success Rates Survey Results." Ambysoft. 2018. Web.
Banfield, Richard, et al. "On-Demand Webinar: Strategies for Scaling Your (Growing) Enterprise Product Team." Pluralsight, 31 Jan. 2018. Web.
Bloch, Michael, Sven Blumberg, and Jurgen Laartz. "Delivering Large-Scale IT Projects on Time, on Budget, and on Value." McKinsey & Company, October 2012.
Blueprint. "10 Ways Requirements Can Sabotage Your Projects Right From the Start." Blueprint. 2012. Web.
Boehm, Barry W. Software Engineering Economics. New Jersey: Prentice Hall, 1981.
Breddels, Dajo, and Paul Kuijten. "Product Owner Value Game." Agile2015 Conference. 2015. Web.
Cagan, Martin. "Behind Every Great Product." Silicon Valley Product Group. 2005. Web.
"Chaos Report 2015." The Standish Group, 2015. Accessed 29 July 2022.
Cohn, Mike. Succeeding With Agile: Software Development Using Scrum. Addison-Wesley. 2010. Web.
Connellan, Thomas K. Inside the Magic Kingdom, Bard Press, 1997. Print.
Dyba, Tore, and Torgeir Dingsøyr. "Empirical Studies of Agile Software Development: A Systematic Review." Elsevier, ScienceDirect. 24 Jan. 2008. Web.
"How do you define a product?" Scrum.org. 4 Apr 2017, Web
EDUCAUSE. "Aligning IT Funding Models to the Pace of Technology Change." EDUCAUSE. 14 Dec. 2015. Web.
Eick, Stephen. "Does Code Decay? Assessing the Evidence from Change Management Data." IEEE Transactions on Software Engineering, vol. 27, no. 1, Jan. 2001, pp. 1-12. Web.
"Enablers." Scaled Agile. n.d. Web.
"Epic." Scaled Agile. n.d. Web.
Eringa, Ron. "Evolution of the Product Owner." RonEringa.com. 12 June 2016. Web.
Fernandes, Thaisa. "Spotify Squad Framework - Part I." Medium.com. 6 Mar. 2017. Web.
Fowler, Martin. "Application Boundary." MartinFowler.com. 11 Sept. 2003. Web. 20 Nov. 2017.
Galen, Robert. "Measuring Technical Product Managership – What Does 'Good' Look Like ...." RGalen Consulting. 5 Aug. 2015. Web.
Hackshall, Robin. "Product Backlog Refinement." Scrum Alliance. 9 Oct. 2014. Web. Feb. 2019.
Halisky, Merland, and Luke Lackrone. "The Product Owner's Universe." Agile Alliance, Agile2016. 2016. Web.
Kamer, Jurriaan. "How to Build Your Own 'Spotify Model'." Medium.com. 9 Feb. 2018. Web.
Karlsson, Johan. "Backlog Grooming: Must-Know Tips for High-Value Products." Perforce. 18 May 2018. Web. Feb. 2019.
Lindstrom, Lowell. "7 Skills You Need to Be a Great Product Owner." Scrum Alliance. n.d. Web.
Lawrence, Richard, and Peter Green. "The Humanizing Work Guide to Splitting User Stories." Humanizing Work, 22 Oct. 2020. Web.
Leffingwell, Dean. "SAFe 5.0." Scaled Agile Inc. 2021. Web. Feb. 2021.
Lucero, Mario. "Product Backlog – Deep Model." Agilelucero. 8 Oct. 2014. Web.
Lukassen, Chris. "The Five Belts Of The Product Owner." Xebia.com. 20 Sept. 2016. Web.
Management 3.0. "Delegation Poker Product Image." Management 3.0. n.d. Web.
McCloskey, Heather. "Scaling Product Management: Secrets to Defeating Common Challenges." Scaling Product Management: Secrets to Defeating Common Challenges, ProductPlan, 12 July 2019 . Web.
McCloskey, Heather. "When and How to Scale Your Product Team." UserVoice Blog, UserVoice, 21 Feb. 2017 . Web.
Medium.com. "Exploring Key Elements of Spotify's Agile Scaling Model." Medium.com. 23 July 2018. Web.
Mironov, Rich. "Scaling Up Product Manager/Owner Teams: - Rich Mironov's Product Bytes." Rich Mironov's Product Bytes, Mironov Consulting, 12 Apr. 2014 . Web.
"Most Agile Transformations Will Fail." Vitality Chicago Inc., 24 Jan. 2019.
Overeem, Barry. "A Product Owner Self-Assessment." Barry Overeem. 6 Mar. 2017. Web.
Overeem, Barry. "Retrospective: Using the Team Radar." Barry Overeem. 27 Feb. 2017. Web.
"PI Planning." Scaled Agile. n.d. Web.
"PI Planning."SAFe. 2020.
Pichler, Roman. "How to Scale the Scrum Product Owner." Roman Pichler, 28 June 2016 . Web.
Pichler, Roman. "Product Management Framework." Pichler Consulting Limited. 2014. Web.
Pichler, Roman. "Sprint Planning Tips for Technical Product Managers." LinkedIn. 4 Sept. 2018. Web.
Pichler, Roman. "What Is Product Management?" Pichler Consulting Limited. 26 Nov. 2014. Web.
Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 7th ed., Project Management Institute, 2021.
Radigan, Dan. "Putting the 'Flow' Back in Workflow With WIP Limits." Atlassian. n.d. Web.
Royce, Dr. Winston W. "Managing the Development of Large Software Systems." Scf.usc.edu. 1970. Web.
Schuurman, Robbin. "10 Tips for Technical Product Managers on Agile Product Management." Scrum.org. 28 Nov. 2017. Web.
Schuurman, Robbin. "10 Tips for Technical Product Managers on (Business) Value." Scrum.org. 30 Nov. 2017. Web.
Schuurman, Robbin. "10 Tips for Technical Product Managers on Product Backlog Management." Scrum.org. 5 Dec. 2017. Web.
Schuurman, Robbin. "10 Tips for Technical Product Managers on the Product Vision." Scrum.org. 29 Nov. 2017. Web.
Schuurman, Robbin. "Tips for Starting Technical Product Managers." Scrum.org. 27 Nov. 2017. Web.
Sharma, Rohit. "Scaling Product Teams the Structured Way." Monetary Musings, Monetary Musings, 28 Nov. 2016 . Web.
STEINER, ANNE. "Start to Scale Your Product Management: Multiple Teams Working on Single Product." Cprime, Cprime, 6 Aug. 2019 . Web.
Shirazi, Reza. "Betsy Stockdale of Seilevel: Product Managers Are Not Afraid To Be Wrong." Austin VOP #50. 2 Oct. 2018. Web.
Standish Group, The. "The Standish Group 2015 Chaos Report." The Standish Group. 2015. Web.
Theus, Andre. "When Should You Scale the Product Management Team?" When Should You Scale the Product Management Team?, ProductPlan, 7 May 2019 . Web.
Todaro, Dave. "Splitting Epics and User Stories." Ascendle. n.d. Web. Feb. 2019.
Tolonen, Arto. "Scaling Product Management in a Single Product Company." Smartly.io - Digital Advertising Made Easy, Effective, and Enjoyable, Smartly.io, 26 Apr. 2018 . Web.
Ulrich, Catherine. "The 6 Types of Product Managers. Which One Do You Need?" Medium.com. 19 Dec. 2017. Web.
Vähäniitty, J. et al. "Chapter 7: Agile Product Management" in Towards Agile Product and Portfolio Management. Aalto University Software Process Research Group, 2010.
VersionOne. "12th Annual State of Agile Report." VersionOne. 9 April 2018. Web.
Verwijs, Christiaan. "Retrospective: Do The Team Radar." Medium.com. 10 Feb. 2017. Web.
"Why Agile Fails Because of Corporate Culture - DZone Agile." Dzone.Com. Accessed 31 Aug. 2021.

Cultural advantages of Agile

Collaboration

Team members leverage all their experience working towards a common goal.

Iterations

Cycles provide opportunities for more product feedback.

Prioritization

The most important needs are addressed in the current iteration.

Continual Improvement

Self-managing teams continually improve their approach for next iteration.

A backlog stores and organizes PBIs at various stages of readiness

A well-formed backlog can be thought of as a DEEP backlog:

• Detailed Appropriately: Product backlog items (PBIs) are broken down and refined as necessary.
• Emergent: The backlog grows and evolves over time as PBIs are added and removed.
• Estimated: The effort a PBI requires is estimated at each tier.
• Prioritized: The PBIs value and priority are determined at each tier.

(Perforce, 2018)

Info-Tech Best Practice

Don't fully elaborate all of your PBIs at the beginning of the project instead, make sure they are elaborated "just in time." (Keep no more than 2 or 3 sprints worth of user stories in the Ready state.)

Scrum versus Kanban: Key differences

Scrum versus Kanban: When to use each

Scrum: Delivering related or grouped changes in fixed time intervals.

• Coordinating the development or release of related items
• Maturing a product or service
• Interdependencies between work items

Kanban: Delivering independent items as soon as each is ready.

• Work items from ticketing or individual requests
• Completing independent changes
• Releasing changes as soon as possible

Develop an adaptive governance process

Five key principles for building an adaptive governance framework

Delegate and Empower

Decision making must be delegated down within the organization, and all resources must be empowered and supported to make effective decisions.

Define Outcomes

Outcomes and goals must be clearly articulated and understood across the organization to ensure decisions are in line and stay within reasonable boundaries.

Make Risk informed decisions

Integrated risk information must be available with sufficient data to support decision making and design approaches at all levels of the organization.

Embed / Automate

Governance standards and activities need to be embedded in processes and practices. Optimal governance reduces its manual footprint while remaining viable. This also allows for more dynamic adaptation.

Establish standards and behavior

Standards and policies need to be defined as the foundation for embedding governance practices organizationally. These guardrails will create boundaries to reinforce delegated decision making.

Maturing governance is a journey

Organizations should look to progress in their governance stages. Ad-Hoc, and controlled governance tends to be slow, expensive, and a poor fit for modern practices.

The goal as you progress in your stages is to delegate governance and empower teams to make optimal decisions in real-time, knowing that they are aligned with the understood best interests of the organization.

Automate governance for optimal velocity, while mitigating risks and driving value.

This puts your organization in the best position to be adaptive and able to react effectively to volatility and uncertainty.

Business value is a key component to driving better decision making

Better Decisions

• Team Engagement
• Frequent Delivery
• Stakeholder Input
• Market Analysis
• Articulating Business Value
• Focus on Business Needs

Facilitation Planning Tool

• Double-click the embedded Excel workbook to select and plan your exercises and timing.
• Place or remove the "X" in the "Add to Agenda" column to add it to the workshop agenda and duration estimate.
• Verify the exercise and step timing estimates from the blueprint provided on the "Detailed Workshop Planner" in columns C-F and adjust based on your facilitation and intended audience.

Appendix:
SDLC transformation steps

Waterfall SDLC: Valuable product delivered at the end of an extended project lifecycle, frequently in years

• Business separated from delivery of technology it needs, only one third of product is actually valuable (Info-Tech, N=40,000).
• In Waterfall, a team of experts in specific disciplines hand off different aspects of the lifecycle.
• Document signoffs are required to ensure integration between silos (Business, Dev, and Ops) and individuals.
• A separate change request process lays over the entire lifecycle to prevent changes from disrupting delivery.
• Tools are deployed to support a specific role (e.g. BA) and seldom integrated (usually requirements <-> test).

Wagile/Agifall/WaterScrumFall SDLC: Valuable product delivered in multiple releases

• Business is more closely integrated by a business product owner accountable for day-to-day delivery of value for users.
• The team collaborates and develops cross-functional skills as they define, design, build, and test code over time.
• Signoffs are reduced but documentation is still focused on satisfying project delivery and operations policy requirements.
• Change is built into the process to allow the team to respond to change dynamically.
• Tools start to be integrated to streamline delivery (usually requirements and Agile work management tools).

Agile SDLC: Valuable product delivered iteratively; frequency depends on Ops' capacity

• Business users are closely integrated through regularly scheduled demos (e.g. every two weeks).
• Team is fully cross-functional and collaboratesto plan, define, design, build, and test the code supported by specialists.
• Documentation is focused on future development and operations needs.
• Change is built into the process to allow the team to respond to change dynamically.
• Explore automation for application development (e.g. automated regression testing).

Agile with DevOps SDLC: High frequency iterative delivery of valuable product (e.g. every two weeks)

• Business users are closely integrated through regularly scheduled demos.
• Dev and ops teams collaborate to plan, define, design, build, test, and deploy code supported by automation.
• Documentation is focused on supporting users, future changes, and operational support.
• Change is built into the process to allow the team to respond to change dynamically.
• Build, test, deploy is fully automated (service desk is still separated).

DevOps SDLC: Continuous integration and delivery

• Business users are closely integrated through regularly scheduled demos.
• Fully integrated DevOps team collaborates to plan, define, design, build, test, deploy, and maintain code.
• Documentation Is focused on future development and use adoption.
• Change is built into the process to allow the team to respond to change dynamically.
• Fully integrated development and operations toolchain.

Fully integrated product SDLC: Agile + DevOps + continuous delivery of valuable product on demand

• Business users are fully integrated with the teams through dedicated business product owner.
• Cross-functional teams collaborate across the business and technical life of the product.
• Documentation supports internal and external needs (business, users, Ops).
• Change is built into the process to allow the team to respond to change dynamically.
• Fully integrated toolchain (including service desk).