Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Agile	
  Project	
  Life	
  Cycle	
  
	
  
	
  
	
  
	
  
	
   	
   	
   	
   	
   	
  
	
   	
   	
   	
   	
   	
  
	
  ...
 
	
  
	
  
Table	
  of	
  Contents	
  
	
  
Why	
  Agile	
  Project	
  Management	
  Works…………………………………………………………….…………………...
 
	
  
Release	
  Planning……………………………………………………………………………………………………………………………………………………..10	
  
Sprint	
  Planning…………………………………...
 
	
  
AGILE	
  PROJECT	
  LIFE	
  CYCLE	
  
	
  
Why	
  Agile	
  Project	
  Management	
  Works	
  	
   	
   	
   	
   	
...
 
	
  
The	
  goal	
  of	
  Product	
  Backlog	
  planning	
  is	
  to	
  determine	
  an	
  appropriate	
  answer	
  to	
...
 
	
  
Stand-­‐Up	
  Meetings	
   	
   	
   	
   	
   	
   	
   	
   	
   	
   Table	
  of	
  Contents	
  
Most	
  agile	
...
 
	
  
When	
  you	
  give	
  a	
  loosely	
  defined	
  user	
  story,	
  you	
  make	
  some	
  assumptions,	
  take	
  ...
 
	
  
Planning	
  poker	
  works,	
  first,	
  because	
  it	
  brings	
  together	
  multiple	
  expert	
  opinions	
  t...
 
	
  
2. The	
  cost	
  of	
  developing	
  (and	
  perhaps	
  supporting)	
  the	
  new	
  features.	
  
3. The	
  amoun...
 
	
  
Split	
  a	
  story	
  along	
  the	
  boundaries	
  of	
  the	
  common	
  CRUD	
  operations	
  Create,	
  Read,	...
 
	
  
iteration.	
  	
  An	
  iteration	
  plan	
  is	
  created	
  in	
  an	
  iteration	
  planning	
  meeting.	
  	
  ...
 
	
  
If	
  a	
  new	
  task	
  is	
  discovered	
  during	
  the	
  iteration	
  (and	
  they	
  almost	
  certainly	
  ...
 
	
  
Appendix:	
  A	
  (	
  Agile	
  Model)	
   	
   	
   	
   	
   	
   	
   	
   Table	
  of	
  Contents	
  
	
  
Upcoming SlideShare
Loading in …5
×

Agile Project LifeCycle

  • Be the first to comment

  • Be the first to like this

Agile Project LifeCycle

  1. 1. Agile  Project  Life  Cycle                                                                       Shaun  Smith   This  document  contains  the  proposed  project  life  cycle    
  2. 2.       Table  of  Contents     Why  Agile  Project  Management  Works…………………………………………………………….………………………………………………………4   Product  Owner…………………………………………….………………………………………………………………………………………….……………….4     Planning  Levels…………………………………..…………………………………………………………………………………………………………………….4   Create  a  SharePoint  2010  Project  Management  Information  System  Template…………………………………………………………5   Stand-­‐Up  Meetings……………………………………………………………………………………………………………………………………………………6   Implement  Version  Control  through  SharePoint  2010……………………………………………………………………………………………….6   Project  Budget………………………………………………………………………………………………………………………………………………………….6   Estimating  Size  and  Effort…………………………………………………………………………………………………………………………………………6   Key  Points  When  Estimating  in  Story  Points………………..…………………………………..……………………………………………………….7   Planning  Poker  for  Release  Planning…………………………..…………………………………………………………………………………………….7   Velocity  Equalizer………………………………………………………….………………………………………………………………………………………….8   Planning……………….…………………………………………………………………………………………………………………………………………………..8   Planning  for  Value……………..……………………………………………………………………………………………………………………………………..8   Prioritization…………………………………………..…………………………………………………………  ……………………………………………………..9   Knowledge………………………………………………………………………………………………………………………………………………………………..9   Risk……………………………………………………………………………………………………………………………………………………………………………9   When  to  Split  a  User  Story……………………………………………………………………………………………………………………………………...10   Scheduling……………………………………………………………………………………………………………………………………………………………….10  
  3. 3.     Release  Planning……………………………………………………………………………………………………………………………………………………..10   Sprint  Planning………………………………………………………………………………………………………………………………………………………..11   Velocity-­‐Driven………………………………………………………………………………………………………………………………………………………..11   Commitment  Driven…………………….………………………………………………………………………………………………………………………….12   Burndown  Chart………………………………………………………………………………………………………………………………………………………12   User  Stories…………..…………………………………………………………………………………………………………………………………………………12   Appendix  A:  (Agile  Model)……………………………………………………………………………………………………………………………………….13                                
  4. 4.     AGILE  PROJECT  LIFE  CYCLE     Why  Agile  Project  Management  Works                 Table  of  Contents     1. A  plan  does  not  guarantee  an  exact  set  of  features  on  an  exact  date  at  a  specified  cost.    A  plan  does,   however,  communicate  and  establish  a  set  of  baseline  expectations.   2. A  plan  should  be  updated  regularly  throughout  the  course  of  the  project,  so  that  something  like  a  one-­‐ month  late  delivery  will  not  be  a  last-­‐minute  surprise  to  anyone.   3. Agile  planning  balances  the  effort  and  investment  in  planning  with  the  knowledge  that  we  will  revise  the   plan  through  the  course  of  the  project.       4. An  agile  plan  is  one  that  we  are  not  only  willing,  but  eager  to  change.   5. The  planning  becomes  more  important  than  the  plan.   6. You  do  not  have  to  change  the  dates,  you  can  drop  a  feature,  reduce  the  scope  of  a  feature,  add  people  to   the  project.   7. Completed  features  are  the  unit  of  customer  value,  not  completed  activities.   8. The  estimates  we  give  should  reflect  our  uncertainty.    The  way  to  do  this  is  by  expressing  the  end  date  as  a   range.   9. The  best  way  to  deal  with  uncertainty  is  to  iterate/sprints.   10. Frequent  re-­‐planning  after  each  sprint.   11. For  a  plan  to  be  useful,  it  must  be  accurate,  but  agile  accepts  that  early  plans  will  be  imprecise  and  will  need   to  be  re-­‐planned  to  remove  the  imprecision.   12. Agile  estimating  and  planning  succeed  because  estimates  of  size  and  duration  are  separated.    We  start  by   estimating  the  size  of  a  project  through  user  story  points.      Then  estimate  a  rate  of  progress  called  velocity.     The  estimate  of  size  and  velocity  are  then  combined  to  arrive  at  an  estimate  of  duration.   13. Agile  acknowledges  the  importance  of  learning.     Product  Owner                       Table  of  Contents     1. Make  sure  all  team  members  are  pursuing  a  common  vision  for  the  project.   2. Establish  priorities  so  highest-­‐valued  functionality  is  always  being  worked  on.   3. Set  and  obtain  sign-­‐off  criteria.   Planning  Levels                       Table  of  Contents     1. Day   2. Iteration   3. Release   4. Product   5. Portfolio   6. Strategy  
  5. 5.     The  goal  of  Product  Backlog  planning  is  to  determine  an  appropriate  answer  to  the  questions  of  scope,  schedule,  and   resources  for  a  project.   A  good  release  plan  is  updated  throughout  the  project  at  the  start  of  each  sprint,  and  should  be  based  on  work   accomplished  in  the  just  finished  sprint,  identified  high-­‐priority  work  the  team  should  address  in  the  new  sprint.   Create  a  SharePoint  2010  Project  Management  Information  System  Template       Table  of  Contents   Template  will  include:     a. Libraries:       i. Project  Documents   1. Milestones  Doc   a. Chart  Web  Part  –  Milestone  Dashboard   b. Lists:   i. Project  Announcements   1. Title,    Modified   ii. Project  Calendar   1. Connect  to  Outlook   iii. Project  Contacts   1. Last  Name,    First  Name,    Company,      Business  Phone,    Home  Phone,    E-­‐mail  Address   iv. Project  Risks   1. Issue  ID,    Title,    Assigned  To,    Issue  Status,    Priority,    Due  Date   v. Agile  Product  Backlog   1. Task  Name,    User  Need,    Story  Points,    Start,    Finish,    Predecessors,    Duration,    State,    Sprint   vi. Project  Resources   1. Resource  Name,    Cost  (per  hour),    Notes,    Role   vii. Change  Request   1. CR  Tile,    Description  of  Change,    Affected  Task,    CR  Status,    Due  Date,    Change  Request   viii. Project  Milestone   1. Title,    ID  Number,    State  =  Not  Started,      State  =  In  Progress,    State  =  Complete   c. Discussions:   i. Discussion  Board   1. Subject,    Created  By,    Replies,      Last  Updated                    
  6. 6.     Stand-­‐Up  Meetings                     Table  of  Contents   Most  agile  teams  use  some  form  of  daily  stand-­‐up  meeting  to  coordinate  work  and  synchronize  daily  efforts.   Teams  definitely  make,  assess,  and  revise  their  plans  during  these  meetings.    They  focus  on  the  planning  of  tasks  and  on   coordinating  the  individual  activities  that  lead  up  to  the  completion  of  a  task.     Implement  Version  Control,  Through  SharePoint,               Table  of  Contents   Control  and  track  the  current  version  of  the  document  by  using  the  “check-­‐in”  and  “check-­‐out”  feature.    This  will   ensure  that  only  one  team  member  is  working  on  a  deliverable  at  any  one  point  in  time.    The”  Check  In”  feature   will  assign  a  version  number  and  capture  comments  describing  the  type  of  update.    This  will  create  the  version   history.     Project  Budget:                       Table  of  Contents   If  budget  management  is  required  for  a  project,  it  will  be  conducted  through  MS  Project  2010.    The  two  general  budget   categories  that  will  be  created  are  as  follows:       a. Fixed  Budget  Costs  e.g.  Hardware,  Software,  Travel  etc.   b. Computed  Budget  Costs  for  Budget  Work  Resources  based  on  Cost  Rates     Estimating  Size  and  Effort                   Table  of  Contents   A  story-­‐point  estimate  is  an  amalgamation  of  the  amount  of  effort  involved  in  developing  the  feature.    This  consists  of   the  complexity  of  developing  the  feature,  and  the  risk  inherent  in  its  development.    Story  points  are  a  unit  of  measure   for  expressing  the  overall  size  of  a  user  story,  feature,  or  other  piece  of  work.    The  raw  values  we  assign  are   unimportant.    What  matters  are  the  relative  values  assigned  to  each  feature  or  story.    For  instance  a  feature  that  is   assigned  a  two  should  be  twice  as  much  as  a  story  that  is  assigned  a  one.   There  are  two  common  ways  to  start  estimating  features  or  stories  by  Analogy  or  Triangulation.    The  first  approach  is  to   select  a  story  that  you  expect  to  be  one  of  the  smallest  stories  you’ll  work  with  and  say  that  story  is  estimated  at  one   story  point.    The  second  approach  is  to  instead  select  a  story  that  seems  somewhat  medium  and  give  it  a  number   somewhere  in  the  middle  of  the  range  you  expect  to  use.    After  you  arbitrarily  assign  a  story-­‐point  value  to  the  first   story,  each  additional  story  is  estimated  by  comparing  it  with  the  first  story  or  with  any  others  that  have  been  estimated.   One  way  to  do  this  is  to  assign  a  dog  point  as  representing  the  height  of  a  dog  at  the  shoulder.    Assign  dog  points  to  each   breed  below:   • Labrador  retriever     =    5   • Terrier    =    3   • Great  Dane    =    10   • Poodle    =    3   • Dachshund    =    1   • German  shepherd    =    5   • Saint  Bernard    =    9   • Bulldog    =    3  
  7. 7.     When  you  give  a  loosely  defined  user  story,  you  make  some  assumptions,  take  a  guess,  and  move  on.    It  is  not   uncommon  to  begin  a  sprint  with  incompletely  specified  requirements,  the  details  of  which  will  be  discovered  during  the   sprint.    Two  developers  of  different  skill  or  experience  can  agree  on  the  size  of  something  while  disagreeing  about  how   long  it  will  take  to  do.   Ideal  time  is  the  amount  of  time  that  something  takes  when  stripped  of  all  peripheral  activities  including  overall  size  and   complexity  of  the  feature  being  implemented.    Elapsed  time  is  the  amount  of  time  that  passes  on  a  clock  or  calendar.   When  considerations  of  organizational  overhead  are  ignored,  ideal  days  can  be  thought  of  as  another  estimate  of  size,   just  as  story  points  are.    Estimate  ideal  days  by  associating  a  single  estimate  with  each  user  story,  rather  than  estimating   that  a  user  story  will  take  four  programmer  days,  two  tester  days,  and  three  product  owner  days,  it  is  better  to  sum   those  days  and  say  the  story  as  a  whole  will  take  nine  ideal  days.   Agile  teams  do  not  rely  on  a  single  expert  to  estimate.    Estimates  are  derived  collaboratively  by  the  team,  which  includes   those  who  will  do  the  work.        Studies  show  that  people  are  best  at  estimating  things  that  fall  within  one  order  of   magnitude.    Two  estimation  scales  that  can  be  used  are  the  Fibonacci  numbers:  1,2,3,5,  and  8,  or  1,  2,  4,  and  8.         A  large  user  story  is  called  an  epic.    A  set  of  user  stories  is  referred  to  as  a  Theme.    An  epic  can  be  a  theme  on  its  own.     Estimates  of  themes  and  epics  will  be  more  uncertain  than  estimates  of  more  specific,  smaller  user  stories.    User  stories   need  to  be  small  enough  that  they  can  be  completed  in  a  single  sprint.    Disaggregation  refers  to  splitting  a  story  or   feature  into  smaller,  easier-­‐to-­‐estimate  pieces.       Key  Points  When  Estimating  In  Story  Points:               Table  of  Contents   o Story  points  help  drive  cross-­‐functional  behavior  because  they  are  estimated  as  a  group.   o Story  point  estimates  do  not  decay  because  the  story  will  always  be  the  same  size  but  the  time  it  takes   to  complete  will  change.   o Story  points  are  a  pure  measure  of  size  if  we  estimate  by  analogy  only  (this  is  like  that).   o Estimating  in  story  points  typically  is  faster.   o My  ideal  days  are  not  your  ideal  days  because  everybody  will  need  to  take  as  long  as  THEY  need  to   complete  a  task.   Planning  Poker  for  Release  Planning                 Table  of  Contents   Planning  poker,  each  estimator  is  given  a  deck  of  cards  with  written  estimates  of  0,  1,  2,  3,  5,  8,  13,  20,  40,  and  100  on   each  of  them.    The  moderator  reads  the  description.    The  moderator  is  usually  the  product  owner  or  an  analyst.     Everyone  is  asked  to  remain  aware  of  the  effort/accuracy  curve.    The  goal  is  to  be  somewhere  well  on  the  left  of  the   effort  line,  where  a  valuable  estimate  can  be  arrived  at  cheaply.    After  all  questions  are  answered,  each  estimator   privately  selects  a  card  representing  his  or  her  estimate.    Cards  are  not  shown  until  each  estimator  has  made  a  selection   at  that  time,    all  cards  are  simultaneously  turned  over  and  shown  so  that  all  participants  can  see  each  estimate.    If   estimates  differ,  the  high  and  low  estimators  explain  their  estimates.      The  moderator  can  take  any  notes  she  thinks  will   be  helpful  when  this  story  is  being  programmed  and  tested.    After  the  discussion,  each  estimator  re-­‐estimates  by   selecting  a  card.    Cards  are  once  again  kept  in  private  until  everyone  has  estimated,  at  which  point  they  are  turned  over   at  same  time.    Continue  the  process  as  long  as  estimates  are  moving  closer  together.    Use  a  timer  in  the  middle  of  the   table  and  allow  two  minutes  for  each  hand  of  poker.    Estimating  an  initial  set  of  user  stories  may  take  a  team  two  or   three  meetings  of  from  one  to  three  hours  each.        
  8. 8.     Planning  poker  works,  first,  because  it  brings  together  multiple  expert  opinions  to  do  the  estimating.    These  experts   form  a  cross-­‐functional  team  from  all  disciplines  on  a  software  project.    Second,  a  lively  dialogue  ensues  during  planning   poker,  and  estimators  are  called  upon  by  their  peers  to  justify  their  estimates.    Third,  averaging    individual  estimates   leads  to  better  results.   Velocity  Equalizer                     Table  of  Contents   Velocity  is  the  great  equalizer,  because  the  estimate  for  each  feature  is  made  relative  to  the  estimates  for  other   features,  it  does  not  matter  if  our  estimates  are  correct,  a  little  incorrect,  or  a  lot  incorrect.    What  matters  is  that  they   are  consistent.    As  long  as  we  are  consistent  with  our  estimates,  measuring  velocity  over  the  first  few  sprints  will  allow   us  to  hone  in  on  reliable  schedule.   Re-­‐estimate  only  when  a  story’s  relative  size  has  changed,  or  when  the  team  finishes  only  a  portion  of  a  story  is  finished   during  a  sprint.    If  everything  is  done  all  points  are  captured,  if  anything  is  missing  no  points  are  captured.      Re-­‐estimate   as  few  stories  as  possible  to  bring  the  relative  estimates  back  in  line.    Use  re-­‐estimating  as  a  learning  experience  for   estimating  future  user  stories.       A  team  only  counts  points  toward  velocity  for  stories  or  features  that  are  complete  at  the  end  of  a  sprint.    Counting   partially  finished  work,  giving  partial  credit,  makes  it  impossible  to  know  exactly  where  we  are  in  the  project,  and  leads   to  a  buildup  of  work  in  process.    The  more  work  in  process,  the  longer  it  will  take  new  features  to  be  transformed  from   raw  ideas  into  functioning  product.    Large  amounts  of  work  in  process  will  take  longer  for  the  team  to  get  feedback  on   what  was  completed.   Planning                       Table  of  Contents   Before  planning  a  project,  we  must  consider  what  it  is  that  our  users  need.    Individual  user  stories  or  features  are   aggregated  into  themes.    Stories  and  themes  are  then  prioritized  relative  to  one  another  for  the  purpose  of  creating  a   release  plan,  such  that  themes  should  be  selected  so  each  defines  a  discrete  set  of  user-­‐or-­‐customer-­‐valued   functionality.     Release  planning  is  the  process  of  creating  a  very  high-­‐level  plan  that  covers  a  period  longer  than  an  sprint.    A  typical   release  will  cover  perhaps  three  to  six  months  and  maybe  three  to  twelve  or  more  sprints.     Planning  for  Value                     Table  of  Contents     The  whole  team  is  responsible  for  estimating.    It  is  difficult  to  estimate  the  value  of  small  units.       User  stories  or  features  are  aggregated  into  themes.   Stories  and  themes  are  prioritized  relative  to  one  another  to  create  a  release  plan.   Each  theme  defines  a  discrete  set  of  user  valued  functionality.     Prioritization                       Table  of  Contents     Four  factors  must  be  considered  when  prioritizing  themes.     1. The  financial  value  of  having  the  features.   Estimate  its  financial  impact  over  a  period  of  time.     New  sales,  new  donations…etc.  
  9. 9.     2. The  cost  of  developing  (and  perhaps  supporting)  the  new  features.   3. The  amount  and  significance  of  learning  and  new  knowledge  created  by  developing  the  features.   4. The  amount  of  risk  removed  by  developing  the  features.     The  themes  with  a  high  value-­‐to-­‐cost  ratio  are  those  that  should  be  done  first.    When  possible,  try  to  combine  related   stories  as  that  will  make  it  easier  to  prioritize  them.       Determine  the  priority  of  a  theme  by  asking  questions  such  as  “How  would  the  user  feel  if  the  feature  were  present”,   and  then  ask  “How  would  the  user  feel  if  the  feature  were  not  present”.    Use  the  following  answers:     1. I  like  it  that  way   2. I  expect  it  to  be  that  way   3. I  am  neutral   4. I  can  live  with  it  that  way   5. I  dislike  it  that  way     Dynamic  Systems  Development  Method  (DSDM)  is  another  way  of  determining  priority.    Requirements  are  sorted  into   four  categories:  Must  Have,  Should  Have,  Could  Have,  and  Won’t  Have.    No  more  than  70%  of  the  planned  effort  for  a   project  can  be  targeted  at  Must  Have  requirements.    In  this  way  DSDM  projects  create  a  feature  buffer  equivalent  to   30%  of  the  duration  of  the  project.     Knowledge                       Table  of  Contents     At  the  start  of  a  project,  we  never  know  everything  that  we  will  need  to  know  by  the  end  of  the  project.    There  is  two   types  of  knowledge  that  a  team  develops:     o Knowledge  about  the  product,  (what  will  be  developed).   o Knowledge  about  the  project,  (how  will  it  be  developed).   Risk                         Table  of  Contents     A  risk  is  anything  that  has  not  yet  happened  but  might  and  that  would  jeopardize  or  limit  the  success  of  the  project.    The   types  of  risks  are:       o Schedule  risk  (“We  might  not  be  done  by  October”)   o Cost  risk  (“We  might  not  be  able  to  buy  hardware  for  the  right  price”)   o Functionality  risk  (“We  might  not  be  able  to  get  that  to  work”)   o Technological  risk   o Business  risk     When  to  Split  a  User  Story                   Table  of  Contents   A  user  story  should  be  split  when  it  is  too  large  to  fit  within  a  single  sprint.   It  won’t  fit  within  the  sprint  being  planned  because  there  isn’t  enough  room  left.   Split  story  by  the  type  of  data  that  the  user  could  enter.  
  10. 10.     Split  a  story  along  the  boundaries  of  the  common  CRUD  operations  Create,  Read,  Update,  Security,  Error-­‐Handling,   Delete,  and  Logging.    Deliver  a  partial  user  interface,  a  partial  middle  tier,  and  a  partial  database.    Delivering  a  cohesive   subset  of  all  layers  of  a  feature  is  almost  always  better  than  delivering  all  of  one  layer.   Scheduling                       Table  of  Contents   In  some  cases  we  start  with  a  finish  date  and  see  how  much  we  can  finished  by  that  date.    In  other  cases  we  start  with  a   set  of  user  stories  and  see  how  long  it  will  take  to  develop  them.    Multiply  the  planned  number  of  sprints  by  either  the   expected  or  known  sprint  velocity  of  the  team  gives  the  total  amount  of  work  that  can  be  performed.   If  feature  driven  project,  sum  the  estimates  of  all  needed  features  and  divide  by  the  velocity.    This  will  give  us  the   number  of  sprints  necessary  to  complete  the  desired  functionality.    If  date-­‐driven  project,  we  can  determine  the  number   of  sprints  by  looking  at  a  calendar.    Multiply  the  number  of  sprints  by  the  expected  velocity  will  tell  us  how  many  story   points  or  ideal  days  will  fit  in  the  release.       The  product  owner  selects  the  top  priority  items  that  will  fit  in  the  first  sprint.    Cards  are  stacked  or  arranged  to  indicate   which  stories  comprise  each  sprint.    Each  story  card  is  annotated  with  an  estimate,  it  is  possible  to  look  down  each   column  of  an  arrangement  and  verify  that  each  sprint  holds  the  right  amount  of  work.   Release  Planning                     Table  of  Contents   Agile  planning  becomes  a  two-­‐stage  process,  release  plan  and  iteration  plan.    The  first  stage  is  the  release  plan,  with  its   rough  edges  and  general  uncertainties.    Release  planning  is  the  process  of  creating  a  very  high-­‐level  plan  that  covers  a   period  longer  than  a  iteration.    A  typical  release  is  three  to  six  months  and  maybe  three  to  twelve  iterations.    A  release   plan  does  the  following  three  things:   o Helps  the  product  owner  and  team  decide  how  much  must  be  done  and  how  long  it  will  take.   o Conveys  expectations  about  what  is  likely  to  be  developed  and  in  what  timeframe.   o Serves  as  a  guidepost  for  progress.   o Either  starts  with  an  end  date  and  see  how  much  can  be  finished,  or  start  with  a  set  of  user  stories  and   see  how  long  it  will  take  to  develop  them.       o Multiply  the  planned  number  of  iterations  by  either  the  expected  or  know  velocity  of  the  team  gives  us   the  total  amount  of  work  that  can  be  performed,  (Number  of  Iterations  x  Velocity  =  Amount  of  Work   Performed).       o Sum  the  estimates  of  all  needed  features  and  divide  by  the  expected  velocity  will  give  the  number  of   iterations  necessary  to  complete  the  desired  functionality,  (Features  /  Velocity  =  Number  of  Iterations   to  Complete).     o Decisions  about  who  works  on  what  and  the  sequence  of  activities  are  best  left  to  the  individuals   working  on  those  tasks  and  best  deferred  as  long  as  possible.   o Include  additional  information  in  the  release,  such  as  assumptions  like  who  is  on  the  team  ,  first   iteration  start  date,  and  finish  date.   o Place  specific  work  into  the  first  one  to  three  iterations,  rest  of  the  release  plan  is  product  backlog.     Sprint  Planning                       Table  of  Contents     A  release  plan  provides  only  the  high  level  view  of  the  product  being  built.    With  iteration  plan,  a  team  takes  a  more   focused,  detailed  look  at  what  will  be  necessary  to  implement  completely  only  those  user  stories  selected  for  the  new  
  11. 11.     iteration.    An  iteration  plan  is  created  in  an  iteration  planning  meeting.    Anyone  involved  in  taking  a  raw  idea  and  turning   it  into  a  functioning  product  should  be  present.    It  can  be  as  simple  as  a  spreadsheet,  a  set  of  note  cards  with  one  task   handwritten  on  each  card,  or  eboard  on  SharePoint  .    Tasks  are  not  allocated  to  specific  individuals.  The  sprint  plan  looks   ahead  only  the  length  of  one  sprint,  usually  one  to  two  weeks.    The  sprints  should  be  staggered  with  a  one  week  sprint   and  then  a  two  week  sprint  and  then  a  one  week  sprint.        The  user  stories  of  the  release  plan  are  decomposed  into  tasks   on  the  iteration  plan.    Tasks  on  the  iteration  plan  are  estimated  in  ideal  hours.    An  iteration  review  meeting  is  held   after  the  iteration  is  finished,  and  will  take  thirty  to  sixty  minutes.    A  prioritization  meeting  is  held  two  days  before  the   end  of  the  iteration,  and  involves  anyone  that  can  contribute  to  a  discussion  of  the  project’s  priorities.       Two  ways  to  plan  a  sprint,  one  is  called  velocity-­‐driven  and  the  other  is  commitment-­‐driven.       Velocity-­‐Driven  is  done  by  the  following:               Table  of  Contents   1. Collaboratively  adjust  priorities.   2. Id  the  target  velocity  for  the  coming  iteration.   3. Selects  a  sprint  goal,  what  they  wish  to  accomplish.    A  unifying  statement  about  what  will  be  accomplished   during  the  iteration.    It  does  not  have  to  be  very  specific.   4. Select  the  top-­‐priority  user  stories  that  support  goal,  enough  to  sum  up  ideal-­‐day  or  story-­‐point  estimates  to   equal  target  velocity.   5. The  best  way  to  predict  velocity  is  to  observe  velocity,  this  should  always  be  your  default  approach.   6. Selected  stories  are  split  into  tasks,  and  each  task  is  estimated.    All  tasks  necessary  to  go  from  a  user  story  to   a  functioning,  finished  product  should  be  identified.    Only  include  tasks  that  add  immediate  value  to  the   current  project.    Include  tasks  for  meetings  and  any  time  spent  preparing  for  the  meeting.    Put  stories  in   their  natural  order  which  is  the  order  the  team  assumed  when  they  estimated  the  stories.  A  spike  task   included  in  an  iteration  plan  that  is  being  undertaken  specifically  to  gain  knowledge  or  answer  a  question.     The  spike  would  help  the  team  learn  how  they’d  approach  the  other  task,  which  would  allow  them  to   estimate  it.    A  task  should  be  able  to  be  completed  within  one  day.       Commitment-­‐Driven  is  done  by  the  following:               Table  of  Contents   1. The  team  adds  stories  to  the  iteration  one  by  one  until  they  can’t  commit  to  any  more.   2. Adjust  priorities  and  identify  an  iteration  goal.   3. Estimate  the  number  of  hours  that  each  person  will  be  available  to  work  on  the  project  each  day.   4. Determine  the  total  number  of  hours  that  will  be  spent  on  the  project  during  the  sprint.   5. The  product  owner  and  team  select  the  highest-­‐priority  story.   6. Stories  are  selected  and  decomposed  into  tasks.   7. Tasks  are  estimated  one  story  at  a  time  and  converted  into  ideal  hours.   8. Select  tasks  until  you  have  identified  enough  tasks  to  fill  the  number  of  hours  in  the  sprint.   Schedule  the  prioritization  meeting  for  two  days  before  the  end  of  the  iteration.    The  product  owner  conducts  the   prioritization  meeting  and  involves  anyone  she  thinks  can  contribute  to  a  discussion  of  the  project’s  priorities.    Sum  up   the  estimates  and  see  if  the  sum  represents  a  reasonable  amount  of  work.  
  12. 12.     If  a  new  task  is  discovered  during  the  iteration  (and  they  almost  certainly  will  be),  a  team  that  is  committed  to  delivering   the  functionality  described  by  a  user  story  will  try  to  complete  the  new  tasks  as  well.   The  key  is  that  everyone  on  the  team  is  accountable  for  contributing  whatever  is  within  their  capabilities,  regardless  of   whether  it  is  their  specialty.       Burndown  Charts                     Table  of  Contents   Shows  the  number  of  story  points  or  ideal  days  remaining  in  a  project.       User  Stories                       Table  of  Contents   Example:   Front    As  a  <>  I  want  to  <>  so  that  I  can  <>.   Priority:  (DSDM)  –  Must  Have,  Should  Have,  Could  Have,  Won’t  Have   Story  points:  1,2,3,5,8,13,21,34   Back   Confirmations  or  acceptance  criteria,  sketches,  flow  charts,  UML                          
  13. 13.     Appendix:  A  (  Agile  Model)                 Table  of  Contents    

×