Agile metrics and decide on: Warm Up Exercise - In …€¢ Retrospective actions – is the team improving themselves based on retrospective results, how many improvements per sprint,

Agile Austin Dev SIG - Metrics

Warm Up Exercise - In groups of 3-5, discuss Agile metrics and decide on:

● A Bad Metric● A Good Metric● An Odd Metric

Agile Austin Dev SIGSeptember 2013 - Metrics

Special thanks to:

Our hosts, BancVue, for their hospitality and meeting facilities. And to

Agile Austin for providing lunch.* For more SIGs and info, go to agileaustin.org

Agile Austin Developers SIG

● What: Topics relevant to Agile developers● When: Third Thursday each month @ noon● Where: BancVue Office● Contact: [email protected] ● Google Group: agileaustin-dev● http://agileaustin.org/category/agile-austin-events/dev-sig

Recap from August Meeting● Continuous delivery discussion

○ Replace manual processes with automated ones○ Avoid branching as much as possible○ Data migration is difficult○ Build health checks into the system○ Leverage tools when appropriate

● Created new topic backlog

** Any feedback or thoughts from the group before we start the next topic?

Agile Metrics

Why are metrics important?

● A constant evaluation of current progress● A measure of performance● An indication of project health

Some traditional metrics

● Story points○ burndown, burnup, velocity

● Defect Counts● Hours of effort● Lines of Code● Unit test code coverage● Code complexity

Leading and Lagging Metrics

● Leading Metrics○ Story points estimates

● Lagging Metrics○ Velocity○ Defect counts

Metrics can be abused

● Gaming metrics

● Unhealthy metrics as goals○ Planning or estimation quality○ Ancillary metrics - loc or bugs found or requirements

written

● Over-emphasizing metrics

The Hawthorn Effect

The act of observing a metric changes its behavior. Also stated “that which is measured, will improve.”

Goodhart’s Law

When a measure becomes a target, it ceases to be a good measure.

Healthy Metrics• Team agitation levels – capturing multi-tasking events, # of committed hours per sprint and variance from expected levels• Team velocity levels – trending over time, improvement trending, paying attention when team composition changes• Impediment handling – #’s per team, avg. time to resolve, # that impacted the Sprint Goals • Retrospective actions – is the team improving themselves based on retrospective results, how many improvements per sprint, average time to resolve • Escapes per sprint – bugs found post-sprint, adherence levels to Done-ness Criteria • Sprint Success / Failure – from the perspective of the Sprint Goal. Not so much focused at a Story or Task completeness level, but at an overall work delivered level

Other (maybe odd) metrics?

● Stand-up duration● Sprint Demo attendance● Pizza order frequency● ?

Dev Sig BacklogMetrics (Agile metrics) 7Unit Tests 6Working with Legacy Code 5Static and Dynamic Analysis Tools 5Services - versioning and compatibility and evolution 5Scrum, Kanban and other Agile processes 4Leveraging Functional Concepts 2Domain Driven Design 2Database Abstraction Libraries 1Monitoring 1Technical Practices 1Spreading the infection to DBAs, Ops, PMOs, PMs, C-Levels0Estimation 0Task Breakdown 0Microservices 0Big Data (Hadoop, etc.) 0Code Coverage 0Trunk based development (stable trunk) 0Abstraction, Good, Bad, or Ugly 0

Special thanks to:

Our hosts, BancVue, for their hospitality and meeting facilities. And to

Agile Austin for providing lunch.* For more SIGs and info, go to agileaustin.org