What does it take to create a backlog, build software, release features, and finally deliver value to your customers? From estimation to prioritization, to understanding an end-state vision of an organization, this deck helps you understand the value you're delivering to your users. Learn more about the principles of Agile Product Management in this slide deck from LeadingAgile, Senior Vice President and Executive Consultant, Adam Asch.
4. 4
Teams: Scaled
• Defines/ Articulate strategic business goals
• Defines success criteria for what we are
trying to achieve
• Gets funding
Portfolio
Team
• Defines epics, features, & stories to align
with & execute on strategic business goals
• Manages the backlog
• Accepts “Done” work
Product
Owner
Team
• Defines How we will deliver
• Defines technical stories
• Responsible for quality
Delivery
Team
5. 5
Team Focus Epics & Releases
How can we release
value incrementally?
What subset of
business objectives will
each release achieve?
What user
constituencies will the
release serve?
What general
capabilities (big stories)
will the release offer?
Stories & Quality
What user or
stakeholder need will the
story serve?
How will it specifically
look and behave?
How will I determine if
it’s completed?
Product & Project
Goals & Strategy
What business
objectives will the
product fulfill?
Features &
Iterations
What specifically
will we build?
(user stories)
How will this
iteration move us
toward release
objectives?
Iteration Goal
Development &
Delivery Tasks
Team
Portfolio Team
Product Owner Team
Delivery Team
10. Agile Requirements – Increments of
Value
10
• Epics are collections of related features
that solve a business problem. (Example:
“Shopping Cart Checkout”)
• Features are smaller than epics and are a
specific piece of functionality. (Example:
“Checkout using credit card”)
• Stories are the smallest increment of
value, and should be contained within a
sprint. (Example: “Checkout using Visa”)
Epic
Feature
Story
15. Product Backlog: Prioritization &
Ordering
15
• Product backlogs are prioritized by business value, where the
drivers of business value are:
– Increasing revenue
– Reducing cost
– Maintaining compliance
– Improving service
– Learning
• Product owners must work with team to also order the backlog.
Ordering is based on:
– Risk
– Complexity
– Demand
– Dependencies (from/ to other projects or systems)
16. Exercise
16
• You will receive a list of foods
• Working in groups, list the foods in order of
difficulty to prepare for consumption
• Anyone on the team can move the foods
around until consensus is reached
17. Performance
Performance is the measure of ability for the capability to satisfy our expectation of the
delivered results of that capability.
What we are asking is what level does this capability perform or need to perform in
order to achieve the result we expect to be able to achieve our goal?
• Currently Largely unknown
• From the perspective of satisfaction from the end user or target segment
• Does this capability support perform suitably?
• Content – Can the User Find Information, Is the Information Valuable?
• Technology – Is the technology reliable and available?
• Features – Can the User perform the tasks they need to?
• UX/Process – Is the experience optimized for the User?
18. Performance - Applied
• Does the current level of performance (speed, bandwidth,
calculations, response time, user interaction) fulfill the need we are
trying to address?
• Is the performance gap a factor of technology or content?
• Can we address the goal with current capabilities – Is what we
currently have Adequate for what we need to do?
• If we improve the performance of the capability will we see a large
enough return to warrant the effort?
19. Business Value
• Question: If we could improve the performance of this capability 10x would
it improve our ability to achieve our strategy?
– Assumptions
• Current performance is adequate
– Local Goals and Organizational Strategy must be aligned
• Business Value is a definitive quantifiable behavior, action or
outcome that can be measured and mapped against our expected
result; aligns with Business Strategy.
20. Business Value - Applied
Business Value is measured as a rank relative to all of our
Capabilities. That is since we have a limited amount of resources and
capacity, what would be the most important capability to address –
then the next – and so on.
This enables us to better determine where we should focus our
investment dollars and resources, who should be accountable for the
capability, where we should build it and how it should get built.
21. Speed of Change Need
• Speed of Change refers to the measurement of the
Frequency, or how often a Capability Group Needs to change
over time.
• Frequently means that the Capability Group or Capabilities within that
group change many times per year (≥ 6x per year)
• Often (≥ 5x per year)
• Regularly means that the Capability Group or Capabilities within that
group change some times per year (≈ 4x per year)
• Sometimes (≤ 2x per year)
• Stable means that the Capability Group or Capabilities within that group
change infrequently by year (≤ 1x per year)
22. Speed of Change Need - Applied
– Content - What is presented to the user needs to be
updated or changes frequently
– Technology - New technologies that need to be supported
and change frequently (Technology Innovation – New
Patentable Technology, New application for existing
technology)
– Features - The process or functionality that a user
interacts with changes frequently
23. Ability to Execute
• Ability to Execute refers to the measurement of our current
ability to change, update or enhance the capability group
relative to the need we have defined in Speed of Change.
• Frequently means that the Capability Group or Capabilities within that
group change many times per year (≥ 6x per year)
• Often (≥ 5x per year)
• Regularly means that the Capability Group or Capabilities within that
group change some times per year (≈ 4x per year)
• Sometimes (≤ 2x per year)
• Stable means that the Capability Group or Capabilities within that group
change infrequently by year (≤ 1x per year)
24. Ability to Execute - Applied
– Content - What is presented to the user needs to be
updated or changes frequently
– Technology - New technologies that need to be supported
and change frequently (Technology Innovation – New
Patentable Technology, New application for existing
technology)
– Features - The process or functionality that a user
interacts with changes frequently
– People - Do you have a Business Person that has Ownership of
this Capability?
25. Speed of Change / Ability to Execute Assessment
Speed of Change Need
HighLow
AbilitytoExecute
High
Low
Ability to Execute
Frequently (≥ 6x per year) - 5 - GREEN
Often (≥ 5x per year) - 4 - LIGHT GREEN
Regularly (≈ 4x per year) - 3 - YELLOW
Sometimes (≤ 2x per year) - 2 - PINK
Low/Unable (≤ 1x per year) - 1 - RED
Speed of Change Need
Frequently (≥ 6x per year) - 5 - RED
Often (≥ 5x per year) - 4 - PINK
Regularly (≈ 4x per year) - 3 - YELLOW
Sometimes (≤ 2x per year) - 2 – LIGHT GREEN
Low/No Need (≤ 1x per year) - 1 - GREEN
2
1
42 3
3
51
4
5
Ability to Execute
Speed of Change Need
High Priority
26. Business Value / Performance Assessment
Business Value
HighLow
Performance
High
Low
Performance
High Performing - 5 - GREEN
Above Adequate - 4 - LIGHT GREEN
Adequate - 3 - YELLOW
Below Adequate - 2 - PINK
Performing Poorly / Does Not Exist - 1 - RED
Business Value
High Value - 5 - RED
Above Adequate Value - 4 - PINK
Adequate Value - 3 - YELLOW
Below Adequate Value - 2 – LIGHT GREEN
Low Value / Does Not Exist - 1 - GREEN
2
1
42 3
3
51
4
5
Performance
Business Value
High Priority
27. Business Value / Performance Assessment
Business Value HighLow
Performance
Low
High
28. Capability Group Business Value by Region
Business Value
High Value - 5
Above Adequate Value – 4
Adequate Value - 3
Below Adequate Value - 2
Low Value / Does Not Exist - 1
# Capability Group APAC China EIA Americas
1 Shopping 3 2 4 4
2 Checkout 3 2 3 3
3 ABO Ordering Administration 2 1 2 3
4 Order Management 2 1 3 3
5 Single Identity 1 1 1 1
6 Personalization/Targeting 4 5 3 5
7 Account Management/Preferences 1 1 2 1
8 Grow My Business 5 5 5 5
9 Motivation/Inspiration NA NA 4 NA
10 Digital Asset Management 2 3 1 2
11 Training 5 4 5 5
12 Selling/Support Tools 5 5 5 4
13 Registration 3 2 3 2
14 Brand Selling Tools/Programs 4 4 2 4
15 Digital Advertising 2 4 4 3
16 Positive Search Results/SEO 4 4 4 4
17 Digital Customer Services 1 3 3 2
18 Unified Search 3 2 1 1
19 User Insights & Analytics 5 5 5 2
20 Campaign Management 4 3 1 5
21 Loyalty Programs 1 3 2 NA
The roles defined in the Scrum framework are defined for teams at the micro level.
However, when operating at the enterprise level, there are a number of structures and roles that can help support agile at scale.
This slide shows how we can go from the individual roles defined at the team level (Product Owner, Scrum Master, Development Team), to a scaled version of roles that includes:
Delivery Team: Defines and builds
Product Owner Team: There are a number of roles that support the product owner when operating at scale, but the basic concept behind having a product owner team is allowing the responsibilities of the Scrum product owner to be shared and distributed amongst a number of people, especially in the case of large complex organizations. There are a number of ways a product owner team can be structured, and some of the potential supporting roles are Business Analyst, Product Manager, Project Manager, and UX designer.
Portfolio Team: This team defines the strategic goals for the overall business, and determines the portfolio of products and services that would support those goals. This team is also responsible for obtaining funding for the products/ services/ projects that become part of the business’ strategic roadmap.
Delivery Team: At the Delivery Team level, the focus of the team is on User Stories & Quality. The team is focused on the specific user stories they are working on, as well as the conditions around considering those stories completed and “Done”.
Product Owner Team: At the Product Owner Team level, the focus of the team is twofold: Epics & Releases and Features & Iterations.
Epics & Releases: The Product Owner Team needs to be thinking about how epics and releases fit into product releases to customers, and how it helps us achieve incremental value delivery. This involves understanding the different sets of users/ customers and how they will benefit from each of the releases and epics, and ensuring we are getting appropriate feedback before investing in building and planning iterations.
Features & Iterations: The Product Owner Team should also be thinking about the specifics of how the epics break down into user stories, and which user stories are critical in order to achieve the goals of the epics and releases. The Product Owner Team also helps identify and agree on the iteration/ sprint goals with teams.
Portfolio Team: The Portfolio Team’s focus is on ensuring the product and project goals align with the overall business’ objectives. At this level, the team is responsible to ensure that products and projects are prioritized based on how/ whether they help achieve larger organizational/ business and strategic goals.
This graphic depicts a traditional project lifecycle, and the different phases of the project.
This graphic provides a view into how we can visualize agile project management and delivery as it relates to a traditional project lifecycle. You can think of each type of project as having similar discovery and inception phases, and then Delivery is really the phase that turns into more of an iterative cycle of sprints, where product is built and delivered incrementally and iteratively.
Talk about the “Iron Triangle” of constraints
On the left: The traditional project management “iron triangle”
Traditionally, project management fixes scope, and considers cost and time as the only variable constraints
This drives behavior that results in work and tasks getting pushed close to deadlines, and in many cases, deadlines get pushed with no real value getting delivered until the whole project is delivered.
Fixing scope and making cost and time variable also causes managers to sometimes approach project challenges with a “throw more bodies at it” mentality. This doesn’t necessarily resolve issues of complexity, or issues that can’t be resolved by adding more people to the project.
On the right: The value-driven version of the iron triangle
With a value-driven approach, time and cost are considered fixed, and scope is variable.
This approach encourages teams to figure out how to deliver value within a specific amount of time and with fixed cost, and negotiations with customers/ stakeholders are around what value should be prioritized and delivered first, instead of how to extend time and add resources to a project to achieve a fixed, locked scope.
Important to note: Agile will not solve all your problems but will expose them. Part of reducing uncertainty is to see the problems early on and then take action to solve those challenges.
The way Agile works:
1) Visibility: Agile gives the team as well as management a whole new level of visibility. Traditionally the visibility is at the beginning of the project and at the end. In Agile the visibility is throughout the project because we are in a constant state of delivering and collaborating together.
2) Business Value: Because we will deliver software earlier the business will realize value much earlier. In an traditional approach the business usually realizes the value at the end when everything is delivered at once.
3) Risk reduction: Agile helps reduce risk early on. Agile teams tend to work on the items with the highest risk first. Also, if customers get to see the work early on the can give more feedback and that again reduces the risk.
4) Adaptability: Agile will offer customers a new level of adaptability that is not common in the traditional world. In the traditional world the goal is to lock everything down and the beginning and then start working. In Agile the mindset is to keep our options open longer and commit to things at the last responsible moment.
•The product backlog captures value to be delivered to customers
•In order to drive the delivery of value, the product backlog must be ready for consumption by the team:
–Prioritized & ordered
–Acceptance criteria defined
- Highest priority work is broken down and elaborated sufficiently
Epics are the largest increment of value and represent collections of related features
Features are smaller than epics and represent a specific piece of functionality
Stories are the smallest increment of value, and typically should be able to be completed within a sprint.
Note to the class that driving value is dependent on the product owner continuously prioritizing, ordering, defining clear acceptance criteria, and breaking down the items that are at the top of the list so they are small enough to be consumed and developed by the team.
Agile frameworks view working tested product as the primary measure of progress
The practices that generate working tested product include practices at the planning level, through the creation of backlogs that are ready for teams to consume, through the implementation of disciplined engineering practices.
In order to achieve a state where teams are delivering working tested product throughout a project/ product development, there are a number of practices teams must implement.
Some of these processes relate to the way we plan iterations (are we planning in increments of value that can be delivered iteratively?), as well as the way we actually execute on our plans.
The execution of our plans involves a number of engineering practices that ensure we are delivering high quality, working product increments.
The next set of slides will discuss the engineering practices involved in delivering working, tested product.
Agile frameworks view working tested product as the primary measure of progress
The practices that generate working tested product include practices at the planning level, through the creation of backlogs that are ready for teams to consume, through the implementation of disciplined engineering practices.
In order to achieve a state where teams are delivering working tested product throughout a project/ product development, there are a number of practices teams must implement.
Some of these processes relate to the way we plan iterations (are we planning in increments of value that can be delivered iteratively?), as well as the way we actually execute on our plans.
The execution of our plans involves a number of engineering practices that ensure we are delivering high quality, working product increments.
The next set of slides will discuss the engineering practices involved in delivering working, tested product.
Prioritization of the product backlog is a critical component of ensuring teams are working on the highest business value items.
Different organizations may vary in what drives business value and in the weight of each item, but generally the drivers are
Increasing revenue
Reducing cost
Maintaining compliance
Improving service
Learning
Product owners should be continuously evaluating the prioritization of the backlog, and ensuring that the team has everything they need to be able to work on items closer to the top of the backlog.
Once prioritization has been determined for backlog items, we also need to ensure that the order of the items makes sense technically, and that it aligns with expectations from the organization.
Ordering and prioritization must work hand in hand to ensure the team is working on the right backlog items at any given time.
Discussion:
Agility is not a process, methodology or framework.
Rather, it is a mindset. Agility is a different way of looking and and approaching things.
There can be many ways to achieve agility within an organization, and rather than focus on the mechanics of the process, the most important things to focus on are the values and principles that make up the Agile Manifesto.