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


Published on

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 Learn more from the experts by visiting

Published in: Business, Technology
1 Comment
  • Thank-you for sharing. It's uncanny how similar our implementations of a product management process in JIRA are. I feel it further validates the decisions I took when implementing them. Of course the results did that, but it's good to see my thoughts echoed independently.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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

  1. 1. presentsCORY VON WALLENSTEINChief Technology Officer, Dyn Inc.@cvonwallensteinTools of the Trade:Creating a ProductProcess 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.  CooperPhoto  Credit:  h2p://
  3. 3. Agenda1. Product  Litmus  Test  –  Is  this  working?2. Product  vs  Project  Management  –  Role  in  org3. Deep  dive!1. Product  management  top  to  boFom2. Teams  driving  toward  success3. 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  TestIs  this  working?
  6. 6. hZp://
  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<wareIndividuals  and  interac1ons  over  processes  and  toolsWorking  so<ware  over  comprehensive  documentaJonCustomer  collabora1on  over  contract  negoJaJonResponding  to  change  over  following  a  planThat  is,  while  there  is  value  in  the  items  onthe  right,  we  value  the  items  on  the  le<  more.hZp://
  9. 9. Product  vs  Project  ManagementWhat  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://­‐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  priorityProduct  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  priorityProduct  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?Kicka1.  Get  the  ideas2.  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  priorityProduct  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?Kicka1.  Get  the  ideas2.  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  priorityProduct  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?Kicka1.  Get  the  ideas2.  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  theschedule?  What  non-­‐technical  tasks  are  required  to  make  it  successful?
  23. 23. What  Does  Product  Planning  Mean?1. Get  the  ideas2. PrioriJze  the  ideas3. Specify  the  funcJonality  for  the  idea4. 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  RequestsCustomer  Idea  for  New  Funcdonality• Example  request:
  26. 26. Examples  of  Feature  RequestsCustomer  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  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  AcJonChanging  rank  logs  the  change  and  sends  a  no0fica0onBe  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  priorityProduct  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  BacklogKickaThe  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  specificaJons4.  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  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  TogetherA  Dashboard  in  Confluence  that  the  whole  company  can  read.
  69. 69. KickassProducts  at  Dyn  Inc!Feature  RequestsProduct  Backlog3-­‐5  High  Profile  Projects  at  DynSprints  and  ReleasesEach  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  ProjectsLet’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  ProjectsSwitch  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  ProjectsThe  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  ProjectsThe  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  RequestsLet’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  RequestsThree  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  RequestsLet’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  RequestsFour  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  RequestsIf  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  RequestsThree  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  RequestsOnly  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  RequestsClicking  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  RequestsWant  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  RequestsCrea0ng  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  BacklogLet’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  BacklogGrouped  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  BacklogFor  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  BacklogTo  see  beyond  the  top  10,  you  can  click  the  “N  matching  issues”  link  at  bojom.
  92. 92. Product  BacklogThe  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  BacklogThere  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  SprintLet’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  SprintThe  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  SprintHere  is  the  work  currently  being  taken  on  by  the  data  team,  described  in  the  form  of  stories  and  bugs.
  97. 97. Current  SprintHere  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  SprintTo  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  SprintTo  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  and  I’d  be  happy  to  send  you  the  code  and  help  you  set  it  up!
  101. 101. Course TitleCourse TitleINSTRUCTOR NAME