SlideShare ist ein Scribd-Unternehmen logo
1 von 91
Downloaden Sie, um offline zu lesen
{	
Agile  Product  Owner  
in  Wonderland!	
Tathagat  Varma	
VP,  Strategic  Process  Innovations	
[24]7  Innovation  Labs
v Agile  Philosophy	
v Scrum  Methodology	
v Product  Owner  Role	
v Agile  in  Hardware  /  Systems	
Topics…
Identify  yourself…J
hNp://headrush.typepad.com/creating_passionate_users/2005/06/featuritis_vs_t.html  
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://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html  
hNp://blog.comsysto.com/2012/08/13/continuous-­‐‑delivery-­‐‑of-­‐‑waste/  
hNp://blog.comsysto.com/2012/08/13/continuous-­‐‑delivery-­‐‑of-­‐‑waste/    
Agile Product Owner in Wonderland!
hNp://www.emilianosoldipmp.info/wp-­‐‑content/uploads/2012/08/Stacey.png  	
That’s  the  
problem  we  
need  to  solve!	
And  these  are  
the  methods  
we  are  using!!!
Agile Product Owner in Wonderland!
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.
Feedback  Loops  in  Traditional  Techniques  
vs.  Agile  Techniques
Waterfall  vs.  Agile:  Risk  vs.  Value  Delivered	
hNp://www.testingthefuture.net/wp-­‐‑content/uploads/2011/12/waterfall_versus_agile_development.png  
Agile  ROI	
hNp://www.agileload.com/agileload//blog/2012/10/22/agile-­‐‑performance-­‐‑testing-­‐‑process-­‐‑-­‐‑-­‐‑whitepaper  
5  Levels  of  Agile  Planning
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
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
Product  Management  Artifacts	
Initiatives  	
Epics	
Themes	
Sprint  Backlog	
Product  Backlog	
Product  Roadmap	
Product  Vision	
Tasks…	
Stories	
Scenarios
Product  Vision	
Shared  by  All	
Desirable  and  Inspirational	
Clear  and  Tangible	
Broad  and  Engaging	
Short  and  Sweet
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://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html  
Product  Vision  Box	
v As  the  name  
suggests…	
v Describes  
the  top  2-­‐‑3  
features  of  
product
Press  Release	
v Amazon’s  
“working  
backwards”	
v Write  the  
launch  press  
release!
Kano  Model
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
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.
MVP,  MMF,  Stories	
MVP	
MMFs	
Stories
Agile Product Owner in Wonderland!
Product  Roadmap	
hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  	
hNp://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png  	
•  High-­‐‑level  plan  
that  describes  how  
the  product  will  
evolve	
•  Refers  to	
•  Product  version	
•  Functionality	
•  Release  date  
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://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
Product  Backlog  Iceberg
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
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://www.mountaingoatsoftware.com/
scrum/product-­‐‑backlog  
….should  be  “DEEP”	
• Detailed  Appropriately	
D:	
• Estimated	
E:	
• Emergent	
E:	
• Prioritized	
P:
Estimated  Product  Backlog
Prioritized  Backlog
Multiple  Backlogs?	
hNp://inevitablyagile.wordpress.com/2010/05/06/backlog-­‐‑grooming/  
Many  Projects,  One  Team	
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
One  Project,  Many  Teams	
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
Many  Projects,  Many  Teams	
hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
From  Product  Roadmap  to  Product  Backlog	
hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
Who  owns  Product  Backlog?	
hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
Sprint  Backlog	
v User  Stories  
selected  by  the  
Team	
v Will  be  built  in  
current  Sprint	
v Fully  Estimated	
v Divided  into  
Tasks
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://cf.agilealliance.org/articles/system/article/file/970/file.pdf  
Backlog  Grooming	
v Upto  10%  
of  sprint  
time	
v Creating  or  
refining  
new  PBIs	
v Estimating  
PBIs	
v Prioritizing  
PBIs
Release  Planning
Agile Product Owner in Wonderland!
Release  Burn-­‐‑down  Chart
Feature  planning  in  Fixed  #Sprints
User  Story	
I as a <Role>
	
want <Feature>
	
so that <Value>
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
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://guide.agilealliance.org/guide/invest.html  
Acceptance  Criteria	
52	
Given <System State>

when <an event occurs>

then <an outcome happens>
Performance  Constraint  -­‐‑>  Acceptance  Criteria
“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”
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://www.mountaingoatsoftware.com/blog/stories-­‐‑epics-­‐‑and-­‐‑themes  
Epics  -­‐‑>  Stories
Themes,  Epics,  Stories,  Tasks
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://www.mountaingoatsoftware.com/blog/stories-­‐‑epics-­‐‑and-­‐‑themes  
Themes  change/evolve…	
Scrum  Product  Ownership  –  Bob  Galen
hNp://www.agileforall.com/wp-­‐‑content/uploads/2012/01/Story-­‐‑SpliNing-­‐‑Flowchart.pdf  
SpliNing  User  Stories
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.      
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://www.cloudforestdesign.com/2011/04/25/introduction-­‐‑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.	
  
User  Story  Mapping
©	
  Jeff	
  Pa(on,	
  all	
  rights	
  reserved,	
  www.AgileProductDesign.com	
  
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
Agile Product Owner in Wonderland!
Agile Product Owner in Wonderland!
Scrum  Framework
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
Scrum  Roles
Product  Owner	
hNp://williamgill.de/2012/10/01/the-­‐‑product-­‐‑owner-­‐‑the-­‐‑poster/  
Product  Management  Spectrum	
hNp://enlogica.com/uncategorized/what-­‐‑is-­‐‑a-­‐‑product-­‐‑manager/  
Agile Product Owner in Wonderland!
Too  many  roles?	
hNp://www.romanpichler.com/blog/roles/the-­‐‑single-­‐‑product-­‐‑owner/  
“There  can  only  be  one”	
hNp://www.romanpichler.com/blog/roles/the-­‐‑single-­‐‑product-­‐‑owner/  
Product  Owner  Role
Why?	
v Reduce  hand-­‐‑offs	
v Ensure  continuity	
v Ownership	
v Enables  long-­‐‑term  thinking
Agile Product Owner in Wonderland!
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://www.scrumalliance.org/why-­‐‑scrum/core-­‐‑scrum-­‐‑values-­‐‑
Agile Product Owner in Wonderland!
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
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
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
Agile Product Owner in Wonderland!
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
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
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://agile.dzone.com/articles/product-­‐‑ownership-­‐‑practice  
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://www.scrumalliance.org/community/articles/2010/april/common-­‐‑product-­‐‑owner-­‐‑traps  
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
Agile  Product  Ownership  in  a  Nutshell	
hNp://youtu.be/502ILHjX9EE  
Agile Product Owner in Wonderland!

Más contenido relacionado

Was ist angesagt?

Product owner Roles and responsibilities in Agile Scrum Methodologies
Product owner Roles and responsibilities in Agile Scrum MethodologiesProduct owner Roles and responsibilities in Agile Scrum Methodologies
Product owner Roles and responsibilities in Agile Scrum MethodologiesAgile Project Management
 
Analysis In Agile: It's More than Just User Stories
Analysis In Agile: It's More than Just User StoriesAnalysis In Agile: It's More than Just User Stories
Analysis In Agile: It's More than Just User StoriesKent McDonald
 
The Product Owner Role
The Product Owner RoleThe Product Owner Role
The Product Owner RoleRoman Pichler
 
Product Owner and Strategy
Product Owner and StrategyProduct Owner and Strategy
Product Owner and StrategyRoman Pichler
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumArrielle Mali
 
NYT Product Discovery Activity Guide
NYT Product Discovery Activity GuideNYT Product Discovery Activity Guide
NYT Product Discovery Activity GuideAl Ming
 
Overview of Agile Methodology
Overview of Agile MethodologyOverview of Agile Methodology
Overview of Agile MethodologyHaresh Karkar
 
Tips for Building a Compelling Product Vision by Amazon Sr PM
Tips for Building a Compelling Product Vision by Amazon Sr PMTips for Building a Compelling Product Vision by Amazon Sr PM
Tips for Building a Compelling Product Vision by Amazon Sr PMProduct School
 
Agile presentation
Agile presentationAgile presentation
Agile presentationinfolock
 
Cheat Sheet: 8 ways to split your user stories
Cheat Sheet:  8 ways to split your user storiesCheat Sheet:  8 ways to split your user stories
Cheat Sheet: 8 ways to split your user storiesPayton Consulting
 

Was ist angesagt? (20)

Product owner Roles and responsibilities in Agile Scrum Methodologies
Product owner Roles and responsibilities in Agile Scrum MethodologiesProduct owner Roles and responsibilities in Agile Scrum Methodologies
Product owner Roles and responsibilities in Agile Scrum Methodologies
 
Scrum Product Owner
Scrum Product OwnerScrum Product Owner
Scrum Product Owner
 
Agile 101
Agile 101Agile 101
Agile 101
 
Product roadmap 101
Product roadmap 101Product roadmap 101
Product roadmap 101
 
Product Roadmap
Product RoadmapProduct Roadmap
Product Roadmap
 
Analysis In Agile: It's More than Just User Stories
Analysis In Agile: It's More than Just User StoriesAnalysis In Agile: It's More than Just User Stories
Analysis In Agile: It's More than Just User Stories
 
Agile Story Writing
Agile Story WritingAgile Story Writing
Agile Story Writing
 
The Product Owner Role
The Product Owner RoleThe Product Owner Role
The Product Owner Role
 
Agile
AgileAgile
Agile
 
Product Owner and Strategy
Product Owner and StrategyProduct Owner and Strategy
Product Owner and Strategy
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to Scrum
 
NYT Product Discovery Activity Guide
NYT Product Discovery Activity GuideNYT Product Discovery Activity Guide
NYT Product Discovery Activity Guide
 
Overview of Agile Methodology
Overview of Agile MethodologyOverview of Agile Methodology
Overview of Agile Methodology
 
What Is Agile Scrum
What Is Agile ScrumWhat Is Agile Scrum
What Is Agile Scrum
 
Creating a Product Vision
Creating a Product VisionCreating a Product Vision
Creating a Product Vision
 
Agile Metrics
Agile MetricsAgile Metrics
Agile Metrics
 
Tips for Building a Compelling Product Vision by Amazon Sr PM
Tips for Building a Compelling Product Vision by Amazon Sr PMTips for Building a Compelling Product Vision by Amazon Sr PM
Tips for Building a Compelling Product Vision by Amazon Sr PM
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Agile Release & Iteration Planning
Agile Release & Iteration Planning   Agile Release & Iteration Planning
Agile Release & Iteration Planning
 
Cheat Sheet: 8 ways to split your user stories
Cheat Sheet:  8 ways to split your user storiesCheat Sheet:  8 ways to split your user stories
Cheat Sheet: 8 ways to split your user stories
 

Ähnlich wie Agile Product Owner in Wonderland!

Scaling Agile - Agility Defined
Scaling Agile - Agility DefinedScaling Agile - Agility Defined
Scaling Agile - Agility DefinedVibhu Srinivasan
 
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)Samuel Chin, PMP, CSM
 
Product Management 101: Techniques for Success
Product Management 101:  Techniques for SuccessProduct Management 101:  Techniques for Success
Product Management 101: Techniques for SuccessMatterport
 
How to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderHow to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderProduct School
 
Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Enthiosys Inc
 
The Butterfly Principle for Product Management by GameBench CEO
The Butterfly Principle for Product Management by GameBench CEOThe Butterfly Principle for Product Management by GameBench CEO
The Butterfly Principle for Product Management by GameBench CEOProduct School
 
Collaborative Roadmapping
Collaborative Roadmapping Collaborative Roadmapping
Collaborative Roadmapping Enthiosys Inc
 
How to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorHow to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorProduct School
 
Product Development - Founder Institute
Product Development - Founder InstituteProduct Development - Founder Institute
Product Development - Founder InstituteAlex Gault
 
How to efficiently build great products in a startup
How to efficiently build great products in a startupHow to efficiently build great products in a startup
How to efficiently build great products in a startupRoger Dudler
 
Patton product owner_role
Patton product owner_rolePatton product owner_role
Patton product owner_roleHindu Dharma
 
Mapping Your MVP Product Development in 30 min or Less
Mapping Your MVP Product Development in 30 min or LessMapping Your MVP Product Development in 30 min or Less
Mapping Your MVP Product Development in 30 min or LessCodeScience
 
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...Matt Roberts
 
PCC2 - How do I incorporate Apple-like design into my products?
PCC2 - How do I incorporate Apple-like design into my products?PCC2 - How do I incorporate Apple-like design into my products?
PCC2 - How do I incorporate Apple-like design into my products?ProductCamp Chicago
 
How to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorHow to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorProduct School
 
Transitioning to Product Manager
Transitioning to Product ManagerTransitioning to Product Manager
Transitioning to Product ManagerToufiq Mahmud
 

Ähnlich wie Agile Product Owner in Wonderland! (20)

Scaling Agile - Agility Defined
Scaling Agile - Agility DefinedScaling Agile - Agility Defined
Scaling Agile - Agility Defined
 
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)
Products and Value: An Agile Perspective BY Matt Nudelmann (GUEST PRESENTER)
 
Product Management 101: Techniques for Success
Product Management 101:  Techniques for SuccessProduct Management 101:  Techniques for Success
Product Management 101: Techniques for Success
 
Product management
Product management  Product management
Product management
 
How to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate FounderHow to Best Develop a Product by PlateRate Founder
How to Best Develop a Product by PlateRate Founder
 
Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)Agile Comes to You (Mironov, Bellevue)
Agile Comes to You (Mironov, Bellevue)
 
The Butterfly Principle for Product Management by GameBench CEO
The Butterfly Principle for Product Management by GameBench CEOThe Butterfly Principle for Product Management by GameBench CEO
The Butterfly Principle for Product Management by GameBench CEO
 
Collaborative Roadmapping
Collaborative Roadmapping Collaborative Roadmapping
Collaborative Roadmapping
 
How to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorHow to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product Advisor
 
Scrum with Asana
Scrum with AsanaScrum with Asana
Scrum with Asana
 
Product Development - Founder Institute
Product Development - Founder InstituteProduct Development - Founder Institute
Product Development - Founder Institute
 
How to efficiently build great products in a startup
How to efficiently build great products in a startupHow to efficiently build great products in a startup
How to efficiently build great products in a startup
 
Agile.docx
Agile.docxAgile.docx
Agile.docx
 
Product Management Primer
Product Management PrimerProduct Management Primer
Product Management Primer
 
Patton product owner_role
Patton product owner_rolePatton product owner_role
Patton product owner_role
 
Mapping Your MVP Product Development in 30 min or Less
Mapping Your MVP Product Development in 30 min or LessMapping Your MVP Product Development in 30 min or Less
Mapping Your MVP Product Development in 30 min or Less
 
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...
Radical Roadmapping - Creating Synchronized Agile Product and Technology Road...
 
PCC2 - How do I incorporate Apple-like design into my products?
PCC2 - How do I incorporate Apple-like design into my products?PCC2 - How do I incorporate Apple-like design into my products?
PCC2 - How do I incorporate Apple-like design into my products?
 
How to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product AdvisorHow to Use Data to Build Products by Tradesy Product Advisor
How to Use Data to Build Products by Tradesy Product Advisor
 
Transitioning to Product Manager
Transitioning to Product ManagerTransitioning to Product Manager
Transitioning to Product Manager
 

Mehr von Tathagat Varma

Can AI finally "cure" the Marketing Myopia?
Can AI finally "cure" the Marketing Myopia?Can AI finally "cure" the Marketing Myopia?
Can AI finally "cure" the Marketing Myopia?Tathagat Varma
 
AI in Manufacturing: Opportunities & Challenges
AI in Manufacturing: Opportunities & ChallengesAI in Manufacturing: Opportunities & Challenges
AI in Manufacturing: Opportunities & ChallengesTathagat Varma
 
Preparing for the next ________?
Preparing for the next ________?Preparing for the next ________?
Preparing for the next ________?Tathagat Varma
 
AI in Business: Opportunities & Challenges
AI in Business: Opportunities & ChallengesAI in Business: Opportunities & Challenges
AI in Business: Opportunities & ChallengesTathagat Varma
 
Leadership Agility Mindsets
Leadership Agility MindsetsLeadership Agility Mindsets
Leadership Agility MindsetsTathagat Varma
 
Building an AI Startup
Building an AI StartupBuilding an AI Startup
Building an AI StartupTathagat Varma
 
Agility in an AI / DS / ML Project
Agility in an AI / DS / ML ProjectAgility in an AI / DS / ML Project
Agility in an AI / DS / ML ProjectTathagat Varma
 
AI Technology Delivering Business Value
AI Technology Delivering Business Value AI Technology Delivering Business Value
AI Technology Delivering Business Value Tathagat Varma
 
Nurturing Innovation Mindset
Nurturing Innovation MindsetNurturing Innovation Mindset
Nurturing Innovation MindsetTathagat Varma
 
PMOs and Complexity Management
PMOs and Complexity ManagementPMOs and Complexity Management
PMOs and Complexity ManagementTathagat Varma
 
An Introduction to the Systematic Inventive Thinking (SIT) Method
An Introduction to the Systematic Inventive Thinking (SIT) MethodAn Introduction to the Systematic Inventive Thinking (SIT) Method
An Introduction to the Systematic Inventive Thinking (SIT) MethodTathagat Varma
 
I blog...therefore I am!
I blog...therefore I am!I blog...therefore I am!
I blog...therefore I am!Tathagat Varma
 
Bridging the gap between Education and Learning
Bridging the gap between Education and LearningBridging the gap between Education and Learning
Bridging the gap between Education and LearningTathagat Varma
 
Is my iceberg melting?
Is my iceberg melting?Is my iceberg melting?
Is my iceberg melting?Tathagat Varma
 
Digital Business Model Innovation
Digital Business Model InnovationDigital Business Model Innovation
Digital Business Model InnovationTathagat Varma
 
25 Years of Evolution of Software Product Management: A practitioner's perspe...
25 Years of Evolution of Software Product Management: A practitioner's perspe...25 Years of Evolution of Software Product Management: A practitioner's perspe...
25 Years of Evolution of Software Product Management: A practitioner's perspe...Tathagat Varma
 
Agility from First Principles
Agility from First PrinciplesAgility from First Principles
Agility from First PrinciplesTathagat Varma
 

Mehr von Tathagat Varma (20)

Can AI finally "cure" the Marketing Myopia?
Can AI finally "cure" the Marketing Myopia?Can AI finally "cure" the Marketing Myopia?
Can AI finally "cure" the Marketing Myopia?
 
AI in Manufacturing: Opportunities & Challenges
AI in Manufacturing: Opportunities & ChallengesAI in Manufacturing: Opportunities & Challenges
AI in Manufacturing: Opportunities & Challenges
 
Preparing for the next ________?
Preparing for the next ________?Preparing for the next ________?
Preparing for the next ________?
 
AI in Business: Opportunities & Challenges
AI in Business: Opportunities & ChallengesAI in Business: Opportunities & Challenges
AI in Business: Opportunities & Challenges
 
Leadership Agility Mindsets
Leadership Agility MindsetsLeadership Agility Mindsets
Leadership Agility Mindsets
 
Building an AI Startup
Building an AI StartupBuilding an AI Startup
Building an AI Startup
 
Agility in an AI / DS / ML Project
Agility in an AI / DS / ML ProjectAgility in an AI / DS / ML Project
Agility in an AI / DS / ML Project
 
Cognitive Chasms
Cognitive ChasmsCognitive Chasms
Cognitive Chasms
 
AI Technology Delivering Business Value
AI Technology Delivering Business Value AI Technology Delivering Business Value
AI Technology Delivering Business Value
 
Nurturing Innovation Mindset
Nurturing Innovation MindsetNurturing Innovation Mindset
Nurturing Innovation Mindset
 
Thought Leadership
Thought LeadershipThought Leadership
Thought Leadership
 
PMOs and Complexity Management
PMOs and Complexity ManagementPMOs and Complexity Management
PMOs and Complexity Management
 
An Introduction to the Systematic Inventive Thinking (SIT) Method
An Introduction to the Systematic Inventive Thinking (SIT) MethodAn Introduction to the Systematic Inventive Thinking (SIT) Method
An Introduction to the Systematic Inventive Thinking (SIT) Method
 
Agile at Scale
Agile at ScaleAgile at Scale
Agile at Scale
 
I blog...therefore I am!
I blog...therefore I am!I blog...therefore I am!
I blog...therefore I am!
 
Bridging the gap between Education and Learning
Bridging the gap between Education and LearningBridging the gap between Education and Learning
Bridging the gap between Education and Learning
 
Is my iceberg melting?
Is my iceberg melting?Is my iceberg melting?
Is my iceberg melting?
 
Digital Business Model Innovation
Digital Business Model InnovationDigital Business Model Innovation
Digital Business Model Innovation
 
25 Years of Evolution of Software Product Management: A practitioner's perspe...
25 Years of Evolution of Software Product Management: A practitioner's perspe...25 Years of Evolution of Software Product Management: A practitioner's perspe...
25 Years of Evolution of Software Product Management: A practitioner's perspe...
 
Agility from First Principles
Agility from First PrinciplesAgility from First Principles
Agility from First Principles
 

Último

Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...
Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...
Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...Splashtop Inc
 
Boost Efficiency: Sabre API Integration Made Easy
Boost Efficiency: Sabre API Integration Made EasyBoost Efficiency: Sabre API Integration Made Easy
Boost Efficiency: Sabre API Integration Made Easymichealwillson701
 
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxCYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxBarakaMuyengi
 
BusinessGPT - SECURITY AND GOVERNANCE FOR GENERATIVE AI.pptx
BusinessGPT  - SECURITY AND GOVERNANCE  FOR GENERATIVE AI.pptxBusinessGPT  - SECURITY AND GOVERNANCE  FOR GENERATIVE AI.pptx
BusinessGPT - SECURITY AND GOVERNANCE FOR GENERATIVE AI.pptxAGATSoftware
 
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurMinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurPriyadarshini T
 
Revolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridRevolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridMathew Thomas
 
Steps to Successfully Hire Ionic Developers
Steps to Successfully Hire Ionic DevelopersSteps to Successfully Hire Ionic Developers
Steps to Successfully Hire Ionic Developersmichealwillson701
 
Einstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfEinstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfCloudMetic
 
Large Scale Architecture -- The Unreasonable Effectiveness of Simplicity
Large Scale Architecture -- The Unreasonable Effectiveness of SimplicityLarge Scale Architecture -- The Unreasonable Effectiveness of Simplicity
Large Scale Architecture -- The Unreasonable Effectiveness of SimplicityRandy Shoup
 
Enterprise Content Managements Solutions
Enterprise Content Managements SolutionsEnterprise Content Managements Solutions
Enterprise Content Managements SolutionsIQBG inc
 
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfFlutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfMind IT Systems
 
Mobile App Development company Houston
Mobile  App  Development  company HoustonMobile  App  Development  company Houston
Mobile App Development company Houstonjennysmithusa549
 
VuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckVuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckNaval Singh
 
Technical improvements. Reasons. Methods. Estimations. CJ
Technical improvements.  Reasons. Methods. Estimations. CJTechnical improvements.  Reasons. Methods. Estimations. CJ
Technical improvements. Reasons. Methods. Estimations. CJpolinaucc
 
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...jackiepotts6
 
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...MyFAA
 
Unlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsUnlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsconfluent
 
8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.Ritesh Kanjee
 
User Experience Designer | Kaylee Miller Resume
User Experience Designer | Kaylee Miller ResumeUser Experience Designer | Kaylee Miller Resume
User Experience Designer | Kaylee Miller ResumeKaylee Miller
 

Último (20)

20140812 - OBD2 Solution
20140812 - OBD2 Solution20140812 - OBD2 Solution
20140812 - OBD2 Solution
 
Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...
Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...
Splashtop Enterprise Brochure - Remote Computer Access and Remote Support Sof...
 
Boost Efficiency: Sabre API Integration Made Easy
Boost Efficiency: Sabre API Integration Made EasyBoost Efficiency: Sabre API Integration Made Easy
Boost Efficiency: Sabre API Integration Made Easy
 
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptxCYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
CYBER SECURITY AND CYBER CRIME COMPLETE GUIDE.pLptx
 
BusinessGPT - SECURITY AND GOVERNANCE FOR GENERATIVE AI.pptx
BusinessGPT  - SECURITY AND GOVERNANCE  FOR GENERATIVE AI.pptxBusinessGPT  - SECURITY AND GOVERNANCE  FOR GENERATIVE AI.pptx
BusinessGPT - SECURITY AND GOVERNANCE FOR GENERATIVE AI.pptx
 
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young EntrepreneurMinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
MinionLabs_Mr. Gokul Srinivas_Young Entrepreneur
 
Revolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM GridRevolutionize Your Field Service Management with FSM Grid
Revolutionize Your Field Service Management with FSM Grid
 
Steps to Successfully Hire Ionic Developers
Steps to Successfully Hire Ionic DevelopersSteps to Successfully Hire Ionic Developers
Steps to Successfully Hire Ionic Developers
 
Einstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdfEinstein Copilot Conversational AI for your CRM.pdf
Einstein Copilot Conversational AI for your CRM.pdf
 
Large Scale Architecture -- The Unreasonable Effectiveness of Simplicity
Large Scale Architecture -- The Unreasonable Effectiveness of SimplicityLarge Scale Architecture -- The Unreasonable Effectiveness of Simplicity
Large Scale Architecture -- The Unreasonable Effectiveness of Simplicity
 
Enterprise Content Managements Solutions
Enterprise Content Managements SolutionsEnterprise Content Managements Solutions
Enterprise Content Managements Solutions
 
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdfFlutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
Flutter the Future of Mobile App Development - 5 Crucial Reasons.pdf
 
Mobile App Development company Houston
Mobile  App  Development  company HoustonMobile  App  Development  company Houston
Mobile App Development company Houston
 
VuNet software organisation powerpoint deck
VuNet software organisation powerpoint deckVuNet software organisation powerpoint deck
VuNet software organisation powerpoint deck
 
Technical improvements. Reasons. Methods. Estimations. CJ
Technical improvements.  Reasons. Methods. Estimations. CJTechnical improvements.  Reasons. Methods. Estimations. CJ
Technical improvements. Reasons. Methods. Estimations. CJ
 
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
03.2024_North America VMUG Optimizing RevOps using the power of ChatGPT in Ma...
 
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
Take Advantage of Mx Tracking Flight Scheduling Solutions to Streamline Your ...
 
Unlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insightsUnlocking the Power of IoT: A comprehensive approach to real-time insights
Unlocking the Power of IoT: A comprehensive approach to real-time insights
 
8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.8 Steps to Build a LangChain RAG Chatbot.
8 Steps to Build a LangChain RAG Chatbot.
 
User Experience Designer | Kaylee Miller Resume
User Experience Designer | Kaylee Miller ResumeUser Experience Designer | Kaylee Miller Resume
User Experience Designer | Kaylee Miller Resume
 

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…
  • 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://www.oreillynet.com/onlamp/blog/2004/08/say_no_by_default.html  
  • 9. hNp://www.emilianosoldipmp.info/wp-­‐‑content/uploads/2012/08/Stacey.png   That’s  the   problem  we   need  to  solve! And  these  are   the  methods   we  are  using!!!
  • 11. 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.
  • 12. Feedback  Loops  in  Traditional  Techniques   vs.  Agile  Techniques
  • 13. Waterfall  vs.  Agile:  Risk  vs.  Value  Delivered hNp://www.testingthefuture.net/wp-­‐‑content/uploads/2011/12/waterfall_versus_agile_development.png  
  • 15. 5  Levels  of  Agile  Planning
  • 16. 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
  • 17. 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
  • 18. Product  Management  Artifacts Initiatives   Epics Themes Sprint  Backlog Product  Backlog Product  Roadmap Product  Vision Tasks… Stories Scenarios
  • 19. Product  Vision Shared  by  All Desirable  and  Inspirational Clear  and  Tangible Broad  and  Engaging Short  and  Sweet
  • 20. 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://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html  
  • 21. Product  Vision  Box v As  the  name   suggests… v Describes   the  top  2-­‐‑3   features  of   product
  • 22. Press  Release v Amazon’s   “working   backwards” v Write  the   launch  press   release!
  • 24. 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
  • 25. 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.
  • 28. Product  Roadmap hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/   hNp://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png   •  High-­‐‑level  plan   that  describes  how   the  product  will   evolve •  Refers  to •  Product  version •  Functionality •  Release  date  
  • 29. 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://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  • 31. 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
  • 32. 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://www.mountaingoatsoftware.com/ scrum/product-­‐‑backlog  
  • 33. ….should  be  “DEEP” • Detailed  Appropriately D: • Estimated E: • Emergent E: • Prioritized P:
  • 37. Many  Projects,  One  Team hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
  • 38. One  Project,  Many  Teams hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
  • 39. Many  Projects,  Many  Teams hNp://blog.assembla.com/AssemblaBlog/tabid/12618/Default.aspx?Tag=workflow  
  • 40. From  Product  Roadmap  to  Product  Backlog hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  • 41. Who  owns  Product  Backlog? hNp://www.romanpichler.com/blog/agile-­‐‑product-­‐‑management-­‐‑tools/agile-­‐‑product-­‐‑roadmap/  
  • 42. Sprint  Backlog v User  Stories   selected  by  the   Team v Will  be  built  in   current  Sprint v Fully  Estimated v Divided  into   Tasks
  • 43. 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://cf.agilealliance.org/articles/system/article/file/970/file.pdf  
  • 44. Backlog  Grooming v Upto  10%   of  sprint   time v Creating  or   refining   new  PBIs v Estimating   PBIs v Prioritizing   PBIs
  • 48. Feature  planning  in  Fixed  #Sprints
  • 49. User  Story I as a <Role> want <Feature> so that <Value>
  • 50. 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
  • 51. 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://guide.agilealliance.org/guide/invest.html  
  • 52. Acceptance  Criteria 52 Given <System State> when <an event occurs> then <an outcome happens>
  • 53. Performance  Constraint  -­‐‑>  Acceptance  Criteria
  • 54. “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”
  • 55. 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://www.mountaingoatsoftware.com/blog/stories-­‐‑epics-­‐‑and-­‐‑themes  
  • 58. 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://www.mountaingoatsoftware.com/blog/stories-­‐‑epics-­‐‑and-­‐‑themes  
  • 59. Themes  change/evolve… Scrum  Product  Ownership  –  Bob  Galen
  • 62. 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.      
  • 63. 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://www.cloudforestdesign.com/2011/04/25/introduction-­‐‑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.  
  • 65. ©  Jeff  Pa(on,  all  rights  reserved,  www.AgileProductDesign.com   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
  • 69. 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
  • 75. “There  can  only  be  one” hNp://www.romanpichler.com/blog/roles/the-­‐‑single-­‐‑product-­‐‑owner/  
  • 79. 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://www.scrumalliance.org/why-­‐‑scrum/core-­‐‑scrum-­‐‑values-­‐‑
  • 81. 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
  • 82. 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
  • 83. 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
  • 85. 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
  • 86. 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
  • 87. 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://agile.dzone.com/articles/product-­‐‑ownership-­‐‑practice  
  • 88. 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://www.scrumalliance.org/community/articles/2010/april/common-­‐‑product-­‐‑owner-­‐‑traps  
  • 89. 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
  • 90. Agile  Product  Ownership  in  a  Nutshell hNp://youtu.be/502ILHjX9EE