dsfsfgad

Velocity MetricsIn search of velocity metrics that spur better conversations.

1

Burn chartsBurndownBurnupIdeal burnActual burntimepoints

timepointsalphabetaR1

Velocity metrics for better conversations How are we tracking against the scope?

Many teams track their progress against a release plan by updating a burndown chart or burnup chart. The burndown chart tracks against a fixed volume of work (working its way down to zero)The burnup chart has affordance for scope volume changes

The 3-sprint trailing average of completed points is a teams velocity

The burn up chart has been more popular since it better displays scope increase throughout the project.

Burn charts are used to predict project completion time and to track the teams productivity improvements

2

Velocity metrics for better conversations Unless the software is released, all scope is assumed scope.

Assuming accuracy of scope unreleased scope definition is VERY WATERFALL

Main problems with burn charts is that they measure completion against the assumed scope that will deliver the desired results. Measuring points completed is a proxy metric towards success that assumes the planned scope will produce desired results and the that the estimates are somewhat accurate.

3

Burn chart anti-patterns

DoesFeelsTeamManagementVelocity metrics for better conversations

Anti patterns that can emerge: Teams are being managed to velocity.Team management, Product owner and other stakeholder start putting too much emphasis on velocity (and overvalue the size estimates)By assuming the scope is correct, teams are Scaled up too early which inevitably means less exploration to try and find the right scope

Falling behind the ideal burn, often results into providing even more instruction and separation of analysis and execution not unlike gant chart management

All this energy best spent elsewhere because most projects aren't meant to reach max velocity (they lack a real value prop)

Anti pattern resultsProduct management and tea get further away from each otherTeam starts inflating estimatesTeam members are not encouraged to explore better solutions. Hence less agile

Its demotivatingThere is a lot to do,The lines dont look right, death march Were not being told the truth we can all see this isnt happening.

The closer you get to deadline or goal line, the more inaccurate the charts become. Tech debt, refactoring and performance optimizations arent visible.

4

Instead of pointsNumber of users Response timeCycle timeSuccess rateCompleteness... other?Velocity metrics for better conversations

Site response time key leading indicator for ability to handle actual successAs we grow along curve, user tolerance lowers, fast response is essential for growthHealth of software, simplified and refactored

Cycle time as measurement of as the teams/companys response time to the market.

5

Number of of usersOur growth

BenchmarkActualT1T2T3Market growthtimeusersFast growthStable growth

nowtimeusers

nowIs it a good idea? Is it the right time?Velocity metrics for better conversations

Track your growthUnderstand what causes growth or declineTrack against benchmarks (i.e. previous projects projects)Track market growth (i.e. comscore)This number will be very low for the first months.You can have negative velocity as user users drop or when you wall behind the market ( Market velocity)

Grow up charts

6

Application response timeMillisecondsGoog/AMZNToleranceTrendsIncident DetailsCan we handle the projected user growth in 3,6, and 9 months from now?Velocity metrics for better conversations Tolerance Goog/AMZN

Technical performance and response time as indicator whether you are ready for success/projected growthAs we grow along curve, user tolerance lowers, fast response is essential for growth

Health of software, simplified and refactored

i.e.Page load timesTop 5 Application transactionsSpeed of high volume Dbase operations

7

Cycle timeBuildVerify/TestLearnHow fast can we respond to market changes and new insights?Velocity metrics for better conversations

Measure how long it takes to respond to market

A very responsive organization has the ability to go from idea to user prototype test within one to two weeks and have it in production within 4 weeks with conclusive information in 5 to 6 weeks

For other organizations it takes 2 to 4 weeks to get a new idea on the roadmap and at least 8 more weeks to get it launched.

The most responsive organizations will churn through the most ideas and will learn the most about the market.

Cycle time is key leading indicator of productivity ( minimal waste @ toyata way & reinertsen)

8

Average cycle time Velocity metrics for better conversations

IterationProject10 days25 days

Company avgCurrentLast60 days

Cycle/Story Velocity Velocity metrics for better conversations daystimeCycle timeTotal storiestimestories

Another Visualization exploration10

Success rateAre we heading in the right direction? How good is our backlog? Project Epics: verified/totalLast 2 sprintsAccountSearchContentSocialPurchaseTracking.333.500.900.200.6661.0001/31/29/101/52/32/2Project.666.500.900.300.500.75010/154/818/203/106/126/8

Velocity metrics for better conversations

11

Feature CompletenessStandish 2002ProjectAre new stories used?Velocity metrics for better conversations

New feature usage against standish benchmark,

This is about details, development stories. How much polish is enough.

This level should be fairly detailed ( more like dev stories such as filter options, module tabs, number of items in home page carouselAcross platforms, is our RWD ( response web design), really RWD? Or does it just look good on other platforms but many features are barely used. Clicks on module options (i.e. carousels swipes, list filters/sorts, module tabs

The more you are heading towards standish numbers, the more complete your product.

Are we growing faster slower than market by adding featuresAre we adding the right featuresShould we stop adding features and invest elsewhere?

Gauge time spent on things that are used and not used

12

Velocity metrics for better conversations Different projects, different metricsDifferent project stages, shift focus

13

SummaryVelocity metrics for better conversations MetricDiscuss[Data points]Number of usersRight value proposition? Right time?User growth %Market shareReferralsRevenueUsage frequencyResponse timeAre we ready for the desired growth?Browser loadApp TransactionsDbase operationsCycle timeHow responsive/Agile are we? When will we have more answers?How much WIP/How much waste? By major initiativeBy featureBy storySuccess rateAre we heading in the right direction?How good is our backlog, analysis and execution? Are we in touch with the market?Feature hypotheses verified

CompletenessShould we keep investing in more scope? Or start investing in other projects? Are new features used? Are new feature options used?