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.

Estimating and planning Agile projects

6,408 views

Published on

Estimating is hard to get right;
Why is estimating hard to get right?;
Why do we need to estimate;
Agile estimating and planning;
Determine the teams velocity;
Identify features and stories;
Define stories or features;
Planning Poker;
Agile Release Plan;
What if you don’t know the teams velocity?;
Estimating from ideal team structure;
The effect of rework;
Proposals and SOW’s;

Published in: Technology, Business
  • Stop getting scammed by online, programs that don't even work! ●●● https://tinyurl.com/y4urott2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Estimating and planning Agile projects

  1. 1. Estimating and planning agile projects murray.robinson@kiandra.com.au, murrayr3128@gmail.com, Twitter: @MurrayR3128, Blog: Agileinsights.wordpress.com Presented by: Murray Robinson
  2. 2. Estimating is hard to get right Suez Canal 3X more than estimated Sydney Opera House 15X more than estimated “On average Victorian Government ICT projects will have more than doubled in cost by the time they are finished” Victorian Ombudsman Report into ICT Projects Myki $1.5B vs $1B estimated
  3. 3. Why is estimating hard to get right?  Overly optimistic predictions of scope and budget to get a project approved and funded  Faulty forecasting techniques  Inadequate information  Scope creep  Everything looks easy at a high level
  4. 4. The Cycling Analogy
  5. 5. The Cycling Analogy
  6. 6. Why do we need to estimate Stakeholders need estimates of how long things will take and cost:  To decide if they are worth doing,  To compare alternative investments and solutions;  To allocate resources and  To plan product launches.
  7. 7. Agile estimating and planning Review Progress & Identify Velocity Develop an iteration and release plan Estimate each feature or story vs known stories Analyze stakeholder requirements Identify and rank features or stories
  8. 8. Determine the teams velocity Team Velocity 120 100 80 60 40 20 0 1 2 3 4 5 6 Estimated velocity 7 8 9 10 11 Actual velocity 12 13 14 15 16 17 Power (Actual velocity) 18 19
  9. 9. Identify features and stories Feature High level story Low level story Create and send basic email Search by keyword Open & read basic email Create sub folders Open RTF email Move emails Send RTF email Send HTML email Delete email Create HTML email Import & process contacts
  10. 10. Define stories or features Acceptance Criteria Given that I am {this actor} And {the situation is X} When I {do this step} Then {Y happens} Business Rule: When A and B then C Interface Design: UI Wireframe for X
  11. 11. The Estimation Game
  12. 12. Planning Poker
  13. 13. Agile Release Plan 3 5 8 3 1 feature pt = approx 6 story pts User Business Process 5 1 1 5 3 1 2 3 2 3 2 3 2 1 1 5 5 5 5 2 2 2 40 2 3 3 3 2 1 2 3 3 40 2 3 5 5 3 8 2 2 3 3 3 40
  14. 14. What if you don’t know the teams velocity? Traditional estimation Start Project Timeline  When velocity is unknown use a combination of traditional and agile estimating approaches  Determine features and estimate stories in points as before  Team provides an optimistic and pessimistic estimate of the features and stories they can commit to in an iteration. Use the pessimistic estimate as the velocity  As a check do a bottom up estimate of days effort taking into account that developer effort is only half the team effort and rework and defect fixing is often as much as the original effort again
  15. 15. Estimating from ideal team structure Online Application Back end Application BA 12% BA 14% PM 10% DEV 50% UX 11% QA 17% PM 11% 0% QA 19% DEV 56%
  16. 16. The effect of rework Outstanding team 90% test case pass rate Average team 70% test case pass rate Rework 10% Initial work 90% Poor quality team 40% test case pass rate Rework 25% Initial work 75% Rework = Defect fixes = Failed tests Initial work 50% Rework 50%
  17. 17. Proposals and SOW’s  Software development projects are always new  We uncover the real requirements and solutions by doing  Big up front designs lead to over specification of the wrong things  Fixed price & scope waterfall projects become variable price, scope and time on the first change request  Agile can guarantee delivery on time and on budget of the features that are most important to the customer  Move to Agile fixed price, fixed team projects with a target variable scope
  18. 18. Waterfall vs Agile
  19. 19. Future topics     Initiating an Agile project Agile Kanban vs Agile Scrum Scaling Agile for Large Teams Reduce wasted time and effort in software development  Project retrospectives  The business case for Agile
  20. 20. Feedback

×