metrics that bring value
TRANSCRIPT
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 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
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
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
www.luxoft.com
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
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
www.luxoft.com
Velocity Visualization
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
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
www.luxoft.com
44
-15.5
23
-6.5
HoursUnderestimate (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)
www.luxoft.com
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;
www.luxoft.com
www.luxoft.com
www.luxoft.com
www.luxoft.com
Ideal team
Not over-committing Finished on time Estimated correctly
No corrections is necessary
Great team
Completed work on time Adapted a scope to complete the sprint At the end can complete additional work
Discuss the reasons of late progress in Sprint first half
Consider the capacity on planning
By Dusan Kocurek, ScrumDesk
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
Discuss change of plan immediately as they see the progress is slowing down
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
Identify this problem earlier Ask the product owner to provide more work Continue with refined stories from the next
www.luxoft.com
Didn’t complete the commitment Was late for the entire sprint Didn’t adapt the sprint scope to appropriate
level
Move not completed or low priority stories to the next sprint.
Lower capacity of the next sprint 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
Ensure additional refined stories are ready to add
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
Explain why and how it is necessary to track the progress
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
Cancel the sprint Restart the team Train the team
Oh, management is coming! Do Your Duties
www.luxoft.com
Scope was not estimated Sprint was started
Arrange a planning meeting Estimate the user stories Create sprint backlog 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
Reevaluate sprint backlog Facilitate reevaluation session Coach the team
Zero effort
Up to the sky
Bump on the road Sprint is started incorrectly. Scope was added after the sprint start.
Restart the sprint, even within a shorter timeframe. Start sprints with planning session using metrics
www.luxoft.com