Agile Product Management: Getting from Backlog to Value
•Download as PPTX, PDF•
9 likes•2,785 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Agile Product Management: Getting from Backlog to Value
Similar to Agile Product Management: Getting from Backlog to Value (20)
More from LeadingAgile
More from LeadingAgile (20)
Recently uploaded
Recently uploaded (20)
Agile Product Management: Getting from Backlog to Value
- 1. Agile Product Management: Getting from Backlog to Value
- 3. Lean+Agile Atlanta Unconference – Nov. 4 http://www.leanagileatlanta.com/
- 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
- 6. Scrum Backlog Planning Iteration Planning Sprint w/ Daily Stand-up Demo Release Retrospective 24 hrs. 2 weeks Product Backlog Sprint Backlog “Fit for Release” Product Increment Feedback Continuous Improvement
- 7. Example Product Lifecycle 7 Discovery * Vision * Goals * Scope •Success Criteria Inception * Business Epics * Technology Epics * High-Level Estimates * Milestones Iteration Zero * Environments * User Stories * Release Planning * Iteration Planning Delivery * Build * Test * Demo * Deploy Closing * Final Delivery * Partner Training * User Documentation * Technical Documentation Benefit & Support * Track Functionality * Measure Benefit * Capture Feedback * Define Need
- 8. Project Lifecycle 8 Discovery * Vision * Goals * Scope •Success Criteria Inception * Business Epics * Technology Epics * High-Level Estimates * Milestones Iteration Zero * Environments * User Stories * Release Planning * Iteration Planning Closing * Final Delivery * Partner Training * User Documentation * Technical Documentation Benefit & Support * Track Functionality * Measure Benefit * Capture Feedback * Define Need Backlog Planning Iteration Planning Sprint w/ Daily Stand-up Demo Release Retrospe ctive
- 9. Plan-Driven vs. Value-Driven 9 Plan-Driven Value-Driven Scope ScopeCost Time Cost Time FIXED VARIABLE
- 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
- 11. Working Tested Product 11 Working Tested Product Progress
- 12. Working Tested Value 12 Working Tested Product In Production Value
- 13. The Horizon of Predictability 13 HOP helps us to determine when we create consumable requirements.
- 14. The Cone of Uncertainty 14
- 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
- 29. WRAP-UP
- 30. Thank You!
Editor's Notes
- 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.