Measuring Efficiency and Productivity of a team

Albert Arul Prakash

Measuring the performance

#Management is to confuse #measuring with #acting, #targets with #performance, and #planning with #change. #beta #stoos #agile

-Niels Pflaeging

Author of Organize for Complexity

Measuring number of hours

• We measure efficiency and productivity by number of hours a team member worked.

Productivity No. hours worked

Efficiency of team member

• Always gauged by the amount of time taken to complete a task

More time than planned = Less efficient

Less time than planned = More efficient

Hours – The Decider

Workaround

• Add Sponge at every stage.

• Always plan for worst day not for normal day

Reports

Problems with traditionIndividual• Not being transparent in accepting mistakes• Trying to defend themselves• Finger-pointing at others• Never trying getting help from others• Never taking ownershipTeam• Low productivity• Team morale• No ownership of what they do• Hiding the ant until it becomes an elephant• No communication on the issues they face

Do we need hours

• Hours is not used in

– Release plan

– Velocity calculation

– Sprint planning

– Ball park estimate

Measuring efficiency without hours

• Number of bugs in the system– QA specialist:

• How many bugs did you find early, even before the build, that were fixed by developers?

• How many very critical bugs were found after the build?

– Dev. specialist: • How many were avoided in

the second run and fixed immediately?

• How many were critical?

– How improved is the turnaround time to fix a bug during a time period

Measuring efficiency without hours

• Test scenarios and use cases covered– QA specialist:

• How many valuable scenarios/use cases were written to cover the story?

• How many critical scenarios were identified and shared with others early during the sprint?

– Dev. specialist: • What was your contribution in

developing those scenarios/use cases?

– How collaborative team were to develop those scenarios and use cases

Measuring efficiency without hours

• Refining requirements

– Team:

• What is your contribution in refining the backlog by adding details to the requirements?

– How vocal the team is?

Measuring productivity

• Quality of code– How good was the code?

– What are the improvements seen over a period?

– How good was the code coverage using the unit testing?

– How productive the refactoring effort were during a particular timeline

– How often we refactor?

Measuring productivity

• Difference between Planned vs Actual stories in a sprint

• Velocity improvements over a time period

• How collaborative and vocal the team is in

– Solving problems

– Raising issues

• What value the team brings in standup