Agile Product Owner in Wonderland!


Published on

I recently delivered a talk to product owners at Cisco. While I would normally cover this stuff over a period of two days, this was a 90 minute talk about some of the aspects of product ownership. None of this is my own creation - for I have learnt all this from the practitioner community, I am more than happy to share it with the community.

Note: If any attribution is missing, I will be happy to correct my mistake :)

Published in: Software

Agile Product Owner in Wonderland!

  1. { Agile  Product  Owner   in  Wonderland! Tathagat  Varma VP,  Strategic  Process  Innovations [24]7  Innovation  Labs
  2. v Agile  Philosophy v Scrum  Methodology v Product  Owner  Role v Agile  in  Hardware  /  Systems Topics…
  3. Identify  yourself…J
  4. hNp://  
  5. How  Apple  does  it? Steve  Jobs  gave  a  small  private  presentation  about  the   iTunes  Music  Store  to  some  independent  record  label   people.  My  favorite  line  of  the  day  was  when  people   kept  raising  their  hand  saying,  "ʺDoes  it  do  [x]?"ʺ,  "ʺDo   you  plan  to  add  [y]?"ʺ.  Finally  Jobs  said,  "ʺWait  wait  —   put  your  hands  down.  Listen:  I  know  you  have  a   thousand  ideas  for  all  the  cool  features  iTunes  could   have.  So  do  we.  But  we  don'ʹt  want  a  thousand   features.  That  would  be  ugly.  Innovation  is  not  about   saying  yes  to  everything.  It'ʹs  about  saying  NO  to  all   but  the  most  crucial  features.” hNp://  
  6. hNp://­‐‑delivery-­‐‑of-­‐‑waste/  
  7. hNp://­‐‑delivery-­‐‑of-­‐‑waste/    
  8. hNp://­‐‑content/uploads/2012/08/Stacey.png   That’s  the   problem  we   need  to  solve! And  these  are   the  methods   we  are  using!!!
  9. 12  Agile  Principles Our  highest  priority  is  to   satisfy  the  customer   through  early  and  continuous   delivery   of  valuable  software. Welcome  changing   requirements,  even  late  in     development.  Agile  processes   harness  change  for     the  customer'ʹs  competitive   advantage. Deliver  working  software   frequently,  from  a     couple  of  weeks  to  a  couple   of  months,  with  a     preference  to  the  shorter   timescale. Business  people  and   developers  must  work     together  daily  throughout  the   project. Build  projects  around   motivated  individuals.     Give  them  the  environment   and  support  they  need,     and  trust  them  to  get  the  job   done. The  most  efficient  and   effective  method  of     conveying  information  to  and   within  a  development     team  is  face-­‐‑to-­‐‑face   conversation. Working  software  is  the   primary  measure  of  progress. Agile  processes  promote   sustainable  development.     The  sponsors,  developers,   and  users  should  be  able     to  maintain  a  constant  pace   indefinitely. Continuous  aNention  to   technical  excellence     and  good  design  enhances   agility. Simplicity-­‐‑-­‐‑the  art  of   maximizing  the  amount     of  work  not  done-­‐‑-­‐‑is   essential. The  best  architectures,   requirements,  and  designs     emerge  from  self-­‐‑organizing   teams. At  regular  intervals,  the  team   reflects  on  how     to  become  more  effective,   then  tunes  and  adjusts     its  behavior  accordingly.
  10. Feedback  Loops  in  Traditional  Techniques   vs.  Agile  Techniques
  11. Waterfall  vs.  Agile:  Risk  vs.  Value  Delivered hNp://­‐‑content/uploads/2011/12/waterfall_versus_agile_development.png  
  12. Agile  ROI hNp://­‐‑performance-­‐‑testing-­‐‑process-­‐‑-­‐‑-­‐‑whitepaper  
  13. 5  Levels  of  Agile  Planning
  14. Product  Runways Strategic  Vision Set  by  the  CEO  /  Board  and   consists  of  Strategic   Direction,  Solution  Strategy,   Technology  Initiatives  and   Themes Reviewed  annually  as  part  of   annual  strategic  planning   and  revised  as  needed Serves  as  a  strategic  input  for   product  vision Product  Vision High-­‐‑level  overview  of   product  requirements  owned   by  respective  POs   Acts  as  true  north  for  the   product  in  long  term  (3-­‐‑5   years) Serves  as  the  input  for   overall  product  roadmap  in   medium  term  (1-­‐‑3  years)   Product  Roadmap Calls  out  the  high-­‐‑level   themes  and  release  timeline   in  next  1-­‐‑3  years Consists  of  swimlanes   (strategic  priorities  vs.  lights   on,  client  requests,vs.   competitive  intel,  technical   debt  vs  innovation  ideas,,   etc.) Reviewed  each  quarter  by   Product  Council Product  Backlog Prioritized  list  of  features   identified  for  the  next  1-­‐‑3   releases Owned  and  maintained  by   respective  POs  based  on   relative  prioritization  of  each   feature  request   Revised  constantly  based  on   evolving  inputs  and  refined   weekly  in  grooming  sessions   with  scrum  team Sprint  Backlog Consists  of  highest-­‐‑priority  /   highest-­‐‑value  features  agreed   upon  for  development  in  the   current  sprint  (1-­‐‑4  weeks) Product  Owner  responsible   to  prioritize  the  features,   while  scrum  team   responsible  for  planning,   estimation,  planning,   execution  and  completion  of   those  features  in  a  sprint Once  the  sprint  has  started,   any  new  requirements  or   change  request  must  wait   until  the  next  sprint  planning
  15. Adaptive  Planning Product  Backlog Product  Roadmap Sprint  Backlog Product  Vision Futuristic   picture  of  the   product Based  on   technology   evolution,   market   development,   industry   trends,  etc. Reviewed   annually,   and  revised   as  needed High-­‐‑level   wish  list  of   themes  and   epics  for  a   long-­‐‑term Reviewed   by  Product   Council  on  a   quarterly   basis Typically   revised   annually Prioritized   list  of   Themes,   Epics  and   User  Stories Gets   constantly   revised  and   groomed  on  a   weekly  basis Well-­‐‑ groomed   User  Stories Can’t  be   changed  once   the  sprint  is   underway Current  Sprint 3-­‐‑6  months 12-­‐‑24  months 1-­‐‑3  years Small  Stories,   Firm  Requirements,   Large  Stories  /  Epics  /  Themes,   Fuzzy  /  Evolving  Requirements Predictable delivery of Features FlexibilitytoaccommodateChanges
  16. Product  Management  Artifacts Initiatives   Epics Themes Sprint  Backlog Product  Backlog Product  Roadmap Product  Vision Tasks… Stories Scenarios
  17. Product  Vision Shared  by  All Desirable  and  Inspirational Clear  and  Tangible Broad  and  Engaging Short  and  Sweet
  18. Product  Vision  –  Elevator  Pitch For  (target  customer) Who  (statement  of  the  need  or  opportunity) The  (product  name)  is  a  (product  category) That  (key  benefit,  compelling  reason  to  buy) Unlike  (primary  competitive  alternative) Our  product  (statement  of  primary  differentiation) hNp://  
  19. Product  Vision  Box v As  the  name   suggests… v Describes   the  top  2-­‐‑3   features  of   product
  20. Press  Release v Amazon’s   “working   backwards” v Write  the   launch  press   release!
  21. Kano  Model
  22. MoSCoW • Describes  a  requirement  that  must  be  satisfied  in  the  final   solution  for  the  solution  to  be  considered  a  success. MUST • Represents  a  high-­‐‑priority  item  that  should  be  included  in   the  solution  if  it  is  possible.  This  is  often  a  critical   requirement  but  one  which  can  be  satisfied  in  other  ways  if   strictly  necessary. SHOULD • Describes  a  requirement  which  is  considered  desirable  but   not  necessary.  This  will  be  included  if  time  and  resources   permit. COULD • Represents  a  requirement  that  stakeholders  have  agreed   will  not  be  implemented  in  a  given  release,  but  may  be   considered  for  the  future.   WON'ʹT
  23. Minimal  Marketable  Feature A  Minimal  Marketable  Feature  (MMF)  is  a  feature  that  is  minimal,   because  if  it  was  any  smaller,  it  would  not  be  marketable.  A  MMF  is   marketable,  because  when  it  is  released  as  part  of  a  product,  people   would  use  (or  buy)  the  feature. An  MMF  is  different  than  a  typical  User  Story  in  Scrum  or  Extreme   Programming.  Where  multiple  User  Stories  might  be  coalesced  to   form  a  single  marketable  feature,  MMFs  are  a  liNle  bit  bigger.  Often,   there  is  a  release  after  each  MMF  is  complete. An  MMF  doesn’t  decompose  down  into  smaller  sub-­‐‑feature,  but  it  is   big  enough  to  launch  on  its  own. A  MMF  can  be  represented  as  a  User  Story  —  a  short,  one-­‐‑sentence   description.
  24. MVP,  MMF,  Stories MVP MMFs Stories
  25. Product  Roadmap hNp://­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/   hNp://   •  High-­‐‑level  plan   that  describes  how   the  product  will   evolve •  Refers  to •  Product  version •  Functionality •  Release  date  
  26. Benefits  of  Product  Roadmap Helps  communicate  how  you  see  the  product  develop. Helps  align  the  product  and  the  company  strategy.   Helps  manage  the  stakeholders  and  coordinate  the   development,  marketing,  and  sales  activities. Facilitates  effective  portfolio  management,  as  it  helps   synchronise  the  development  efforts  of  different  products. Supports  and  complements  the  product  backlog.  This   allows  the  backlog  to  focus  on  the  tactical  product   development  aspects. hNp://­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  27. Product  Backlog  Iceberg
  28. Product  Backlog A  combined  list  of  all  desired  work,  including  user   focused  stories,  technical  work,  features  &  ideas Everything  is  expressed  in  User  Stories List  is  prioritized  by  the  Product  Owner Product  Owner  keeps  it  organized  with  the  team’s  help Anyone  can  add  items  to  the  backlog Evolves  over  time   Always  in  progress
  29. Product  Backlog v  The  agile  product  backlog  is  a   prioritized  features  list,  containing  short   descriptions  of  all  functionality  desired   in  the  product.   v  When  using  Scrum,  it  is  not  necessary  to   start  a  project  with  a  lengthy,  upfront   effort  to  document  all  requirements.   v  Typically,  a  Scrum  team  and  its  product   owner  begin  by  writing  down   everything  they  can  think  of  for  agile   backlog  prioritization.  This  agile   product  backlog  is  almost  always  more   than  enough  for  a  first  sprint.   The  Scrum  product  backlog  is  then   allowed  to  grow  and  change  as  more  is   learned  about  the  product  and  its   customers. v  hNp:// scrum/product-­‐‑backlog  
  30. ….should  be  “DEEP” • Detailed  Appropriately D: • Estimated E: • Emergent E: • Prioritized P:
  31. Estimated  Product  Backlog
  32. Prioritized  Backlog
  33. Multiple  Backlogs? hNp://­‐‑grooming/  
  34. Many  Projects,  One  Team hNp://  
  35. One  Project,  Many  Teams hNp://  
  36. Many  Projects,  Many  Teams hNp://  
  37. From  Product  Roadmap  to  Product  Backlog hNp://­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  38. Who  owns  Product  Backlog? hNp://­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  39. Sprint  Backlog v User  Stories   selected  by  the   Team v Will  be  built  in   current  Sprint v Fully  Estimated v Divided  into   Tasks
  40. Potentially  Shippable  Increment v  Most  agile  processes  require  development  teams  to  built  an  increment  of  product   functionality  every  iteration,  or  Sprint.  Scrum  and  Extreme  Programming  require  that   this  increment  be  potentially  shippable,  if  the  customer  desires  to  implement  the   functionality.  This  usually  requires  that  the  increment  consist  of  thoroughly  tested   code  that  has  been  built  into  an  executable,  and  the  user  operation  of  the   functionality  is  documented,  either  in  Help  files  or  user  documentation.    If  the   product  increment  that  is  created  during  the  iteration  has  more  exacting  use,  the   development  organization  usually  defines  the  additional  product  requirements  as   standards  or  conventions.   v  For  example,  the  Federal  Drug  Administration  (FDA)  must  approve  a  product  that  will   be  used  in  life  critical  circumstances  by  in  numerous  health  care  seNings  if  the  product   is  to  be  used  in  the  United  States.  As  part  of  the  approval  process,  the  FDA  checks  that   specific  information  regarding  the  product  is  provided,  such  as  requirements   traceability  and  specific  functionality  operation.  For  each  increment  to  be  potentially   shippable,  these  additional  facets  of  the  product  must  also  be  developed  ñ  so  that  each   increment  of  the  product  is  potentially  ready  for  FDA  approval.   v  Similarly,  some  products  require  that  performance  requirements  be  modeled  and  the   performance  demonstrated  mathematically,  not  just  through  statistical  measurement  of   the  actual  system.  The  model  with  all  required  rigor  is  thus  an  additional  part  of  each   iteration  ís  potentially  shippable  increment.   hNp://  
  41. Backlog  Grooming v Upto  10%   of  sprint   time v Creating  or   refining   new  PBIs v Estimating   PBIs v Prioritizing   PBIs
  42. Release  Planning
  43. Release  Burn-­‐‑down  Chart
  44. Feature  planning  in  Fixed  #Sprints
  45. User  Story I as a <Role> want <Feature> so that <Value>
  46. The  Three  C’s  of  a  User  Story • The  story  itself • A  promise  to  have  a  conversation  at  the   appropriate  time Card • The  requirements  themselves   communicated  from  the  PO  to  the  Delivery   Team  via  a  conversation • Write  down  what  is  agreed  upon Conversation • The  Acceptance  Criteria  for  the  story • How  the  Delivery  Team  will  know  they   have  completed  the  story Confirmation
  47. What  makes  a  good  User  Story? Independent  of  all  others Negotiable  not  a  specific  contract  for  features Valuable  or  vertical Estimable  to  a  good  approximation Small  so  as  to  fit  within  an  iteration Testable  in  principle,  even  if  there  isn’t  a  test  for  it  yet hNp://  
  48. Acceptance  Criteria 52 Given <System State> when <an event occurs> then <an outcome happens>
  49. Performance  Constraint  -­‐‑>  Acceptance  Criteria
  50. “Done” •  Defines  the  good  working  development   practices  that  will  be  delivered  with  each   item  as  it  is  ready  for  acceptance •  Common  entries  in  Definition  of  Done: •  Code  includes  unit  tests,  reviewed,  checked  in •  Tests  described  and  executed •  Build,  release  notes •  Compliance  documentation  updated  to  include  current  functionality •  Satisfies  agreed-­‐‑upon  acceptance  criteria • Done  focuses  on  internal  quality •  Applies  to  all  items  in  Product  Backlog  “Building  the  thing  right” • Acceptance  criteria  focuses  on  external   quality •  Functionality  “Building  the  right  thing”
  51. Epics v  A  Scrum  epic  is  a  large  user  story.  There'ʹs  no  magic  threshold  at   which  we  call  a  particular  story  an  epic.  It  just  means  “big  user   story.”  I  like  to  think  of  this  in  relation  to  movies.  If  I  tell  you  a   particular  movie  was  an  “action-­‐‑adventure  movie”  that  tells  you   something  about  the  movie.  There'ʹs  probably  some  car  chases,   probably  some  shooting,  and  so  on.  It  tells  you  this  even  though   there  is  no  universal  definition  that  we'ʹve  agreed  to  follow,  and  that   an  action-­‐‑adventure  movie  must  contain  at  least  three  car  chases,  at   least  45  bullets  must  be  shot,  and  …. v  So,  “epic”  is  just  a  label  we  apply  to  a  large  story.  Calling  a  story  an   epic  can  sometimes  convey  additional  meaning.  Suppose  you  ask  me   if  I  had  time  yesterday  to  write  the  user  stories  about  the  monthly   reporting  part  of  the  system.  “Yes,”  I  reply,  “but  they  are  mostly   epics.”  That  tells  you  that  while  I  did  write  them,  I  didn'ʹt  get  the   chance  to  break  most  of  them  down  into  stories  that  are  probably   small  enough  to  implement  directly. hNp://­‐‑epics-­‐‑and-­‐‑themes  
  52. Epics  -­‐‑>  Stories
  53. Themes,  Epics,  Stories,  Tasks
  54. Themes We  could  put  a  rubber  band  around  that   group  of  stories  I  wrote  about  monthly   reporting  and  we'ʹd  call  that  a  “theme.”   Sometimes  it'ʹs  helpful  to  think  about  a  group   of  stories  so  we  have  a  term  for  that.  Sticking   with  the  movie  analogy  above,  in  my  DVD   rack  I  have  filed  the  James  Bond  movies   together.  They  are  a  theme  or  grouping. hNp://­‐‑epics-­‐‑and-­‐‑themes  
  55. Themes  change/evolve… Scrum  Product  Ownership  –  Bob  Galen
  56. hNp://­‐‑content/uploads/2012/01/Story-­‐‑SpliNing-­‐‑Flowchart.pdf  
  57. SpliNing  User  Stories
  58. Scenarios v  A  usage  scenario,  or  scenario  for  short,  describes  a   real-­‐‑world  example  of  how  one  or  more  people  or   organizations  interact  with  a  system.     v  They  describe  the  steps,  events,  and/or  actions   which  occur  during  the  interaction.     v  Usage  scenarios  can  be  very  detailed,  indicating   exactly  how  someone  works  with  the  user  interface,   or  reasonably  high-­‐‑level  describing  the  critical   business  actions  but  not  the  indicating  how  they’re   performed.      
  59. Scenarios,  User  Case,  User  Story Use  Case: Customer  walks  to  the  restaurant   Customer  enters  the  restaurant   Customer  finds  a  seat  at  the  bar   Customer  scans  the  menu   Customer  selects  a  beer   Customer  orders  selected  beer   Bartender  takes  order   Bartender  pours  beer   Bartender  delivers  beer   User  drinks  beer   User  pays  for  beer User  Story: A  user  wants  to  find  a  bar,  to  drink  a   beer. hNp://­‐‑user-­‐‑stories-­‐‑user-­‐‑personas-­‐‑use-­‐‑cases-­‐‑whats-­‐‑the-­‐‑difference/   Scenario: Josh  is  a  30  something  mid-­‐‑level   manager  for  an  ad  agency,  metro-­‐‑ sexual  and  beer  aficionado.  He  likes  to   try  new  and  exotic  beers  in  trendy   locations.  He  also  enjoys  using  a   variety  of  social  apps  on  his  smart   phone.  He  reads  a  review    on  Yelp  of  a   new  burger  &  beer  joint  downtown   with  over  100  beers  on  tap,  and  decides   to  go  walk  over  after  work  and  check  it   out.  
  60. User  Story  Mapping
  61. ©  Jeff  Pa(on,  all  rights  reserved,   The  user  story  map  contains  two   important  anatomical  features v  The  backbone  of  the  application  is  the  list  of   essential  activities  the  application  supports v  The  walking  skeleton  is  the  software  we  build   that  supports  the  least  number  of  necessary   tasks  across  the  full  span  of  user  experience time necessity The backbone The walking skeleton
  62. Scrum  Framework
  63. Roles,  Ceremonies  and  Artifacts •  Scrum  Team  is  small   (5-­‐‑9),  cross-­‐‑ functional  team   members  from  Dev,   UX,  QA  (excluding   Product  Owner)  to   ship  complete   feature(s)  end  to  end   •  Scrum  Master  is  the   servant  leader   responsible  for   supporting  team •  Product  Owner   owns  Product   Backlog  and  sets   appropriate  priority   for  team  to  act  upon Roles Product   Owner Scrum  Master Scrum  Team Ceremonies Sprint  Planning   Meeting Daily  Stand-­‐‑ ups Backlog   Grooming Product  Demo Sprint   Retrospective Artifacts Product   Backlog Sprint  Backlog Increment Release  Burn-­‐‑ down  Chart Sprint  Burn-­‐‑ down  Chart
  64. Scrum  Roles
  65. Product  Owner hNp://­‐‑product-­‐‑owner-­‐‑the-­‐‑poster/  
  66. Product  Management  Spectrum hNp://­‐‑is-­‐‑a-­‐‑product-­‐‑manager/  
  67. Too  many  roles? hNp://­‐‑single-­‐‑product-­‐‑owner/  
  68. “There  can  only  be  one” hNp://­‐‑single-­‐‑product-­‐‑owner/  
  69. Product  Owner  Role
  70. Why? v Reduce  hand-­‐‑offs v Ensure  continuity v Ownership v Enables  long-­‐‑term  thinking
  71. Product  Owner The  product  owner  has  responsibility  for  deciding  what  work  will  be  done.  This  is  the  single  individual   who  is  responsible  for  bringing  forward  the  most  valuable  product  possible  by  the  desired  date.  The   product  owner  does  this  by  managing  the  flow  of  work  to  the  team,  selecting  and  refining  items  from  the   product  backlog.  The  product  owner  maintains  the  product  backlog  and  ensures  that  everyone  knows  what   is  on  it  and  what  the  priorities  are.  The  product  owner  may  be  supported  by  other  individuals  but  must  be  a   single  person. Certainly  the  product  owner  is  not  solely  responsible  for  everything.  The  entire  Scrum  team  is  responsible   for  being  as  productive  as  possible,  for  improving  its  practices,  for  asking  the  right  questions,  for  helping   the  product  owner. Nonetheless,  the  product  owner,  in  Scrum,  is  in  a  unique  position.  The  product  owner  is  typically  the   individual  closest  to  the  "ʺbusiness  side"ʺ  of  the  project.  The  product  owner  is  charged  by  the  organization  to   "ʺget  this  product  out"ʺ  and  is  the  person  who  is  expected  to  do  the  best  possible  job  of  satisfying  all  the   stakeholders.  The  product  owner  does  this  by  managing  the  product  backlog  and  by  ensuring  that  the   backlog,  and  progress  against  it,  is  kept  visible. The  product  owner,  by  choosing  what  the  development  team  should  do  next  and  what  to  defer,  makes  the   scope-­‐‑versus-­‐‑schedule  decisions  that  should  lead  to  the  best  possible  product. hNp://­‐‑scrum/core-­‐‑scrum-­‐‑values-­‐‑
  72. Old  School  Vs.  New  School Old  School New  School Several  roles  bring   product  to  life One  role  is  responsible Detached  from   development  teams Member  of  scrum  teams Extensive  work  up-­‐‑front Minimum  work  up-­‐‑front Up-­‐‑front  product   discovery Continuous  product   discovery Late  customer  feedback Early  and  frequent  customer   feedback Agile  Product  Management  with  Scrum  –  Roman  Pichler
  73. Responsibilities  Affected You  Used  to  do  This Now  do  This Write  an  exhaustive  PRD Write  user  stories  and  maintain  a   backlog Strive  to  get  it  right  the  first  time Use  experimentation  as  a   competitive  advantage Innovate  and  differentiate  within   the  confines  of  Product   Management Leverage  the  creativity  of  your   entire  cross-­‐‑functional  team  to   innovate  and  differentiate Have  large  amounts  of  time   between  input  and  delivery,   watching  market  changes   without  the  ability  to  change   course Be  involved  on  a  daily  basis  to   maximize  the  value  delivered
  74. Responsibilities  -­‐‑  continued Always  do  This Because… Understand  and  communicate   Market  Requirements Helps  ensure  alignment Have  a  clear  customer  value   proposition  and  metrics Enables  experimentation  as  a   competitive  advantage Seek  and  find  Early  Release   Opportunities Provides  rich  learning   environment,  early  feedback,  less   guesswork
  75. Top  5  ways  POs  can  support  your  team   Share  the  product  backlog  for  feedback  from  the  team  a   few  days  before  sprint  planning Collaborate  with  the  team  to  produce  a  great  product   through  product  backlog  management  and  delivery ANend  the  daily  stand-­‐‑up Come  to  planning  meetings  prepared Provide  a  longer-­‐‑term  view  of  product  vision,  roadmap,   and  goals  that  is  negotiable  in  how  it  is  delivered
  76. Top  5  PM/PO  behaviors  to  reconsider       The  whole  list  is  “must  have”,  by  the  target   release  date Product  backlog  isn’t  ready  for  the  team  to  plan   with Not  able  to  describe  context  and  assumptions  for   product  backlog  items Not  involving  the  team  in  backlog  management Not  knowing  your  market
  77. Product  Owner  Anti-­‐‑PaNerns Trying  to  reprioritize  the  work  that  team  has  commiNed  to   in  a  sprint Trying  to  unilaterally  add  or  remove  content  of  a  Sprint   backlog  after  the  team  has  commiNed  to  its  delivery Dictating,  or  trying  to  overrule,  the  estimates  that  a  team   provides Interfering  with  the  Development  Team’s  ability  to  deliver   on  their  Sprint  commitments Deferring  business  decisions  to  the  development  teams Expecting  the  development  team  to  plan  beyond  one   iteration hNp://­‐‑ownership-­‐‑practice  
  78. Common  Product  Owner  Traps The  Underpowered  Product  Owner The  Overpowered  Product  Owner The  Partial  Product  Owner The  Distant  Product  Owner The  Proxy  Product  Owner The  Product  Owner  CommiNee hNp://­‐‑product-­‐‑owner-­‐‑traps  
  79. Potential  Product  Owner  Pitfalls Product  Backlog  doesn’t  exist Product  Backlog  not  visible  to  The  Team Never-­‐‑ending  stories Stories  too  big Product  Owner  without  power  or  domain  knowledge More  than  1  Product  Owner Product  Backlog  not  maintained Product  Owner  surprised  at  Sprint  Demo Product  Owner  not  prioritizing Product  Owner  being  a  boNleneck
  80. Agile  Product  Ownership  in  a  Nutshell hNp://