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.
www.luxoft.com
Metrics That Bring Value
www.luxoft.com
Introduction
Svetlana Mukhina
ICAgile ICP, ICP-ATF, ICP-BVA, PSM I
Agile and Career Coach at Luxoft Agile P...
www.luxoft.com
What Metrics We Gather on Projects
ü  Capacity – number of ideal hours available during next sprint
ü  Ve...
www.luxoft.com
Capacity
Capacity is a number of ideal hours available during next sprint
ü  To understand how many hours ...
www.luxoft.com
www.luxoft.com
Ideal Hour and Load Factor
§  Read specification
§  Discuss specification with BA
§  Plan development ac...
www.luxoft.com
Velocity
Velocity is a number of story points completed during previous sprint.
ü  To track performance an...
www.luxoft.com
Velocity Visualization
www.luxoft.com
Requirements Stability Index
RSI is a percentage of requirements changed in the current sprint
ü  To under...
www.luxoft.com
Work Log
ü  To see what types of task are usually underestimated
Ø  Bring it on Retro or lessons learned ...
www.luxoft.com
44
-15.5
0
23
-6.5
Hours
Underestimate (delta >= 10 h)
Overestimate (delta <= -10 h )
Perfect estimate
Smal...
www.luxoft.com
www.luxoft.com
Burndown Chart
Burn-down is visual representation of story points burned to the given moment
ü  To make fo...
www.luxoft.com
www.luxoft.com
www.luxoft.com
www.luxoft.com
Ideal team
ü  Not over-committing
ü  Finished on time
ü  Estimated correctly
q  No corrections is neces...
www.luxoft.com
By Dusan Kocurek, ScrumDesk
ü  Complete commitment on time.
ü  Adapted the scope or worked harder to comp...
www.luxoft.com
ü  Didn’t complete the commitment
ü  Was late for the entire sprint
ü  Didn’t adapt the sprint scope to ...
www.luxoft.com
By Dusan Kocurek, ScrumDesk
ü  Didn’t update progress accordingly
ü  PO added the same amount of work tha...
www.luxoft.com
ü  Scope was not estimated
ü  Sprint was started
q  Arrange a planning meeting
q  Estimate the user sto...
www.luxoft.com
Upcoming SlideShare
Loading in …5
×

Svetlana Mukhina: Metrics That Bring Value at I T.A.K.E. Unconference 2015

498 views

Published on

Svetlana Mukhina: Metrics That Bring Value at I T.A.K.E. Unconference 2015

Published in: Technology
  • Be the first to comment

Svetlana Mukhina: Metrics That Bring Value at I T.A.K.E. Unconference 2015

  1. 1. www.luxoft.com Metrics That Bring Value
  2. 2. www.luxoft.com Introduction Svetlana Mukhina ICAgile ICP, ICP-ATF, ICP-BVA, PSM I Agile and Career Coach at Luxoft Agile Practice Experience: 12+ years in IT, Project and department management, Computer Linguistics, Technical Writing, Quality Assurance Interests: Project management, Agile transformation, Career and performance coaching, Psychology Hobbies: Horse riding, music, poker, travelling Linkedin - https://www.linkedin.com/in/svetlanamukhina
  3. 3. www.luxoft.com What Metrics We Gather on Projects ü  Capacity – number of ideal hours available during next sprint ü  Velocity – number of story point completed during previous sprint ü  Requirements stability index – percentage of requirements changed in the current sprint ü  Burn-down chart – visual representation of story points burned to the given moment ü  We also log work time on daily basis
  4. 4. www.luxoft.com Capacity Capacity is a number of ideal hours available during next sprint ü  To understand how many hours we really can do the work, e.g. write code or do testing Ø  A usual developer don’t work more then 5h per day ü  To be able to distribute tasks effectively Ø  No sense to plan tasks for the ones on holiday Ø  No good to refine or investigate tasks by those who will not take part in the sprint development ü  To do precise planning Ø  We estimate sub-tasks in hours and during planning map it to capacity
  5. 5. www.luxoft.com
  6. 6. www.luxoft.com Ideal Hour and Load Factor §  Read specification §  Discuss specification with BA §  Plan development activities §  Develop DB §  Develop server side §  Develop UI §  Check integration §  Build §  Development testing §  Bug-fixing §  Unit tests create §  Unit tests running §  Bug-fixing after unit tests run §  Prepare test date §  Run story test §  Prepare and test deployment procedures §  Deployment on server §  Merging §  Jira task update §  Sanity check §  Bug-fixing after testing §  Knowledge transfer and sharing §  Mentoring and training Included in ideal hour Included in load factor
  7. 7. www.luxoft.com Velocity Velocity is a number of story points completed during previous sprint. ü  To track performance and see area of improvements on a team and individual basis; ü  To form Sprint scope basing on experience from previous Sprint; ü  To mitigate hard push from Product Owner/Manager when they would like to do extra in-scoping; ü  To see that we have technical debt on the project; Ø  Technical debt does not calculated into velocity, but time is spent on it ²  Using velocity and capacity all together helps to align workload basing on the past experience and future availability of development time, it make planning more accurate and results more expectable
  8. 8. www.luxoft.com Velocity Visualization
  9. 9. www.luxoft.com Requirements Stability Index RSI is a percentage of requirements changed in the current sprint ü  To understand how much time was spent on re-work; ü  To show the re-work time to PO; Ø  It can be an argument to keep the sprint scope stable Ø  It can persuade PO to prepare requirements beforehand
  10. 10. www.luxoft.com Work Log ü  To see what types of task are usually underestimated Ø  Bring it on Retro or lessons learned session Ø  In such a way one team has found out they always late with UI tasks Ø  A team got statistics that tasks that done via virtual machines takes 30% more time Ø  Other guys were able to present bottleneck in testing to the management ü  To get information on re-opened tasks and investigate the reasons Ø  One more team found out the necessity of sanity tests ü  To track personal performance Ø  Playing table tennis is not about writing code
  11. 11. www.luxoft.com 44 -15.5 0 23 -6.5 Hours Underestimate (delta >= 10 h) Overestimate (delta <= -10 h ) Perfect estimate Small underestimate (0 <delta <10) Small overestimate (-10 < delta < 0) 2 1 5 6 3 Count Underestimate (delta >= 10 h) Overestimate (delta <= -10 h ) Perfect estimate Small underestimate (0 <delta <10) Small overestimate (-10 < delta < 0)
  12. 12. www.luxoft.com
  13. 13. www.luxoft.com Burndown Chart Burn-down is visual representation of story points burned to the given moment ü  To make forecasting about ability to deliver scope in time; ü  To see visually in-scoping and delays in order to be able to do de-scoping when it is necessary; ü  To focus on team, not individual work; Ø  Draw it as a team, be involved and take responsibility ü  To discover and remove impediments in time;
  14. 14. www.luxoft.com
  15. 15. www.luxoft.com
  16. 16. www.luxoft.com
  17. 17. www.luxoft.com Ideal team ü  Not over-committing ü  Finished on time ü  Estimated correctly q  No corrections is necessary Great team ü  Completed work on time ü  Adapted a scope to complete the sprint ü  At the end can complete additional work q  Discuss the reasons of late progress in Sprint first half q  Consider the capacity on planning By Dusan Kocurek, ScrumDesk
  18. 18. www.luxoft.com By Dusan Kocurek, ScrumDesk ü  Complete commitment on time. ü  Adapted the scope or worked harder to complete the sprint. ü  The team is self-reflecting q  Discuss change of plan immediately as they see the progress is slowing down q  Move a low priority item from next sprint backlog or to product backlog. Typical team Let’s have a rest ü  Committed to less than they are able to complete ü  PO does not provide enough stories for the sprint. ü  Over-estimation of complexity q  Identify this problem earlier q  Ask the product owner to provide more work q  Continue with refined stories from the next
  19. 19. www.luxoft.com ü  Didn’t complete the commitment ü  Was late for the entire sprint ü  Didn’t adapt the sprint scope to appropriate level q  Move not completed or low priority stories to the next sprint. q  Lower capacity of the next sprint q  Take corrective actions after a few days when slower progress is observed. Boom. It is too late By Dusan Kocurek, ScrumDesk Boom. Too early ü  Finished work sooner than expected ü  Didn’t work on additional stories even it had capacity to do it. ü  Stories were overestimated ü  The velocity is estimated incorrectly q  Ensure additional refined stories are ready to add
  20. 20. www.luxoft.com By Dusan Kocurek, ScrumDesk ü  Didn’t update progress accordingly ü  PO added the same amount of work that was already completed ü  Didn’t able to predict the end of the sprint q  Explain why and how it is necessary to track the progress q  Stop the team after two or three days that shows a flat progress line and should apply corrective actions ü  Non-functional team on many levels. ü  No coaching of the team ü  PO does not care about development progress q  Cancel the sprint q  Restart the team q  Train the team Oh, management is coming! Do Your Duties
  21. 21. www.luxoft.com ü  Scope was not estimated ü  Sprint was started q  Arrange a planning meeting q  Estimate the user stories q  Create sprint backlog q  Start working on sprint backlog By Dusan Kocurek, ScrumDesk ü  First sprint typically looks like that ü  Scope was added to backlog daily without progress recorded. ü  Tasks were re-estimated constantly during the sprint q  Reevaluate sprint backlog q  Facilitate reevaluation session q  Coach the team Zero effort Up to the sky Bump on the road ü  Sprint is started incorrectly. ü  Scope was added after the sprint start. q  Restart the sprint, even within a shorter timeframe. q  Start sprints with planning session using metrics
  22. 22. www.luxoft.com

×