O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Closed loop - Software Estimation to Delivery

626 visualizações

Publicada em

A check and balance approach to Software estimation to delivery using Scrum method via JIRA

Publicada em: Tecnologia, Negócios
  • Login to see the comments

  • Seja a primeira pessoa a gostar disto

Closed loop - Software Estimation to Delivery

  1. 1. Closed Loop: Project Estimation to Delivery Ahsan Saleem Engagement Manager
  2. 2. Closed Loop? Closed loop refers to a check and balance approach to project delivery As a services company we should measure certain metrics that guide project managers where and why projects go over (or under) estimated budget
  3. 3. Presentation Agenda 1. Process 2. Metrics 3. Slippage Analysis 4. ‘Catch 22s’
  4. 4. Process 1. Creating WBS 2. Estimating WBS 3. Creating project plan 4. Project kick-off 5. Executing sprints and gathering metrics 6. Analysis
  5. 5. Creating WBS Process – Step 1
  6. 6. WBS Content Think of project in modules/features, user stories and tasks WBS is not just development Testing, scripts, builds, product definition, UI work etc. are all part of WBS Our estimation sheet automatically ads PM, testing, and bug fixing effort Generally in mobile and web apps we can derive WBS screen by screen plus backend processes
  7. 7. Sample WBS
  8. 8. WBS Rules  WBS items should not base on un-documented assumptions  WBS item should define functionality and not a mere UI item • E.g. Login button IS NOT a WBS item • Login feature (including UI) IS a WBS item  Ask maximum questions to client/sales team, lesser the assumptions better the WBS  Break bigger items that go over 2 days into smaller items  Too small an items are seldom useful e.g. 2 Hour tasks
  9. 9. Estimating WBS Process – Step 2
  10. 10. Estimation Process  PM should create the WBS  Senior engineers should provide effort estimate  How to assign days/hours to a task? • Based on previous experience • Avoid re-inventing the wheel and consider existing modules • A very aggressive estimate is equally harmful as a very safe estimate • Delivery team will be separate from estimate team so realistic estimates will help  Make detailed notes in assumptions column as it will greatly help the implementation team • Suggested modules • Assumptions • Suggested approaches  Ideally WBS items should directly translate into tickets
  11. 11. Creating Project Plan Process – Step 3
  12. 12. Project Plan A project plan will help layout overall picture of project start till delivery Sprints can be derived from the project plan Deviating from project plan is not a bad thing but you will be able to track it MS Project Plan and OpenProj both decent tools for project plan creation
  13. 13. Sample Project Plan
  14. 14. Project Kick-Off Process – Step 4
  15. 15. Project Kick-Off Meeting Introduce project team (internal and external i.e. client) Discuss project requirements and WBS and identify gaps Discuss with Sales/Engagement manager for gpas Discuss deliverables Discuss milestones and dates
  16. 16. Executing Sprints and Gathering Metrics Process – Step 5
  17. 17. Ticket Creation  WBS items should translate into tickets  WBS estimate should go into ‘Original Estimate’, even if you do not agree to its number value  Engineer should log actual hours worked on ticket and DO NOT manually change remaining estimate  PM should label on ticket in case the delta between original estimate and logged hours is more than 25%
  18. 18. Use Time Tracking report to spot slipping issues
  19. 19. Use labels to mark tickets that need analysis  Original estimate too tight/loose • Who to judge: PM or a senior engineer • Apply label Original-Estimate- Issue  Unclear or missed requirements from sales/estimation collateral • Should apply label Missed- Unclear-Req  Scope change • PM makes this call and applies a label on ticket; Scope- Change  You can search based on labels
  20. 20. Utilize Sprint Retrospective Meeting Retrospective meeting is a good time to touch base on tickets which went over and under initial estimate PM should label/comment on tickets with implementation engineer’s consent All major deltas should be communicated to Engagement Manager
  21. 21. Slippage Analysis
  22. 22. Using Interactive JIRA Graphs Report can be generated for a Sprint or total project
  23. 23. Issue Details The query can be altered live for more analysis
  24. 24. Report based on Assignee
  25. 25. Report based on Component
  26. 26. Catch 22’s
  27. 27. Catch 22’s The purpose of ‘Closed Loop’ is not a blame game, rather improve process and knowledge for overall company The exercise should not be presented as a police activity so it does not discourage team members The process will not work if engineer’s do not log hours or not put Original Estimates