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.

Agile transformations can be difficult and complex to implement. That's because they require fundamental changes in the way an organization thinks and behaves (and many organizations don't fully understand the changes required).

Agile is an extremely broad and deep topic, and it works best when everyone in the organization has a common understanding of its practices and how it impacts their role in the organization.

This blueprint explains Agile fundamentals, principles, and practices in an easy-to-understand way, regardless of whether you are a "leader" or a "doer," working in IT or not.

Alex Ciraco
Principal Research Director, Application Delivery and Management
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 understands Agile fundamentals, principles, and practices, the "different way of working" Agile requires, and the role each person plays in its success.

Info-Tech's methodology

Develop Your Agile Approach for a Successful Transformation

Everyone's Agile journey is not the same.

Conduct Survey

Use our Common Agile Challenges Survey to identify your organization's Agile pain points.

Introducing Agile Basics

Level-set everyone on what Agile is (and isn't).

Examine Pain Points

Understand your specific pains and identify the most urgent ones.

Address Pain Points

Work through your most urgent pain-points using the corresponding modules. Everyone will have different pain points.

• Backlog Management And User Story Decomposition
• Scrum Simulation
• Establishing an Effective Product Owner
• Agile Estimation

More Modules Coming Soon!

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

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.

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:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Develop Your Agile Approach

Step 1.1

Distribute Survey and Collect Results

Activities

1.1 Distribute Common Agile Challenges Survey and collect results

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

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

Exercise 1.1 Distribute common Agile challenges survey and collect results

Download Survey Template:

• Info-Tech Common Agile Challenges Online Survey Template

1. Create your own local copy of the Common Agile Challenges Survey by using the template link below. The Common Agile Challenges Survey will help you to identify which of the many of the common Agile-related challenges your organization may be facing.
2. 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.
3. Copy the link for your local survey and distribute it for participants to complete (we suggest giving them one week to complete it).
4. Collect the consolidated survey results in preparation for the next phase.

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 (contact your Engage Rep to make arrangements).

Identify your organization's top five Agile pain points from the survey results:

• (e.g. Effectively managing a backlog, Agile Estimation, etc.)

Output

Your organization's biggest Agile pain points

Participants

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

Record the results in the Roadmap for Transition to Agile Template

Phase 2

This phase will walk you through the following activities:

• Gaining 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:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Develop Your Agile Approach

Step 2.1

The What and Why of Agile

Activities

2.1.1 Capture your current understanding of Agile

2.1.2 A tale of two teams

2.1.3 Dissect the agilist's oath

2.1.4 Create your prototype definitions of "ready" and "done"

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

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

The What and Why of Agile

Exercise 2.1.1 Tell us your understanding of Agile (What is it, and why do we do it?)

Share your current understanding of Agile (10-15 minutes)

As a group, discuss and capture your thoughts on:

• What is Agile (its characteristics, practices, differences from alternatives, etc.)?
• Why do we do it (its drivers, benefits, advantages, etc.)?

Capture your findings in the table below:

Output

• Your current understanding of Agile and its benefits

Participants

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

Why Agile/DevOps? It's About Time to Value

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?

* Google Cloud/Accelerate State of DevOps 2021

DevOps helps organizations realize and SUSTAIN Value

Businesses with elite DevOps practices…

973x
more frequent code deployments

6570x
faster lead time from commit to deploy

3x
lower change failure rate

6570x
faster time to recover

Yes, you read that correctly. This is not an editorial error.

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 and how you can make this happen in your organization

Team 1:

Team 2:

Image Credit: DVIDS

Discuss differences between these teams:

• How are they different?
• How would you coach/train/manage/lead?
• How does team members' behavior differ?
• How would you measure each team?

What would have to happen at your organization to make working like this possible?

Output

• How your organization can support Agile behavior and mindset

Participants

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

The agilist's oath

Take two minutes to 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.
• Lastly, 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.

(Optional) Exercise 2.1.3 Dissect the agilist's oath

Discussion (5-10 minutes)

Each bullet point in the agilist's oath is chosen to convey one of 8 key messages about Agile practices and the mindset change that's required by everyone involved.

As a group, discuss the "message" for each bullet point in the agilist's oath, and 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.
• Lastly, 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.

  Which aspects of the agilist's oath are "easy" in your org?

  Which aspects of the agilist's oath are "hard" in your org?

Traditional/Waterfall SDLC

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

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, use the functionality and provide necessary feedback.
• Feedback is being continuously injected back into 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).

Scrum roles and responsibilities

Scrum ceremonies

Are any of these challenges for your organization?

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 be 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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 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

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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done (Continued)

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 2:
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

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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done (Continued)

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 3:
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

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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done (Continued)

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 4:
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:

Output

Prototype definitions of ready and done for your organization

Participants

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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done (Continued)

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 5:
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

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

(Optional) Exercise 2.1.4 Create your prototype definitions of ready and done (Continued)

Create prototype definitions of ready and done starting from the samples (30-45 minutes)

Step 6:
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

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

Step 2.2

Becoming Agile Is Hard, but It's Worth It

Activities

2.2.1 Understand the challenges implementing Agile in your organization

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

• Understand why becoming Agile is hard but that it reduces project risk compared to traditional delivery methods

Becoming Agile Is Hard, but It's Worth It

Getting to Agile/DevOps Nirvana is not easy or fast

A "Typical" Progression Up The Mountain

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

It turns out Waterfall is not that great at reducing risk and ensuring value delivery after all

Standish Group; CHAOS REPORT 2015

"I believe in this concept, but the implementation described above is risky and invites failure."
– Winston W. Royce

Exercise 2.2.1 Identify the challenges to implementing agile in your organization

Discuss why being Agile may be difficult in your organization (10-15 minutes)

As a group, discuss:

• Why being Agile may be difficult in your organization
• What are some of the roadblocks and speed bumps you may face
• What incremental steps might the organization take toward becoming Agile

Capture your findings in the table below:

Record the results in the Roadmap for Transition to Agile Template

Output

• Why being Agile is hard in your organization

Participants

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

Compare Waterfall to Agile

Hybrid (Wagile/Agifall/WaterScrumFall) SDLC
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)

Phased Approach to Delivery (Avoids "one-and-done")

Step 2.3

Move Stepwise From Traditional to Agile

Activities

2.3.1 Identify a hypothetical project

2.3.2 Capture your traditional delivery approach

2.3.3 Consider what a two-phase delivery looks like

2.3.4 Consider what a four-phase delivery looks like

2.3.5 Consider what a four-phase delivery with monthly sprints looks like

2.3.6 Decide on your target state and the steps required to get there

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

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

Move Stepwise From Traditional to Agile

Moving Stepwise from Traditional to Agile (Visualized)

Exercise 2.3.1 Identify a Hypothetical Project

Consider an imaginary traditional project delivery you might do (<5 minutes)

As a group, consider some typical, large, mission-critical system deliveries your organization has done in the past (name a few as examples).

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.

Give this imaginary project a name (e.g. Traditional Project, Our Project, etc.).

Record this in the Roadmap for Transition to Agile Template

Now, complete the following series of sub-exercises…

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, etc.)

Output

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

Participants

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

Exercise 2.3.2 Capture your traditional delivery approach

Capture the high-level steps of your traditional delivery approach (10-15 minutes)

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

Output

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

Participants

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

Exercise 2.3.3 Consider what a two-phase delivery looks like

Consider delivering this project in two one-year phases (15-20 minutes)

• 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.
• Now imagine that you are able to convince the stakeholders to work with you to do the following:
  • Identify their most important project requirements.
  • Work with you to describe a valuable subset of the project requirements which reflect about ½ of all features they need (call this Phase 1).
  • Work with you to get this Phase 1 of the project into production in about 1 year.
  • Agree to leave the remaining requirements (i.e. the less important ones) until Phase 2 (second year of project).
• As a group, identify:
  • How hard this would be for your organization to do, on a scale of 1 to 10.
  • Identify what changes are needed to make this happen (consider people, processes, and technology).
  • Capture your results using the table on the following slide.

Output

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

Participants

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

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

Consider delivering this project in two one-year phases (15-20 minutes)

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 org?
(1-easy, 10-next to impossible)

E.g. 2

Output

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

Participants

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

Exercise 2.3.4 Consider what a four-phase delivery looks like

Consider delivering this project in four six-month-long phases (15-20 minutes)

• 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.
• Now imagine that you are able to convince the stakeholders to work with you to do the following:
  • From the "Phase 1" requirements in Exercise 2.3.3, they will identify the most important ones that they need first.
  • 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).
  • They will work with you to get this Phase 1A of the project into production in about six months.
  • Agree to leave all the remaining requirements (i.e. the less important ones) until later phases.
• As a group, identify:
  • How hard this would be for your organization to do, on a scale of 1 to 10.
  • Identify what changes are needed to make this happen (consider people, processes and technology).
  • Capture your results using the table on the following slide.

Output

• Understand how your org would deliver a large project in four phases

Participants

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

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

Consider delivering this project in four six-month-long phases (15-20 minutes)

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

E.g. 5

Output

• Understand how your org would deliver a large project in four phases

Participants

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

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

Consider delivering this project in 24 one-month-long sprints (15-20 minutes)

• Now, imagine that project stakeholders tell you that they are happy with the six-month release approach (i.e. 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.
• 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 working 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.
• 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.
• 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.
• 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.
• You agree with the stakeholders these one-month deliverables will be called "sprints."

Output

• Understand how your org would deliver a large project in 24 sprints with four incremental releases

Participants

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

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

Consider delivering in 24 one-month sprints (15-20 minutes)

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 org?
(1-easy, 10-next to impossible)

E.g. 8

Output

• Understand how your org would deliver a large project in 24 sprints with four incremental releases

Participants

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

Exercise 2.3.6 Decide on your target state and the steps required to get there

Decide on your target state and the steps required to get there (20 minutes)

• 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).
• Then, identify your desired future state (e.g. 24 one-month sprints with six-month releases).

• 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

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

Exercise 2.3.6 Decide on your target state and the steps required to get there (Continued)

Decide on your target state and the steps required to get there (20 minutes)

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):

What are you going to do now?

Record the results in the Roadmap for Transition to Agile Template

Output

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

Participants

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

Step 2.4

Review Your Common Agile Challenges Survey Results

Activities

2.4.1 Review the results of your Common Agile Challenges Survey

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

• Identify your organization's biggest Agile pain points

Review Your Common Agile Challenges Survey Results

Common Agile challenges we see

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

1. Establishing an effective product owner (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.4.1 Review the results of your Common Agile Challenges Survey

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

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

Step 2.5

Phase 2 Wrap-Up and Exit Survey

Activities

2.5.1 Identify key insights and takeaways

2.5.2 Perform exit survey and capture results

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

• Identify your key insights and takeaways from Phase 2

Phase 2 Wrap-Up and Exit Survey

Exercise 2.5.1 Identify key insights and takeaways from presentation

Discuss key insights and any takeaways from presentation (10-15 minutes)

As a group, discuss and capture your thoughts on:

What key insights have participants gained from the Roadmap for Transitioning to Agile presentation?

What if any takeaways do participants feel are needed as a result of the presentation?

What changes need to be made in the organization to support/enhance Agile adoption?

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

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

Exercise 2.5.2 Perform exit survey and capture results

Wrap up the Roadmap for Transitioning to Agile presentation by addressing any key questions participants still have.

Create your own local Exit Survey by copying the Template using the link below. Then copy and distribute your local Survey link.

Collect the consolidated Survey results in preparation for the next Phase.

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 (contact your Engage Rep to make arrangements). Alternatively, this survey can be done with sticky notes and a pen and paper to calculate the outcomes.

Download Survey Template:

Info-Tech Roadmap for Transitioning to Agile Exit Survey Template

Output

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

Participants

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

Phase 3

Examine Pain Points and Work Through Them

This phase will walk you through the following activities:

• Address your biggest Agile pain points by better understanding them and how to work through them

This phase involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Develop Your Agile Approach

Phase 3

Examine Pain Points and Work Through Them

Examine the results of your Common Agile Challenges Survey results from Phase 2 and identify the most sited challenges that were not already address by the Phase 2 Roadmap for Transitioning to Agile presentation.

Agree on the order in which you will work through these most cited challenges.

Deliver the Phase 3 Modules which correspond to the most cited challenges. Currently, this blueprint has modules for the following challenges:

1. Backlog Management and User Story Decomposition
2. Scrum Simulation Exercise
3. Agile Estimation
4. Establishing an Effective Product Owner

New-to-Agile organizations often struggle with numerous pain points around Agile delivery.

The Common Agile Challenges Survey results will help you identify the organization's biggest (most cited) pain points.

Treat these pain points like a backlog and address the biggest ones first.

Module 3.1

Backlog Management and User Story Decomposition

Activities

3.1.1 Identify your backlog and user story decomposition pains

3.1.2 What are user stories and why do we use them?

3.1.3 User story decomposition: password reset

3.1.4 Decompose a real epic

3.1.5 Identify key insights and takeaways from module

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

• A better understanding of backlog management and user story decomposition

Backlog Management and User Story Decomposition

Exercise 3.1.1 Identify your backlog and user story decomposition pains

Share your backlog management and user story decomposition challenges (10-15 minutes)

As a group, discuss and capture your thoughts on:

• What specific challenges you are facing with backlog management
• What specific challenges you are facing with user story decomposition

Capture your findings in the table below:

Output

• Your specific backlog management and user story decomposition challenges

Participants

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

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" & "Shalls" to capture requirements

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

Discussion (5-10 minutes)

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

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

User stories are "placeholders for conversations"

User stories enable collaboration and conversations to more 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

Exercise 3.1.3 User story decomposition: password reset

Decomposition Exercise (5-10 minutes)

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.

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

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

Exercise 3.1.3 User story decomposition: password reset (Continued)

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 (i.e. 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

Exploration

Any efforts toward learning customer or user needs and creation of solutions and alternatives. Exploration enablers are heavily linked to learning milestones.

Architectural

Any efforts toward building components of your architecture. These will often be linked to delivery teams other than your pure development team.

Infrastructure

Any efforts toward building various development and testing environments. Again, these are artifacts that will relate to other delivery teams.

Compliance

Any efforts toward regulatory and compliance requirements in your development activities. These can be both internal and external.

Create, split, and bundle your PBIs as necessary

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.

Source: Humanizing Work, 2020.

(Optional) Exercise 3.1.4 Decompose a real epic

Decomposition exercise for a real epic (10-15 minutes)

As a group, select a real epic or feature from one of your project backlogs which needs to be decomposed:

Epic to be decomposed:

• As a ____ I want _____ so that ______

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):

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

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

Effective Backlog Management & 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: 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 PBI's value and priority are determined at each tier.

Adapted from Essential Scrum

1. Ready
   • Composed of raw, vague, and potentially large ideas that have yet to go through any formal valuation.
2. Qualified
   • Researched and qualified PBIs awaiting refinement.
3. Ideas
   • Discrete, refined PBIs that are ready to be placed in your development team's sprint plans.

Info-Tech Best Practice:

Don't fully elaborate all 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.)

Backlog tiers facilitate product planning steps

Ranging from the intake of an idea to a PBI ready for development; to enter the backlog, each PBI must pass through a given quality filter.

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

A PBI successfully completes an activity and passes through to the next backlog tier when it meets the appropriate criteria. Quality filters should exist between each tier.

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 PBI's 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.

Exercise 3.1.5 Identify key insights and takeaways from this module

Discuss key insights and any takeaways from this module (10-15 minutes)

As a group, discuss and capture your thoughts on:

• What key insights have participants gained on backlog management and US decomposition?
• What if any takeaways do participants feel are needed as a result of the module?
• What changes need to be made in the organization to improve in this area?

Capture your findings in the table below:

Output

• A better understanding of backlog management and user story decomposition good practices
• Action items that will help solidify these practices in the organization

Participants

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

Exercise 3.1.5 Perform exit survey and capture results

Wrap up the backlog management and user story decomposition module by addressing any key questions participants still have.

Create your own local exit survey by copying the template using the link below. Then copy and distribute your local survey link.

Collect the consolidated survey results in preparation for the next Phase.

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 (contact your Engage Rep to make arrangements)

Download Survey Template:

• Info-Tech Backlog Management and US Decomp Exit Survey Template

Output

• A better understanding of backlog management and user story decomposition good practices
• Action items that will help solidify these practices in the organization

Participants

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

Module 3.2

Scrum Simulation Exercise

Activities

3.2.1 Identify your Scrum pains
3.2.2 Review Scrum simulation intro
3.2.3 Create a mock backlog
3.2.4 Review Sprint 0
3.2.5 Determine a budget and timeline
3.2.6 Understand minimum viable product
3.2.7 Plan your first sprint
3.2.8 Do a sprint retrospective
3.2.9 "What if" exercise (understanding what a fluid backlog really means)
3.2.10 A Sprint 1 example
3.2.11 Do more sprints
3.2.12 Identify key insights and takeaways from module

This step involves the following participants:

• PMs, POs and SMs
• Delivery managers and senior leaders
• Business stakeholders and delivery teams
• Other interested parties

Outcomes of this step

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

Exercise 3.2.1 Identify your Scrum pains

Share your organization's specific Scrum challenges (10-15 minutes)

As a group, discuss and capture your thoughts on:

• What specific challenges are you facing with your Scrum practices?

Capture your findings in the table below:

Output

• Your specific Scrum related challenges

Participants

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

Exercise 3.2.2 Review Scrum Simulation Intro

Read the Introduction tab in the Scrum Simulation and answer any questions (15 minutes)

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

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Understand background for Scrum Simulation Exercise

Participants

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

Exercise 3.2.3 Create a mock backlog

Follow the instructions on the Create a Mock Backlog tab (20-30 minutes)

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

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Create a mock initial backlog for the simulated project

Participants

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

Exercise 3.2.3 Create a mock backlog (Continued)

Step 2: Identify Your Epics
Categorize your "Features and Functions" list into a number of epics for the application:

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Create a mock initial backlog for the simulated project

Participants

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

Exercise 3.2.3 Create a mock backlog (Continued)

Step 3: Identify Your MVP
Decide which "Features and Functions" will be in your MVP and which will be delivered in future releases:

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Create a mock initial backlog for the simulated project

Participants

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

Exercise 3.2.3 Create a mock backlog (Continued)

Step 4: (OPTIONAL) Write up Epics and User Stories for the MVP
For each Epic in your MVP, create a User Story to describe it,
For each "Feature and Function" in your MVP, create a User Story to capture it:

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Create a mock initial backlog for the simulated project

Participants

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

Exercise 3.2.4 Review Sprint 0

Review the Sprint 0 tab in the Scrum Simulation and answer any questions (15-20 minutes)

Step 1: Introduce and walk through the Sprint 0 tab in the Scrum Simulation Exercise

Step 2: Discuss and answer any questions the participants may have about the Sprint 0 tab

Step 3: 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: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

• Understand Sprint 0 for Scrum Simulation Exercise

Participants

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

Exercise 3.2.5 Determine a budget and timeline

Determine the expected budget and timeline for the first project release (10 minutes)

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

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

Output

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

Participants

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

Exercise 3.2.6 Understanding minimum viable product (MVP)

Discuss your current understanding of MVP (10 minutes)

How do you describe/define MVP?

(Discuss/capture your understanding of minimum viable product)

Output

• Capture your current understanding of Minimum Viable Product

Participants

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

Understanding MVP

(Note: see Facilitator Slides for more guidance on how to deliver this exercise)

How Agile reduces risk and speeds value delivery compared to traditional

Traditional Risk/Value Curve:	Agile Risk/Value Curve:

Exercise 3.2.7 Plan your first sprint

Decide which user stories will be delivered in your first sprint (~40 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 out on their findings (10 minutes)

Capture findings in the table below:

Output

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

Participants

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

(Optional) Exercise 3.2.8 Do a sprint retrospective

Perform a "sprint retrospective" on the work you did in Exercise 3.2.6 (10 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

Capture findings in the table below:

Output

• Experience performing a sprint retrospective

Participants

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

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

Consider how you would handle various changes to the project backlog (10 minutes)

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

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

Exercise 3.2.10 A Sprint 1 example

Consider and discuss an example Sprint 1 (15-20 minutes)

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

Output

• Better understanding of an MVP strategy

Participants

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

Exercise 3.2.10 (Continued) A Sprint 1 example

Consider and discuss an example Sprint 1 (15-20 minutes)

As a group, discuss this approach, including:

The pros and cons of the approach

Is this a shippable increment?

What more would you need to do to make it a shippable increment?

Capture your findings in the table below:

Output

• Better understanding of an MVP strategy

Participants

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

Exercise 3.2.11 Do more sprints

Continue to simulate more sprint (20-40 minutes)

As a group, continue to simulate more sprints for the online banking app:

Simulate the planning, execution, demo, and retro stages for additional sprints

Stop when you have had enough

Capture your learnings in the table below:

Output

• Better understanding of an MVP strategy

Participants

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

Exercise 3.2.12 Identify key insights and takeaways from module

Discuss key insights and any takeaways from this module (10-15 minutes)

As a group, discuss and capture your thoughts on:

What key insights have participants gained about Scrum?

What if any takeaways do participants feel are needed as a result of the module?

Is this a feasible way to develop systems in your org?

What changes need to be made in the organization to improve in this area?

Capture your findings in the table below:

Output

• A better understanding of how to use Scrum in your organization
• Action items that will help solidify good Scrum practices in the organization

Participants

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

Exercise 3.2.12 Perform exit survey and capture results

Wrap up the Scrum Simulation module by addressing any key questions participants still have.

Create your own local exit survey by copying the template using the link below. Then copy and distribute your local survey link.

Collect the consolidated survey results in preparation for the next Phase.

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 (contact your Engage Rep to make arrangements)

Download Survey Template:

Info-Tech Scrum Simulation Exit Survey Template

Output

• A better understanding of how to use Scrum in your organization
• Action items that will help solidify good Scrum practices in the organization

Participants

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

Module 3.3

Agile Estimation

Activities

3.3.1 Identify your estimation pains

3.3.2 Why do we estimate?

3.3.3 How do you estimate now?

3.3.4 Estimate a real PBI

3.3.5 Understanding the wisdom of crowds

3.3.6 Identify key insights and takeaways from module

This step involves the following participants:

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

Outcomes of this step

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

Exercise 3.3.1 Identify your estimation pains

Share your organization's specific estimation challenges (10-15 minutes)

As a group, discuss and capture your thoughts on:

What specific challenges are you facing with your estimation practices today

Capture your findings in the table below:

Output

• Your specific estimation related challenges

Participants

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

(Optional) Exercise 3.3.2 Why do we estimate?

Share your thoughts/beliefs about why we do estimates (10-15 minutes)

As a group, discuss and capture your thoughts on:

Why do we do estimates?
What value/merit do estimates have?

Capture your findings in the table below:

Output

• Better understanding of the need for estimates

Participants

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

(Optional) Exercise 3.3.2 Why do we estimate? (Con't)

Here are some sample reasons for estimates:

• Estimation has its merits
• "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

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

Exercise 3.3.3 How do you estimate now?

Describe your organization's current approach to estimation (10-15 minutes)

As a group, speak about now you currently estimate in your organization.

Capture your findings in the table below:

Output

• Your current estimation approach

Participants

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

Agile Estimation Fundamentals

Know the truth about estimates and their potential pitfalls.

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

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

What is Agile estimation?

NOTE: 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.

Characteristics of Agile estimation techniques:

• Understands and accepts the limitations of any estimation process.
• Leverages good practices to counteract these limitations (e.g. wisdom of crowds, quality-first thinking, etc.).
• 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 improves 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
(i.e. 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 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.

(Optional) Exercise 3.3.4 Estimate a real PBI

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 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 "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

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

Exercise 3.3.5 Understanding the wisdom of crowds

Experience the wisdom of crowds through an exercise (20 minutes)

Use the on-slide instructions for the following steps:

1. Guess the number of jelly beans (Round 1)
2. Compare your guess against the average
3. Guess the number of gumballs (Round 2)
4. Compare how you did across rounds

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Guess the number of jelly beans (Round 1)

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Guess the number of jelly beans
(Round 1)

Survey instructions:

Create your own local survey by copying the template using the link below. Then copy and distribute your local Survey link to 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 do not have access to Microsoft Forms, an Info-Tech Analyst can perform the survey for you (contact your Engage Rep to make arrangements). Alternatively, this survey can be done with sticky notes, a pen, paper, and a calculator to determine the outcomes.

Download Survey Template:

Info-Tech Wisdom of the Crowd 1 (Jelly Bean Guess)

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Compare the average of your guesses against the Actual

Record each participant's guess in the table Calculate the average guess value and record it as the Average of Guesses Calculate and record the error % of the average guess from the Actual Similarly, calculate and record the error % of each participant's guess from the Actual Discuss how well the average guess performed compared to individual guesses As a group, talk about the different ways each participant determined their guess (particularly those that were close to the Actual)

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Guess the number of gumballs(Round 2)

INSTRUCTIONS:

• Each participant is asked to guess the total number of gumballs visible in the photo shown at right
• Again, please don't share your guess with anyone
• Submit your guess using the survey link on next slide

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Guess the number of gumballs (Round 2)

Survey instructions:

Create your own local survey by copying the template using the link below. Then copy and distribute your local survey link to 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 do not have access to Microsoft Forms, an Info-Tech Analyst can perform the survey for you (contact your Engage Rep to make arrangements). Alternatively, this survey can be done with sticky notes, a pen, paper and calculator to determine the outcomes.

Download Survey Template:

Info-Tech Wisdom of the Crowd 2 (Gumball Guess)

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Compare the average of your guesses against the Actual

Record each participant's guess in the table Calculate the average guess value and record it as the Average of Guesses Calculate and record the error % of the average guess from the Actual Similarly, calculate and record the error % of each participant's guess from the Actual Discuss how well the average guess performed compared to individual guesses

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.5 Compare how you did across rounds

As a group, discuss how your average guesses performed from Round 1 to Round 2 (did your estimates get better?)

Output

• An appreciation for the power of the wisdom of crowds

Participants

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

Exercise 3.3.6 Identify key insights and takeaways from module

Discuss key insights and any takeaways from this module (10-15 minutes)

As a group, discuss and capture your thoughts on:

What key insights have participants gained about Agile estimation?

What if any takeaways do participants feel are needed as a result of the module?

Is this a feasible way to work in your org?

What changes need to be made in the organization to improve in this area?

Capture your findings in the table below:

Output

• A better understanding of how to use Agile estimation techniques in your organization
• Action items that will help solidify good estimation practices in the organization

Participants

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

Exercise 3.3.6 Perform exit survey and capture results

Wrap up the Agile estimation presentation by addressing any key questions participants still have.

Create your own local exit survey by copying the template using the link below. Then copy and distribute your local survey link.

Collect the consolidated survey results in preparation for the next Phase.

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 (contact your Engage Rep to make arrangements)

Download Survey Template:

Info-Tech Agile Estimation Module Exit Survey Template

Output

• A better understanding of how to use Agile estimation techniques in your organization
• Action items that will help solidify good estimation practices in the organization

Participants

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

Module 3.4

Establishing an Effective Product Owner

Activities

3.4.1 Identify your product owner pains

3.4.2 Dissect this definition of the product owner role

3.4.3 Define your products and consumers

3.4.4 Identify key insights and takeaways from module

This step involves the following participants:

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

Outcomes of this step

• A better understanding of effective product ownership, and how to apply it in your organization

Exercise 3.4.1 Identify your product owner pains

Share your organization's specific product owner challenges (10-15 minutes)

As a group, discuss and capture your thoughts on:

What specific challenges are you facing with your product owner practices today?

Capture your findings in the table below:

Output

• Your specific product owner challenges

Participants

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

It's critical to establish an effective product owner

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

The importance of establishing an effective product owner

• The critical importance of establishing an effective Product Owner (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 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. Stakeholder needs/constraints represent what is most important to those who will be using the system and typically revolve around delivery of value, ease of use, better outcomes, making their jobs easier and more efficient, getting what they ask for, etc.
3. 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.

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

Info-Tech Insight

An effective PO will expertly balance the needs of:

• The organization
• Project stakeholders
• The delivery team

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 (i.e. establish their norms).

The use of a proxy PO (Continued)

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

• Work closely at start of 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 PO's and proxy's 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, etc.) it can be difficult to find a single PO who has sufficient subject matter expertise across all modules.
• When assigning Multiple PO's to a project, be sure to identify a "Lead PO" (who is given ultimate responsibility for the entire project) and have the remaining PO's act like Proxy PO's.
• 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 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.

Establishing an effective product owner

• 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 (i.e. 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 process 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 for 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 who 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

(Optional) Exercise 2.4.2 Dissect this definition of the product owner role

Discussion (10-15 minutes)

Take a minute or two to review the bullet points below, which describe the product owner role.

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 (typically also a stakeholder) who has been empowered by both the organization and stakeholders to act on their behalf and to guide the project direction with a single voice (supported by appropriate consultations with the organization and stakeholders).
• The product owner must be someone with 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 which 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)

The importance of good backlog management
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: 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 PBI's value and priority are determined at each tier.

Backlog tiers facilitate product planning steps

Ranging from the intake of an idea to a PBI ready for development; to enter the backlog, each PBI must pass through a given quality filter.

Each activity is a variation of measuring value and estimating effort in order to validate and prioritize a PBI.
A PBI successfully completes an activity and passes through to the next backlog tier when it meets the appropriate criteria. Quality filters should exist between each tier.

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 PBI's 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.

A little on product
Agile can help to facilitate the move from project orientation to product orientation

Most software systems have a lifespan which far exceeds the duration of the project that created it.

Move toward a product orientation to speed delivery of value, and ensure your critical systems evolve over time to meet your organization's ever-changing needs.

What is a product?

"A product is a solution, tool, or service managed by IBSDB that continuously delivers evolving value over the product's lifecycle to its stakeholders (internal and external) based on their needs. This means continually evolving priorities over the life of a product rather than focusing only on a defined start and end."
-- IBSDB Product Management Working Group (July 2021)

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." They can comprise any software or services that drive value.
3. There is often more than one stakeholder group that derives value from a product or service.

Products and services share the same foundation and best practices

For the purpose of this blueprint, product/service and product owner/service owner are used interchangeably. 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 specific situation and customers (both internal and external).

The most important aspect is consistent use and common understanding of:

1. External products
2. Internal products
3. External services
4. Internal services
5. Products as a service (PaaS)
6. Productizing services (SaaS)

Recognize the different product owner perspectives

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?).

"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"

Exercise 3.4.3 Define your products and consumers

Define products and consumers for your organization (20-30 minutes)

As a group, discuss and capture your thoughts on:

How do you define a product, service, or application?
Who are the consumers that receive value from the product?

Capture your findings in the table below:

Output

• Your definition of product/service and consumers/customers

Participants

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

Scale products to improve alignment

Operationally align product delivery to enterprise goals

The Info-Tech difference:

1. Start by piloting product families to determine which approaches work best for your organization.
2. Create a common definition of what a product is and identify products in your inventory.
3. Use scaling patterns to build operationally aligned product families.
4. Develop a roadmap strategy to align families and products to enterprise goals and priorities.
5. Use products and families to evaluate 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 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.

Leverage the product family roadmap for alignment

A roadmap is more than a set of colorful boxes. It's a map to aligning everyone on 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.

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.

Exercise 3.4.4 Identify key insights and takeaways from module

Discuss key insights and any takeaways from this module (10-15 minutes)

As a group, discuss and capture your thoughts on:

• What key insights have participants gained about the PO role?
• What takeaways do participants feel are needed as a result of the module?
• What changes need to be made in the organization to product ownership?

Capture your findings in the table below:

Output

• A better understanding of the critical nature of the product owner role
• How to establish an effective product owner in your organization

Participants

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

Exercise 3.4.4 Perform exit survey and capture results

Wrap-up the product owner module by addressing any key questions participants still have.

Create your own local exit survey by copying the template using the link below. Then copy and distribute your local survey link.

Collect the consolidated survey results in preparation for the next Phase.

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 (contact your Engage Rep to make arrangements)

Download Survey Template:

Info-Tech's Establishing an Effective PO Module Exit Survey Template

Output

• A better understanding of the critical nature of the Product Owner role
• How to establish an effective product owner

Participants

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

Facilitator Slides

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

Facilitator Slides: Explaining MVP

Facilitator Slides: Explaining MVP (Continued)

Facilitator Slides: Scrum Simulation Introduction

Facilitator Slides: Scrum Simulation Create a Mock Backlog

Facilitator Slides: Scrum Simulation Budget and Timeline

Facilitator Slides: Scrum Simulation Sprint 0

Related Info-Tech Research

Modernize Your SDLC

Strategically adopt today's SDLC good practices to streamline value delivery.

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.

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.
Bloch, Michael, Sven Blumberg, and Jurgen Laartz. "Delivering Large-Scale IT Projects on Time, on Budget, and on Value." McKinsey & Company, October 2012.
Boehm, Barry W. Software Engineering Economics. New Jersey: Prentice Hall, 1981.
"Chaos Report 2015." The Standish Group, 2015. Accessed 29 July 2022.
"Enablers." Scaled Agile. n.d. Web.
"Epic." Scaled Agile. n.d. Web.
Hackshall, Robin. "Product Backlog Refinement." Scrum Alliance. 9 Oct. 2014. Web. Feb. 2019.
Karlsson, Johan. "Backlog Grooming: Must-Know Tips for High-Value Products." Perforce. 18 May 2018. Web. Feb. 2019.
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.
"Most Agile Transformations Will Fail." Vitality Chicago Inc., 24 Jan. 2019.
"PI Planning." Scaled Agile. n.d. Web.
"PI Planning."SAFe. 2020.
Royce, Winston. "Managing the Development of Large Software Systems." Proceedings, IEEE WESCON, August 1970.
Todaro, Dave. "Splitting Epics and User Stories." Ascendle. n.d. Web. Feb. 2019.
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.
"Why Agile Fails Because of Corporate Culture - DZone Agile." Dzone.Com. Accessed 31 Aug. 2021.

Develop an adaptive governance process

5 key principles for building an adaptive governance framework

Manage and communicate key milestones

For successful product delivery, understand and define key milestones in your product delivery lifecycle. These need to be managed along with the product backlog and roadmap.

Business value is a key component to driving better decision making