O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

How to Create a Product Management Process That Doesn't Suck

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 101 Anúncio

How to Create a Product Management Process That Doesn't Suck

Baixar para ler offline

Learn how to create a product management process that works effectively for your organization. Slides taken from a class that Cory von Wallenstein of Dyn taught at Intelligent.ly. Learn more from the experts by visiting http://intelligent.ly/learn

Learn how to create a product management process that works effectively for your organization. Slides taken from a class that Cory von Wallenstein of Dyn taught at Intelligent.ly. Learn more from the experts by visiting http://intelligent.ly/learn

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a How to Create a Product Management Process That Doesn't Suck (20)

Anúncio

Mais de Intelligent_ly (20)

Mais recentes (20)

Anúncio

How to Create a Product Management Process That Doesn't Suck

  1. 1. presents CORY VON WALLENSTEIN Chief Technology Officer, Dyn Inc. @cvonwallenstein Tools of the Trade: Creating a Product Process that Doesn’t Suck
  2. 2. “Truly  Superior,  Differen1ated”  Products  had  an   average  98%  success  rate  and  53.5%  market  share. “Me-­‐Too”  Products  averaged  an  18.4%  success  rate   and  11.6%  market  share.   Product  Leadership:  Crea2ng  and  Launching  Superior  New  Products  –  Robert  G.  Cooper Photo  Credit:  h2p://www.flickr.com/photos/idletype/526824467/
  3. 3. Agenda 1. Product  Litmus  Test  –  Is  this  working? 2. Product  vs  Project  Management  –  Role  in  org 3. Deep  dive! 1. Product  management  top  to  boFom 2. Teams  driving  toward  success 3. Keeping  the  company  in  the  loop
  4. 4. But  First,  Who  Is  Dyn? • 170  Global  Employees • Headquarters  in  Manchester,  NH • Offices  in  San  Francisco  and  Brighton,  UK • Raised  first  financing  in  Oct  2012:  $38MM  from  NorthBridge
  5. 5. Product  Litmus  Test Is  this  working?
  6. 6. hZp://www.flickr.com/photos/alshepmcr/4859805312/
  7. 7. Is  what  we’re  doing  now  working? • Is  there  a  palpable  divide? – When  will  X  be  done? – What’s  blocking  X? • Is  it  a  bug  or  a  firewall  config  or  logo  or  contract? – When  can  we  start  Y? – What’s  the  priority  in  the  grand  scheme  of  things? – Is  Kari  available  to  help  with  something  next  week? – When  can  we  safely  switch  gears? – What  defines  80%  complete?
  8. 8. Manifesto  for  Agile  So<ware Individuals  and  interac1ons  over  processes  and  tools Working  so<ware  over  comprehensive  documentaJon Customer  collabora1on  over  contract  negoJaJon Responding  to  change  over  following  a  plan That  is,  while  there  is  value  in  the  items  on the  right,  we  value  the  items  on  the  le<  more. hZp://agilemanifesto.org
  9. 9. Product  vs  Project  Management What  is  the  role  of  Product   Management  in  the  org?
  10. 10. What  is  Product  Management? • Read  a  great  overview  presentaJon
  11. 11. What  is  Product  Management? • At  Dyn  Inc.,  largely  concerned  with  what  features   and  improvements  go  into  the  products  in  what   order. • Ideas  for  features  and  improvements  come  from   everywhere – Prospects,  customers,  internal  teams,  etc. • Collaboradve  process  with  execs  and  directors  to   set  priorides  for  what  to  take  on,  and  when • Funcdonal  specificadons  for  what  is  to  be  built
  12. 12. What  is  Project  Management? • At  Dyn  Inc.,  largely  concerned  with   coordinaJon  of  resources  to  efficiently  execute   on  the  plans  set  forth  by  product   management. • CollaboraJve  process  between  directors  and   managers  to  set  schedules,  remove  roadblocks   and  communicate  progress. • Most  important:  Deliver  value  constantly.
  13. 13. Few  Quick  DefiniJons • Sprint – Easy  definiJon:  Up  to  two  weeks  of  work.  You’ll   hear  it  used  as  “current  sprint”  and  “next  sprint”. – Complete  definiJon:  One  or  two  weeks  on  the   calendar  (defined  by  directors/managers),  such   that  all  work  assigned  to  the  sprint  will  be   complete  by  the  end  of  the  sprint.  Well  defined   points  to  flexibly  change  focus  before  or  a`er  a   sprint.
  14. 14. Few  Quick  DefiniJons • Story:  A  business  focused  descripJon  of  new   or  changed  funcJonality  that  can  be  done  in   one  sprint.  To  be  divided  into  technical  and   business  tasks. hZp://www.slideshare.net/rwirdemann/user-­‐stories-­‐for-­‐your-­‐product-­‐backlog
  15. 15. Few  Quick  DefiniJons • Epic:  A  collecJon  of  stories  that  span  sprints. • Technical  task:  Technical  work  required  to   bring  a  story  to  fruiJon.  Design  architecture,   write  code,  create  mockup,  code  review,  etc. • Business  task:  Non-­‐technical  work  required  to   bring  a  story  to  fruiJon.  Define  objecJves/ goals/measurables,  write  specificaJon,  create   graphics  and  content,  blog  entries,  etc.
  16. 16. Few  Quick  DefiniJons • Bug:  Broken  funcJonality  that  needs  to  be   corrected.  Bugs  do  not  describe  new   funcJonality,  only  exisJng  funcJonality  that  no   longer  works. • Feature  Request:  New  funcJonality. • Improvement  Request:  ExisJng  funcJonality   that  works  as  designed,  but  could  work  beFer.
  17. 17. Deep  Dive! Let’s  see  this  process  and  tools  in   acJon!
  18. 18. How  does  it  come  together? Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted  by  priority • We  track  who  asks  for  what,  and  how  frequently • Execs,  VPs  &  directors  keep  three  sorted  priority  lists  by  category:  DNS,  Email  &  Internal • We  conGnuously  add  new  requests,  and  we  review  prioriGes  minimum  of  2x  per  week. Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,  sorted  by  priority. • The  top  priority  requests  get  evaluated  in  detail,  with  a  target  pace  of  1-­‐2  per  week • VPs  use  a  product  lifecycle  process  to  figure  out  what’s  needed  to  implement  the  request,  directors  write   specificaGons  (e.g.,  epics  and  stories),  and  get  ready  for  teams  to  execute. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and  schedule  efforts. • Managers  work  in  two  week  sprints,  each  culminaGng  in  at  least  some  value  delivered  to  someone. • On  release  of  large  efforts  (e.g.,  epics),  VPs  &  directors  coordinate  the  launch  using  a  product  lifecycle   process  again.
  19. 19. Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted   by  priority Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,   sorted  by  priority. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and   schedule  efforts. • What  Does  Product  Planning   Mean? 1.  Get  the  ideas
  20. 20. Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted   by  priority Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,   sorted  by  priority. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and   schedule  efforts. • What  Does  Product  Planning   Mean? Kicka 1.  Get  the  ideas 2.  Priori0ze  the  ideas,  driven  by  opportunity,  pain,  number  of  customers.  
  21. 21. Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted   by  priority Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,   sorted  by  priority. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and   schedule  efforts. • What  Does  Product  Planning   Mean? Kicka 1.  Get  the  ideas 2.  Priori0ze  the  ideas,  driven  by  opportunity,  pain,  number  of  customers.   3.  At  a  high  level,  what  needs  to  be  done?  That’s  the  func0onal   specifica0on.
  22. 22. Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted   by  priority Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,   sorted  by  priority. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and   schedule  efforts. • What  Does  Product  Planning   Mean? Kicka 1.  Get  the  ideas 2.  Priori0ze  the  ideas,  driven  by  opportunity,  pain,  number  of  customers.   3.  At  a  high  level,  what  needs  to  be  done?  That’s  the  func0onal   specifica0on. 4.  What  are  the  tasks  that  bring  this  idea  to  life?  Where  do  they  fit  in  the schedule?  What  non-­‐technical  tasks  are  required  to  make  it  successful?
  23. 23. What  Does  Product  Planning  Mean? 1. Get  the  ideas 2. PrioriJze  the  ideas 3. Specify  the  funcJonality  for  the  idea 4. IdenJfy  the  tasks  required  to  bring  the  idea  to   life,  and  schedule  the  tasks  for  teams  to  work   on.
  24. 24. 1.  Get  the  Ideas   • Primarily  in  the  form  of  feature  requests  and   improvement  requests  that  come  from  the   dashboard • Click  “Feature  Request”  or  “Improvement   Request”  for  DNS,  Email  or  Internal.
  25. 25. Examples  of  Feature  Requests Customer  Idea  for  New  Funcdonality • Example  request:
  26. 26. Examples  of  Feature  Requests Customer  Idea  for  Improvement • Example  request:
  27. 27. Examples  of  Other  Feature   Requests • Could  be  an  improvement  to  a  UI  or  workflow – Include  screenshots  that  show  where  the  confusion  or  pain  is,  or  under   what  circumstances  the  pain  is  introduced • Could  be  a  change  to  how  a  service  works – For  example,  on  failover  of  a  hostname,  provide  just  the  failover  IP  for   the  purpose  of  secondary  DNS  providers  to  consume. • Could  be  an  internal  improvement  request – For  example,  connect  our  Salesforce.com  account  to  other  systems – Speed  up  a  tool  that  is  slow
  28. 28. 2.  PrioriJze  the  Ideas   • ConJnue  to  add  addiJonal  support  for  ideas  as   new  customers  request  the  same  features  or   improvements • Comment  on  ideas  to  add  support   • Vote  on  ideas • Directors  and  execuJves:  Adjust  the  prioriJes   of  the  ideas
  29. 29. Add  addiJonal  support • Has  another  customer  requested  a  feature   that  we’re  already  tracking?  Add  them! • Add  another  row  to  the  table  in  the  descripJon
  30. 30. Comment  on  ideas • Add  your  insights,  addiJonal  customers  to  look   at,  and  other  ideas  that  can  help  decide  where   this  should  sit  in  the  priority  stack.
  31. 31. Vote  on  ideas • VoJng  is  another  way  to  register  your  support,   parJcularly  for  internal  feature  and   improvements  that  make  our  lives  easier.
  32. 32. PrioriJzaJon  in  AcJon • VPs,  execs  &  directors  review  and  adjust   prioriJes  3x  per  week. • Be  sure  to  leave  a  comment  as  to  WHY  you   changed  the  priority! • Priority  adjustments  appear  in  the  history  of   the  issue  for  who  changed  what  and  when,   and  will  alert  via  an  email  noJficaJon  to   watchers.
  33. 33. PrioriJzaJon  in  AcJon Changing  rank  logs  the  change  and  sends  a  no0fica0on Be  sure  to  comment  WHY  you  made  the  change,  especially  if  bumping  to  at  or  near  the  top.
  34. 34. Feature  Requests • From  prospects,  customers,  internal  teams,  etc.,  all  the  ideas  we  may  do,  sorted   by  priority Product  Backlog • Feature  requests  are  work  we  may  do;  the  product  backlog  is  work  we  will  do,   sorted  by  priority. Sprints  and  Releases • Directors  and  managers  define  the  work  described  by  stories  into  actual  tasks,  and   schedule  efforts. • Requests  in  a  Queue  vs  Stories  in  a   Backlog Kicka The  JIRA  issue  types  of  “Feature  Request”  and  “Improvement  Request”  represent  the   never  ending  “wishlist”.  Ideally  it’s  a  mess,  because  it’s  everything,  and  we  have  yet  to   sort  through  which  requests  we’re  taking  on  and  which  we  are  not. The  JIRA  issue  types  of  “Story”,  “Bug”,  “Epic”  and  the  sub-­‐tasks  represent  work  we   have  definitely  agreed  to  take  on,  scope  out,  and  deliver.  It’s  just  a  maer  of   scheduling.  This  is  the  backlog!  It’s  ideally  clean,  because  it’s  stuff  we  have  agreed  to   take  on.  The  “Request”  issues  link  to  the  associated  backlog  issues  in  JIRA.
  35. 35. 3.  FuncJonal  specificaJons 4.  IdenJfy  tasks,  assign  &  schedule • We’ll  cover  these  in  detail  in  the  final  secJon   of  the  training  on  “Teams  driving  toward   success”  and  day-­‐to-­‐day  JIRA  usage.
  36. 36. Teams  Driving  Toward  Success • WriJng  really  useful: – Bug  reports,  stories  and  epics – Technical  and  business  subtasks – FuncJonal  and  technical  specificaJons • Workflows  for  issues  and  transiJons • Scheduling  sprints,  due  dates  and  releases • Keeping  your  plans  accurate  to  reality • CreaJng  and  using  dashboards  to  stay  in  the  loop
  37. 37. WriJng  Useful  Bug  Reports • Bug:  Broken  funcJonality  that  needs  to  be   corrected.  Bugs  do  not  describe  new   funcJonality,  only  exisJng  funcJonality  that  no   longer  works.
  38. 38. WriJng  Useful  Bug  Reports • Use  the  summary  to  describe  what  is  broken   and  the  impact  in  plain  English. • Good  examples: – Users  from  Canada  cannot  checkout  their  cart   because  they  are  marked  as  fraudulent  purchases. – Zone  changes  larger  than  50  resource  records  in   size  fail  to  publish. – Leaving  TTL  text  field  blank  throws  HTTP  500  to   user.
  39. 39. WriJng  Useful  Bug  Reports • Use  the  summary  to  describe  what  is  broken   and  the  impact  in  plain  English. • Bad  examples: – Checkout  error – Line  50  of  checkZone.pl  is  wrong – Internal  Server  Error  500
  40. 40. WriJng  Useful  Bug  Reports • In  the  descripJon,  include  steps  necessary  to   reproduce  the  bug. • AFach  a  screenshot  or  otherwise  capture  the   “evidence”  that  the  bug  exists,  and  place  in  the   descripJon.
  41. 41. Few  Quick  DefiniJons • Story:  A  business  focused  descripJon  of  new   or  changed  funcJonality  that  can  be  done  in   one  sprint.  To  be  divided  into  technical  and   business  tasks.
  42. 42. WriJng  Useful  Stories • Why  bother  with  the  whole  story  thing? – Convey  what’s  going  on  in  terms  anyone  can   understand. – Force  us  to  think  about  taking  on  work  in  small   chunks,  so  we  can  conJnuously  deliver  value  and   be  nimble  to  changing  course  if  necessary.  Stories   cannot  span  sprints. – Define  what  value  is  geong  delivered  for  whom  to   set  clear  expectaJons  on  what  “done”  means.
  43. 43. WriJng  Useful  Stories • Think  about  the  end  result  you’re  trying  to   achieve,  and  try  to  aFack  it  in  ways  that  will   ensure  you’re  delivering  some  value  to  some   user  at  least  every  sprint,  even  if  that  user  is   yourself  as  a  developer. • Follow  the  template: – As  a  [user  role],  I  want  some  [goal]  so  that  [reason].
  44. 44. WriJng  Useful  Stories • As  large  efforts  progress,  you’ll  start  to  see  the   value  shi`  from  internal  to  external  user  roles. – First  sprint:  As  a  developer…;  As  a  tester…; – Second  sprint:  As  a  system  administrator…; – Third  sprint:  As  an  internal  alpha  user…; – Fourth  sprint:  As  a  closed  beta  user…; – Fi`h  sprint:  As  a  customer…; – Sixth  sprint:  As  a  customer…; – Seventh  sprint:  As  a  customer…;
  45. 45. WriJng  Useful  Stories • If  the  story  implements  a  Feature  Request  or  Improvement  Request,   link  it! • More  Acdons  -­‐>  Link,  then  search  for  the  issue • Use  “implements”  going  from  Story  to  Feature/Improvement   request.  Automadcally  creates  reverse  link  of  “is  implemented  by”.
  46. 46. WriJng  Useful  Stories • The  descripJon  of  the  story  contains  any   necessary  implementaJon  details  and   technical  specificaJon,  like  mockups,   architecture  diagrams,  state  diagrams,  etc. • Include  pictures,  create  Gliffy  diagrams,  link  to   documents  in  Confluence. • We’ll  explore  breaking  the  story  down  into   tasks  a`er  we  look  at  epics  real  quick…
  47. 47. WriJng  Useful  Epics • Epic:  A  collecJon  of  stories  that  span  sprints. • Only  needed  if  it  truly  spans  sprints.
  48. 48. WriJng  Useful  Epics   • Summary  describes  the  effort – High  availability  for  portal  and  API – Geo  Traffic  Management • DescripJon  contains  the  project-­‐wide  technical   specificaJon – Remember,  the  funcJonal  specificaJon  is  tracked  on   the  Feature  Request  or  Improvement  Request. – Large  efforts  have  tech  specs  on  epics;  small,  less   than  two  week  efforts  have  tech  specs  on  story
  49. 49. WriJng  Useful  Epics • On  your  stories,  be  sure  to  set  the  Epic.  It  has   to  be  explicitly  set  on  each  Story.  Can  be  bulk   changed.
  50. 50. WriJng  Useful  Sub-­‐tasks   • Sub-­‐tasks  are  where  we  define  the  actual  work  that   needs  to  be  done,  by  whom,  and  by  when. • Free  to  use  summary  and  descripJon  as  necessary  to   convey  task  requirements. • OK  to  group  smaller  tasks  in  the  descripJon  of  a  sub-­‐ task  as  a  bulleted  or  numeric  list  (e.g.,  ten  things  that   each  take  5  minutes…) • Technical  (write  code,  install  package)  and  business   (create  logo,  sign  contract)  sub-­‐task  types.
  51. 51. WriJng  Useful  Sub-­‐tasks • Most  important:  TIME  ESTIMATES! • Used  for  the  burndown  charts,  that  convey  to   the  rest  of  Dyn  Inc.  when  an  effort  is  expected   to  be  completed.
  52. 52. WriJng  Useful  Technical  Sub-­‐tasks
  53. 53. WriJng  Useful  Business  Sub-­‐tasks   • Logos,  contracts,  feedback,  approvals,  etc.
  54. 54. WriJng  Useful  FuncJonal  Specs • What  does  the  implemented  idea  look  like?   What  are  the  requirements?  How  do  you   define  it’s  done  and  it’s  successful? • Describe  with  user  stories,  workflow  diagrams,   and  interface  mockups • Leave  no  quesJon  unanswerable.
  55. 55. WriJng  Useful  Technical  Specs • How  are  we  going  to  implement  the  funcJonal   specificaJons? • System  architecture,  state  diagrams,  pseudo-­‐ code  as  needed  to  convey  how  to  implement. • If  the  funcJonal  specificaJons  live  on  (or  are   linked  from)  the  Feature  or  Improvement   request,  the  technical  specificaJons  live  on  (or   are  linked  from)  the  highest  level  Epic  or  Story   for  the  effort.
  56. 56. Workflows  for  Issues   • Open  or  Re-­‐opened  -­‐>  In  Progress  -­‐>  In  QA  -­‐>  Closed • What  does  Open  mean? – Queued  up  for  an  individual  to  work  on  according  to   priority  stack. • What  does  Re-­‐opened  mean? – It  previously  went  through  at  least  up  to  In  QA  or   Closed,  and  needs  more  aFenJon  that’s  not  being   given  right  this  moment  (otherwise,  would  have   gone  back  to  In  Progress).
  57. 57. Workflows  for  Issues   • Open  or  Re-­‐opened  -­‐>  In  Progress  -­‐>  In  QA  -­‐>  Closed • What  does  In  Progress  mean? – You’re  working  on  it  today.  OK  to  have  more  than  one  In   Progress  if  you’re  working  on  more  than  one  thing  in  a  day.   Not  OK  to  leave  it  In  Progress  if  you’re  not  working  on  it   today. • What  does  In  QA  mean? – Ready  for  peer  review.  TransiJon  to  In  QA  and   assign  to  a  peer  who  will  review  the  funcJonality.   EVERY  issue  gets  peer  reviewed.
  58. 58. Workflows  for  Issues   • Open  or  Re-­‐opened  -­‐>  In  Progress  -­‐>  In  QA  -­‐>  Closed • What  does  Closed  mean? – If  In  QA  failed  (e.g.,  more  work  or  changes   required),  goes  back  to  original  assignee  and  either   Re-­‐opened  to  work  on  later  or  In  Progress  if   they’re  going  to  jump  on  it  now. – If  it  passes  peer  review,  can  be  Closed,  which   signals  that  it’s  ready  for  the  next  release.
  59. 59. Scheduling  Sprints,  Due  Dates  and  Releases • Really  only  two  contexts  to  use  the  term   “sprint”: – The  current  sprint:  Defined  value  that  the  teams  are   commiFed  to  delivering  in  two  weeks  or  less  on  the   calendar.  Working  on  it  now. – The  next  sprint:  Defined  value  that  the  teams  are   commiFed  to  delivering  in  two  weeks  or  less  on  the   calendar…  as  soon  as  the  current  sprint  is  delivered. • Anything  beyond  “the  next  sprint”  is  prioriJzed   in  the  backlog.  That’s  it.
  60. 60. Scheduling  Sprints,  Due  Dates  and  Releases • OK,  we  have  our  sprint  scheduled,  what  about   release? – A  version  in  JIRA  is  a  release  to  producJon.  When   you  know  you’re  going  to  take  advantage  of  a  code   release  day  to  release  code,  create  the  appropriate   version  in  your  project  with  the  “release  date”  set   to  your  release  day. – Set  the  “fixversion”  on  your  issues  to  indicate  what   will  go  live  in  the  version.  These  will  later  become   your  release  notes.
  61. 61. Scheduling  Sprints,  Due  Dates  and  Releases • We  missed  the  due  date!  We’re  late!  OH  NOZ! – Not  to  worry,  these  things  will  happen.   – What’s  important  is  to  communicate  to  the  team: 1. That  it  happened.  Don’t  sweep  it  under  the  rug. 2. Why  it  happened,  so  you  can  think  about  what  to  keep   in  mind  for  next  Jme. 3. What  the  new  plan  is…  adjust  your  fix  versions,  due   dates,  and  other  planning  as  needed.  Comment  on  the   issues!   • There  are  lots  of  perfectly  valid  reasons  why  plans  may   change,  but  there  is  no  excuse  for  ignoring  the  change.
  62. 62. Keeping  your  plans  accurate  to  reality • Here  we’ll  cover: – Due  date  maintenance,  or  “we’re  clearly  not  going   to  get  all  of  this  done  for  release  day” – Burndown  charts,  or  “when  is  project  X  going  to  be   done?” – Time  tracking  with  SVN,  or  “keeping  our  burndown   charts  up  to  date  with  minimum  effort”
  63. 63. Due  Date  Maintenance   • When  changing  dates  on  a  fixversion,  all  issues   assigned  to  that  fix  version  must  be  changed  as   well – Create  issue  filter  with  fixversion  of  ‘x.x.x’ – Apply  bulk  change  to  all  issues  matching  filter – Leave  comment  as  to  why  change  was  required
  64. 64. Due  Date  Maintenance   • When  changing  dates  on  a  fixversion,  all  issues   assigned  to  that  fix  version  must  be  changed  as   well – Create  issue  filter  with  fixversion  of  ‘x.x.x’ – Apply  bulk  change  to  all  issues  matching  filter – Leave  comment  as  to  why  change  was  required
  65. 65. Burndown  Charts • Burndown  charts  require  start  and  end  date  be   set  in  Chart  tool – Create  a  filter  based  on  FixVersion – Add  Burndown  chart  to  dashboard – Set  start  and  end  date  on  info  tab  
  66. 66. Burndown  Charts • Burndown  charts  require  start  and  end  date  be   set  in  Chart  tool – Create  a  filter  based  on  FixVersion – Add  Burndown  chart  to  dashboard – Set  start  and  end  date  on  info  tab  
  67. 67. Time  Tracking  with  SVN • Use  the  #  when  checking  in  to  record  Jme  and   comments  svn  commit  -­‐m  "ECTE-­‐862  Created  basic  interac0on  #0me  2h”8asic  in #resolve  and  #close  work  too
  68. 68. Puong  It  All  Together A  Dashboard  in  Confluence  that  the   whole  company  can  read.
  69. 69. Kickass Products  at  Dyn  Inc! Feature   Requests Product   Backlog 3-­‐5  High  Profile   Projects  at  Dyn Sprints  and   Releases Each  pordon  of  the  process  has  a   corresponding  pordon  of  the   dashboard: 1. The  high  profile  projects  are  at  top   for  easy  reference • This  is  what  most  folks  will  be   interested  in…  when  is  X  going   to  be  done? • Not  part  of  the  “flow”,  just  a   handy  reference  secdon. 2. Feature  requests  for  DNS,  Email   and  Internal  in  sorted  priority. 3. Next  is  the  product  backlog  in   sorted  priority  by  team. 4. Followed  by  the  current  sprint,   with  work  grouped  by  team.
  70. 70. High  Profile  Projects Let’s  look  at  the  first  secJon  in  detail:  the   High  Profile  Projects. The  goal  of  this  secdon  is  give  you  a  quick  pulse  on   the  top  3-­‐5  efforts  at  Dyn  that  everyone  cares   about.  You’ll  see  whether  or  not  the  effort  is   acdvely  being  worked  on,  and  when  it’s  expected  to   be  complete. Have  it  open?  Good!
  71. 71. High  Profile  Projects • Three  porJons  to  pay  aFenJon  to: – Switching  between  the  3-­‐5  high  profile  projects – The  project  card,  which  gives  an  overview  of  the   effort,  and  links  to  the  associated  informaJon  in   JIRA  if  you’d  like  to  dive  into  the  details. – The  burndown  chart,  which  plots  calendar  days  on   the  X-­‐axis  and  hours  remaining  on  the  Y-­‐axis.   When  hours  remaining  reaches  zero,  the  project  is   complete!
  72. 72. High  Profile  Projects Switch  between  projects  by  clicking  the  tabs.  What  projects  are  shown  are  determined   by  CvW,  so  send  a  request  if  what  you  seek  isn’t  shown.
  73. 73. High  Profile  Projects The  card  view  shows  the  parent  issue  in  JIRA  (likely  a  Story  or  Epic,  here  it’s  a  Story),  with   a  summary  of  the  effort,  what  version  it  will  release  in,  and  the  assignee  who  is  the   person  that  is  most  familiar  with  the  effort.
  74. 74. High  Profile  Projects The  burndown  chart  shows  you  in  real-­‐0me  when  this  project  is  likely  to  complete.  The   red  line  is  a  guideline  predic0ng  comple0on,  and  the  green  line  is  work  remaining.  When   work  remaining  reaches  0,  the  project  is  done.  Read  more  about  burndown  charts.
  75. 75. Feature  Requests Let’s  look  at  the  second  secJon  in  detail:   Feature  Requests. The  goal  of  this  secdon  is  show  the  ideas  we  may   want  to  work  on,  in  sorted  priority.  Each  week,   teams  take  the  top  1-­‐2  feature  requests  and  spend   dme  figuring  out  what  it  would  take  to  implement   them  in  the  form  of  a  funcdonal  specificadon.    This   specificadon  gets  translated  into  stories,  which  will   appear  in  the  backlog. Have  it  open?  Good!
  76. 76. Feature  Requests • Few  porJons  to  pay  aFenJon  to: – Categories  of  requests:  DNS,  Email  and  Internal – InterpreJng  the  status  of  a  request – Sorted  prioriJes,  and  how  to  change  them – Going  beyond  the  top  10  prioriJes – Diving  in  to  a  feature  requests – CreaJng  new  feature  requests  vs  improvement   requests
  77. 77. Feature  Requests Three  sec0ons,  lea  to  right:  DNS,  Email  and  Internal.  DNS  includes  all  DNS  products  and   services,  Email  includes  all  Email  products  and  services,  Internal  includes  everything  we   rely  on  internally  (Salesforce,  Phones,  Zimbra,  RT,  Billing  Portals,  etc.).
  78. 78. Feature  Requests Let’s  zoom  in  on  DNS.  Everything  we  look  at  from  here  on  is  equally  applicable  to  DNS,   Email  and  Internal,  we’re  just  using  DNS  as  an  example.
  79. 79. Feature  Requests Four  pieces  of  informa0on  are  shown.  The  first  is  implicit,  and  it’s  the  priority  of  the   request  gauged  by  the  posi0on  in  the  list  (top  issue  is  the  top  priority).  The  second   through  fourth  are  in  columns:  “Component”  is  the  product  or  service  (e.g.,  DynECT   Managed  DNS,  Dyn  Standard  DNS),  “Summary”  is  the  idea,  and  “Status”  is…  status.
  80. 80. Feature  Requests If  the  status  is  “Open”,  it  means  no  one  is  looking  at  the  feature  request  at  the  moment.  If   the  status  is  “In  Progress”,  it’s  likely  in  ac0ve  implementa0on  by  teams.  If  it’s  anything   else  (e.g.,  Sales  Review,  Legal  Review,  etc.),  the  request  is  running  through  the  “Product   Lifecycle  Process”  used  by  the  director  team  to  evaluate  and  spec  out  requests.
  81. 81. Feature  Requests “In  Progress”  requests  generally  have  their  work  defined  already  in  the  form  of  a   func0onal  specifica0on  and  stories  on  the  current  sprint  or  the  product  backlog.  Each   team  has  a  prac0cal  limit  for  the  number  of  requests  “In  Progress”;  as  each  effort  wraps   up,  the  next  highest  priority  request  is  taken  on.
  82. 82. Feature  Requests Three  0mes  a  week,  directors  and  execu0ves  review  and  adjust  the  priori0es  of  requests   using  the  “Priori0ze”  link.  We’ll  discuss  priori0za0on  later  on,  but  for  the  moment,  it’s   worth  no0ng  that  unless  you’re  in  a  priori0za0on  mee0ng,  you  shouldn’t  change  anything   here.
  83. 83. Feature  Requests Only  the  top  10  priority  feature  requests  are  shown  on  each  gadget.  To  see  lower  priority   requests,  click  the  link  at  the  bojom  that  says  “N  matching  issues”.  This  will  take  you  into   JIRA,  where  you  can  explore  all  feature  requests.
  84. 84. Feature  Requests Clicking  a  summary  will  take  you  to  the  feature  request  in  JIRA,  where  you  can  comment   on  the  request,  watch  the  request  to  be  emailed  about  changes,  vote  on  the  issue  and   more.
  85. 85. Feature  Requests Want  to  request  an  improvement  to  something  we  already  have?  Click  “Improvement   Request”.  Want  to  request  new  func0onality  that  we  do  not  already  have?  That’s  a   “Feature  Request”,  so  click  “Feature  Request”. The  links  take  you  into  JIRA  with  the  screen  promp0ng  what’s  required.  Let’s  look  at  this   in  more  detail.
  86. 86. Feature  Requests Crea0ng  a  request  takes  you  to  JIRA,  and  requires  you  to  specify  a  summary,  a  component   (select  drop  down  for  op0ons,  they’re  the  products,  and  you  can  specify  more  than  one!),   assignee  (leave  as  “automa0c”),  reporter  (yourself,  search  by  name).
  87. 87. Product  Backlog Let’s  look  at  the  third  secJon  in  detail:   Product  Backlog. The  goal  of  this  secdon  is  to  see  what  work  is   queued  up  to  work  on  next,  defined  in  a  format   anyone  can  understand:  stories  define  what  value   is  gerng  to  what  person  for  what  reason,  and  bugs   define  funcdonality  that  use  to  work  but  currently   does  not. Have  it  open?  Good!
  88. 88. Product  Backlog • Few  porJons  to  pay  aFenJon  to: – What  work  are  the  teams  going  to  take  on  next? – What  are  the  teams  going  to  take  on  for  the  rest  of   the  year  at  a  high  level? – How  do  we  prioriJze  the  work  to  be  taken  on?
  89. 89. Product  Backlog Grouped  by  teams;  at  top  are  the  DNS  teams,  at  bojom  are  the  Email  teams.  Within  DNS,   we  can  see  short-­‐term  backlogs  for  DNS  Performance  and  Op0miza0on  and  DNS  New   Product  Development.  Within  Email,  we  can  see  short-­‐term  backlogs  for  Email   Deliverability  and  Email  Engineering.  Let’s  zoom  in  on  DNS.
  90. 90. Product  Backlog For  each  team,  the  backlog  contains  the  sorted  list  of  bugs  and  stories  that  will  be  taken   on  when  the  current  sprint  wraps  up.  The  top  10  items  are  shown.  The  top  N  items  define   the  next  sprint,  where  N  changes  based  on  the  complexity  of  the  work  that  can  be   completed  in  under  two  weeks.
  91. 91. Product  Backlog To  see  beyond  the  top  10,  you  can  click  the  “N  matching  issues”  link  at  bojom.
  92. 92. Product  Backlog The  short  term  backlog  defines  the  work  to  be  done  between  the  next  sprint  and  about   6-­‐8  weeks  out.  The  long  term  backlog  focuses  on  larger  efforts  that  we  know  we’re  going   to  take  on,  between  about  2  months  out  to  1  year  out.  Clicking  the  tabs  changes  the  view.
  93. 93. Product  Backlog There  are  two  priori0za0on  links;  one  shows  priority  of  just  the  stories  and  bugs,  while   the  other  includes  the  technical  and  business  sub-­‐tasks  that  describe  the  work  to  be  taken   on  in  detail.
  94. 94. Current  Sprint Let’s  look  at  the  third  secJon  in  detail:   Current  Sprint. The  goal  of  this  secdon  is  to  show  what  teams  are   working  on  now  in  the  current  sprint,  who’s   working  on  what,  and  how  efforts  are  progressing   within  the  sprint  (e.g.,  efforts  to  be  done,  in   progress,  in  QA,  and  complete)  toward  a  release. Have  it  open?  Good!
  95. 95. Current  Sprint The  rows  indicate  teams  (e.g.,  Data,  Marke0ng,  DNS  P+O,  Email  Deliverability,  etc.).  The   columns  indicate  states  of  stories  and  bugs  as  they  progress  through.  As  a  sprint  is  worked   on,  issues  move  from  lea  to  right.
  96. 96. Current  Sprint Here  is  the  work  currently  being  taken  on  by  the  data  team,  described  in  the  form  of   stories  and  bugs.
  97. 97. Current  Sprint Here  is  all  of  the  work  across  the  teams  that  has  yet  to  be  started.  Moving  lea  to  right,  the   work  goes  through  the  states:  In  Progress,  In  QA,  and  finally  Done.  When  the  work  is   released  to  produc0on  at  the  end  of  the  sprint,  it’s  removed  from  the  view.
  98. 98. Current  Sprint To  move  work  from  one  state  to  another,  click  the  “Current  Sprint  Rapid  Board  with   Stories  and  Bugs”  link.  That  will  take  you  to  JIRA,  where  you  can  drag  and  drop  your  work   into  the  next  state.  
  99. 99. Current  Sprint To  see  the  individual  technical  and  business  sub-­‐tasks  that  compose  the  stories  and  bugs,   and  how  those  individual  items  are  progressing,  click  the  “Current  Sprint  Rapid  Board   Including  Tasks”  link.
  100. 100. Get  your  own  dashboard! If  you’re  running  Confluence  and  JIRA  and  would  like  to  get  started  with  this  dashboard,   email  me  at  cvw@dyn.com  and  I’d  be  happy  to  send  you  the  code  and  help  you  set  it  up!
  101. 101. Course Title Course Title INSTRUCTOR NAME

×