Metrics That Bring Value

www.luxoft.com

Metrics that bring valueSvetlana Mukhina

www.luxoft.com

IntroductionSvetlana MukhinaICAgile ICP, ICP-ATF, ICP-BVA, PSM I, CSPO

Agile and Career Coach at Luxoft Agile PracticeExperience: 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

https://www.linkedin.com/in/svetlanamukhina

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 prognosis 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

Incl

uded

in id

eal h

our

Incl

uded

in lo

ad fa

ctor

www.luxoft.com

Velocity

Velocity experience 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 used to measure the changes in the business requirement added or deleted compared to the original requirements decided at the start of the Sprint.Requirement Stability Index = (Total number of original business requirements + Number of requirements changed till date+ Number of requirements added + Number of requirements deleted) / (total number of original requirements)

Requirement Stability Index = (10+5+2+1)/10 =1.8 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;

No. of Original Requirements

No. of Requirements Changed

No. of Requirements Added

No. of Requirements Deleted

Requirement Stability Index

10 5 2 1 1.8

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; The 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 estimateSmall underestimate (0 <delta <10)Small overestimate (-10 < delta < 0)

2 1

56

3

CountUnderestimate (delta >= 10 h)Overestimate (delta <= -10 h )Perfect estimateSmall 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

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

By Dusan Kocurek, ScrumDesk

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

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

By Dusan Kocurek, ScrumDesk

www.luxoft.com

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

By Dusan Kocurek, ScrumDesk

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 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

By Dusan Kocurek, ScrumDesk

www.luxoft.com

www.luxoft.com

Further Reading and Watching Overview of Estimation in Function Points upcoming webinar (eng) https

://attendee.gotowebinar.com/register/7096855347981584898?anouncementduringwebinar

The Power on Visualization – recording of webinar (eng)https://www.linkedin.com/pulse/20141202230246-48371619-follow-up-on-the-webinar-the-power-on-visualization

How to calculate work hours of the team - post (eng)https://www.linkedin.com/pulse/how-calculate-work-hours-team-svetlana

Как манипулировать диаграммами - статья (рус) https://www.linkedin.com/pulse/как-манипулировать-диаграммами-svetlana

Метрики, которые приносят пользу - запись вебинара (рус) https://goo.gl/nV35j7

www.luxoft.com

Upcoming Trainings from Agile Practice

ICAgile Certified Professional – Agile Team Facilitation. Тренинг (рус), Киев, январь 21-22For Luxoft https://inthr.luxoft.com/IntHRWebApp/aspx_PTC/CreateRequestInternal.aspx?Course=SDP-035 For non-Luxoft http://www.luxoft-training.ru/kurs/icagile_icp_agile_team_facilitation_icagile_icp-atf.html

ICAgile Certified Professional - Agile Fundamentals. Тренинг (рус) • Санкт-Петербург, январь 20-22 • Москва, январь 27-29

For Luxoft https://inthr.luxoft.com/IntHRWebApp/aspx_PTC/CreateRequestInternal.aspx?Course=SDP-031 For non-Luxoft http://www.luxoft-training.ru/kurs/icagile_certified_professional_-_agile_fundamentals.html

For trainings in Sofia, Bucharest, Krakow, Wroclaw, Minsk contact [email protected]

www.luxoft.com

Thank you