in search of better velocity metrics
TRANSCRIPT
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?