Agile Product Owner

1,329 views

Published on

Concepts from Jeff Patton, Marty Cagan, Software by Numbers, David Anderson, Feature Driven Development being taught while at Yahoo.

Published in: Software, Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,329
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
55
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile Product Owner

  1. 1. Agile Product Owner
  2. 2. The Goal What is the goal of software development? Hint: It is not to produce working code It is to make a profit
  3. 3. Product Owner Role How would you describe it? Define a successful product. Sets the product direction at all levels Represents the customer and business domain on the team Represents the product to the customer CEO of the product Manages the Product Backlog
  4. 4. Product Owner Role Responsible for market, business case, and competitive analysis Captures most of the User Stories and their Acceptance Criteria Prioritizes in a stack rank the User Stories for releases based upon expected ROI Accepts (or rejects) User Stories on behalf of the Customer
  5. 5. Product Owner Role Responsible for ROI, Cost and Net Profit Higher operating expense in longer release cycles Scope impacts business value in Expected ROI Chooses the mix of features for releases The most value in the smallest scope within the shortest time
  6. 6. Product Owner Challenges 1.Resisting the temptation to “manage” the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. 2.Resisting the temptation to add more work 3.Being willing to make hard choices during a planning meeting. 4.Balancing the interests of competing stakeholders.
  7. 7. Pig or a chicken? Originally the Product Owner role was considered a chicken role. That‟s to say it was a role that required no commitment to the Sprint goals. This has changed over the past as the product owner role has been identified as a key to success or failure of a project.
  8. 8. Product over Project
  9. 9. Always 7% Often 13% Sometimes 16% Rarely 19% Never 45% Standish Group study reported at XP2002 by Jim Johnson, Chairman Often or Always Used: 20% Rarely or Never Used: 64%
  10. 10. Plan Design Build Test Release Bug Fix
  11. 11. exemplify validate release innovate Inspect & Adapt
  12. 12. v2.0 v2.1 v2.2 v2.3 v2.4
  13. 13. Plan Design Build Test Release Bug Fix start finish project timeline Point where finding defects least desired.
  14. 14. v2.0 v2.1 V3.0 Change v2.15 Change Change Change v2.2
  15. 15. Value over Date over Scope
  16. 16. Value Rolls Up Suite - Interrelated products and platforms Product - Satisfies a market need Release - Deployed feature set proving value Feature - Minimal and marketable set of Stories User Story - Smallest block of customer value
  17. 17. Steering the Planning Driving as a Metaphor Where are we heading? Continuously adjust steering based on feedback from the road. Make turns down roads to reach the destination, get by obstacles, or when changing course.
  18. 18. Rolling Wave Planning Product Larger ideas are further away and detailed out as the date nears. 6-12 months ahead Release 3-6 months ahead Feature 2-4 weeks ahead
  19. 19. Vision Planning Wave  Scope - For Multiple years  Are the Vision and Mission statements fresh?  Are the objectives in line with these statements?  Updated - Every year  Results of plan  Vision and mission shared internal and external  Status on objectives updated and communicated
  20. 20. Product Planning Wave  Scope - Annually What objectives will be addressed? What is the compelling statement of need?  Updated - Each Quarter  Results of plan  Establish time-to-market commitments  Product roadmap  One-pager for each product
  21. 21. Product One Pager Elevator Statement For…who…that…Unlike… Customer Attributes 1. People who work in … 2. Those who need a … 3. … Feature / Ability to… 1. Share content with… 2. Personalized ads on… 3. … Metrics: Sign-ups xxx Customer Benefits 1. More accurate … 2. Better customer service … 3. … Performance Attributes 1. 3000 hits/hour 2. … Tradeoff Matrix Scope Resources Schedule Quality Fixed Firm Flexible √ √ √ √ Major Milestones Xyz features xxx Abc features xxx Metrics and ROI
  22. 22. Release Planning Wave  Scope - Quarterly  What needs to be released next?  What is the size of the release?  Updated - Monthly  Re-evaluate plan, make adjustments, notify stakeholders  Derive duration based on size of Stories in release  Results of Plan  People organize in to feature teams  Minimal features to market established  Update schedule of release window Collecting features into releases for scheduling is your primary planning tool
  23. 23. Feature Planning Wave • Scope - Monthly • What User Stories comprise this feature? • How do we know when the feature is done?  Updated - Weekly  Revisit the backlog and keep highest-valued User Stories at the top.  Results of plan  Break down a feature into stories  Write initial acceptance criteria for stories  Team estimates size of stories to derive duration  Inestimable stories are identified as a „spike‟  Logically group features in to a theme if needed  Prioritize stories in the team‟s Product Backlog
  24. 24. Story Planning Wave • Scope - Every Sprint • What tasks are needed to deliver this story? • How do we know when the story is done?  Updated - Every day  Ensure tacit knowledge of high-rank user stories is strong  Stories updated to reflect tasks needed  Results of plan  Break down a story into tasks  All tasks needed for delivery identified  Story can be delivered as working software
  25. 25. Work Planning Wave Scope - Daily •What did I finish yesterday? •What am I doing today? •What is in my way of finishing? Updated - As tasks finish •Update work board to reflect what is being worked on •Ensure tasks prove out acceptance criteria •Results of plan •Identify bottlenecks to work-in-progress •Swarm on tasks to complete User Stories
  26. 26. Multi-year Vision The Waves Combined Yearly Product Quarterly Release Monthly Feature Sprint Story Daily Work
  27. 27. Multi-Level Planning Product Vision Roadmap Release Plan Sprint Plan Daily Plan Q1 Q2 Q3 R1 R2 R3
  28. 28. Relative Sizing 1 2 3 5 8 13 20 40 100
  29. 29. The rate of change in displacement with respect to time. It has both magnitude and direction. Velocity Formula
  30. 30. How difficult is the journey? 8 minutes 12 minutes 1 mile
  31. 31. Velocity 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 9 10 Actual Best W orst Last Average 0 5 10 15 20 25 30 35 40 1 2 3 4 5 6 7 8 9 10 Actual Best W orst Last Average
  32. 32. Cone of Uncertainty
  33. 33. A story point takeoff chart 12 27 58 76 99 117 132 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Points
  34. 34. What can I have? Desired release date 1 July Today s Date 12 February Number of sprints 10 (2 week length) Worst 12 Average 22 Last 26 Best 34
  35. 35. Last (26) When can I have it? Total Points 150 Today s Date 12 February 23 AprilBest (34) 7 May Average (22) 21 May Worst (12) 30 June 150/12=12.5 150/22=6.8 150/26=5.7 150/34=4.4 2/12 4/23 5/21 6/30
  36. 36. Releases cover multiple iterations 4 4 3 4 2 1 3 V = 21 3 2 1 54 3 3 V = 21
  37. 37. Story A 4 Story B 4 Story C 3 Story D 3 Story E 2 Story F 4 Story G 3 Story H 2 Story I 3 Story J 3 Story K 4 Story L 1 Iteration 1 Iteration 2
  38. 38. ready to deliver
  39. 39. Planning Analysis Design Coding Testing Performance User Acceptance Staging Live
  40. 40. May require a Release Sprint AKA “hardening” Fit and finish Shrink Wrap Intensive customer involvement Suggested for immature Sprint teams
  41. 41. Release Planning R1 R2 R3
  42. 42. Incremental Releases Users and Stakeholders Will Love How to deliver functionally complete, valuable, incremental releases Jeff Patton ThoughtWorks jpatton@thoughtworks.com Copyright is held by the author/owner(s). OOPSLA'06, October 22–26, 2006, Portland, Oregon, USA. 2006 ACM 06/0010.
  43. 43. Software By Numbers & Project Portfolios Software by Numbers [Denne & Cleland-Huang] describes Incremental Funding Methodology [IFM] Goal to reduce necessary cash outlay Make projects self-funding Increase return on investment SBN Tools: http://dactyl.cti.depaul.edu/ifm/default.htm SBN introduces the concept of Minimal Marketable Feature – MMF - the smallest sized feature that would have marketable value SBN simple financial models provide guidance on evaluating multiple projects in a portfolio
  44. 44. A Lot Can And Does Go Wrong During Design And Development process risks delays & cut scope scope additions scope subtractions design not built as described risks from outside the process political financial loss of key talent
  45. 45. A Lot Can And Does Go Wrong At Release Time design off target – doesn‟t meet user or business goals product made unusable by poor performing technical architecture ROI estimates were big fat lies
  46. 46. Using Our Task Model to Identify Features that Span Our Business Process The Task Model we‟ve built identifies the major activities and tasks that span the business functionality A successful software release must support all necessary activities in the business process This type of task model is referred to as a Span Plan since it helps identify the spans of functionality Task 1 Task 2 Task 3 Task 4 Task 5 Task 6 Task 7 time necessity Activity 1 smallest list of tasks to support users = smallest span
  47. 47. Identify Releases In a Span Plan By Slicing Horizontally Choose coherent groups of features that consider the span of business functionality and user activities. Support all necessary activities with the first release Improve activity support with subsequent releases time optionality necessary less optional more optional activity 1 activity 2 activity 3 activity 4 first release second release third release
  48. 48. This Product Thickening Strategy Slowly Brings The Product Into Focus Just as an artist envisions an entire painting by starting with a sketch or an under-painting and slowly building up detail, apply the same strategy to “thicken” the product from simple necessities through to full featured product.
  49. 49. Project Success is Not Product Success Placing focus on finishing all scope on time and in budget may equate to project success Finishing all intended scope on time, and under budget does not guarantee product use or quality of use Focus on effective support of user tasks Focus on achieving stakeholder and user goals Focus on getting product into use to begin earning revenue for its business stakeholders
  50. 50. Agile development may be characterized by short cycles of planning and design, building, and testing and evaluation. --Jeff Patton
  51. 51. Minimal Marketable Feature A A feature is minimal because if it was any smaller, it would not be marketable. It is marketable because when released to production, customers will use it.
  52. 52. ReturnonRevenue Months to complete 1 1 1 2 1 3 Release 2 Release 1 Release 3 1 4 1 5 1 6
  53. 53. Different Types of Features Table Stakes Parity to the competition Minimum needed to be in the game Delighter Differentiates you from the competition Excites the customer Spoiler Competitor‟s advantage Raises the bar for parity Pain Reliever Reduces Cost Improves the margin
  54. 54. Features are Supported By Architectural Elements
  55. 55. From Themes to Features 5 13 3 13 8 5 8 8 5 2 13 8 5 8 13 2 20 5 13 8 5 13 20 8 5 13 3 13 8 5 8 852 13 8 5 8 13 2 20 5 13 8 513 20 8
  56. 56. Prioritizing Features High High Low Low Risk Value 1 23 X
  57. 57. Force-rank Features on a Product Backlog Deploy highest value Maximize throughput Maximize ROI De-scope lowest value When date is fixed Adjust to competition Adjust to emerging features Focus the effort to get Stories done/shippable KISS Swarm
  58. 58. 4 Release Strategies for the Same Product Features Return On Investment (2,000) (1,000) - 1,000 2,000 3,000 4,000 5,000 6,000 1 4 7 10 13 16 19 22 Month Thousandsof$s Single Release 12 months total cost: $1.3 M total 2 year return: $3.6 M net 2 year return: $2.3 M Cash Investment: $1.3 M Internal Rate of Return: 9.1% Return On Investment (2,000) (1,000) - 1,000 2,000 3,000 4,000 5,000 6,000 1 4 7 10 13 16 19 22 Month Thousandsof$s Semi Annual Release 6 months increment total cost: $1.4 M total 2 year return: $4.8 M net 2 year return: $3.4 M Cash Investment: $.7 M Internal Rate of Return: 15.7% Return On Investment (2,000) (1,000) - 1,000 2,000 3,000 4,000 5,000 6,000 1 4 7 10 13 16 19 22 Month Thousandsof$s Quarterly Release 3 months increment total cost: $1.6 M total 2 year return: $5.3 M net 2 year return: $3.7 M Cash Investment: $.44 M Internal Rate of Return: 19.1% Return On Investment (2,000) (1,000) - 1,000 2,000 3,000 4,000 5,000 6,000 1 4 7 10 13 16 19 22 Month Thousandsof$s Quarterly Release – drop the last release 3 months increment total cost: $1.2 M total 2 year return: $4.9 M net 2 year return: $3.7 M Cash Investment: $.44 M Internal Rate of Return: 20.4% Return On Investment (2,000) (1,000) - 1,000 2,000 3,000 4,000 5,000 6,000 1 4 7 10 13 16 19 22 Month Thousandsof$s Quarterly Release – continue with 5th release 3 months increment total cost: $2 M total 2 year return: $6.2 M net 2 year return: $4.24 M Cash Investment: $.44 M Internal Rate of Return: 19.0% Source: Jeff Patton Incremental Releases Users and Stakeholders Will Love All features delivered and in use earn $300K monthly About half the features account for $200K of this monthly return Features begin earning money 1 month after release Each month of development costs $100K Each release costs $100K
  59. 59. Technical Considerations Continuous Integration Build on demand Execute all tests Build integrity in Progressive design Implemented with end-to-end functionality Exemplified through test coverage and refactoring
  60. 60. Scaling the Product Owner Product Owners Product Line Owners Chief Product Owner
  61. 61. Who has the „D‟?

×