| Table of Contents |
|---|
Roadmap Focus
Why:
Understand how much of your team’s effort is going towards roadmap work vs maintenance and tasks.
Answer the question “How long do you think this will take?” with confidence knowing how focused you’ve historically been on planned work.
...
Group series by parent properties.
Filter out “Won’t Do” statuses via Advanced Filters
Velocity
Why:
Understand if your team is consistently delivering based on their estimation and pointing.
...
Base goal of the metric: consistency of delivery and estimation. Do we consistently deliver 20 points, and are 20 points always roughly the same?
Based issue count and type: So you get more holistic views of everything the team has done historically.
Other cases:
Normalizing across teams
Ratios normalize disparate estimation processes.
Different team types (QA,vs dev vs product)
Dev - assignee based velocity
QA - If they are assigned, historic assignee velocity
Product is going to be more focused on roadmap focus, capacity, historic allocation of the dev team.
By points, by estimation method
Determine consistency of child delivery and ratios
Defects vs new product
Roadmap focus, etc
Sprint Attainment (
...
for Scrum Teams)
Why:
Metric:
Committed vs Completed
...
Base goal: Did we complete all of the issues committed to at the beginning of the sprint and meet our goal?
Threshold goal is between 80-90%
Committed vs Committed Completed
Filter by project or individual sprint names.
Added vs Added Completed
Percentage changes over time
Cycle Time
Why:
Metric:
Settings to Apply:
Goal: Consistent timely completion of relatively sized work.
By issue type
Or by story points
“Finding your five”
Consistent definition of issue types
Smallest issue type should be under 3 days at most.
What about weekends/non-working times?
Set thresholds slightly higher than the goal to call out truly stalled items.
Set goals based on calendar time, not working time.
Lead Time
Why:
Understand how quickly your team responds to high priority bugs, defects, and customer inquiries.
Metric:
Issue Lead Time
Settings to Apply:
Tracks from creation to completion
For defects and customer requests
...
Filter out “Won’t Do” type issue/work item states.
Filter down to bugs, defects and/or customer requests.
Group by month or quarter.
Group series by priority/severity.
Issue Time in State
Why:
Metric:
Settings to Apply:
Analyze for bottlenecks
Finding median or average time in progress, wait states, etc.
For example, in progress states should often be under 24 hours. Make sure items aren’t bottlenecked waiting for QA resources, etc.
Defect/Bug creation over time - filter by backlog
Why:
Metric:
Settings to Apply:
Issue creation metric
By priority/severity
Filter to the relevant backlog of the team.
Bouncebacks
Why:
Metric:
Settings to Apply:
Displays cards that have revisited previous states, like QA back to dev, or dev back to product requirements.
Increase shows churn/uncertainty
Also sort by number of bouncebacks on cards. Good retro items
Coding days
Why:
Metric:
Settings to Apply:
Low coding days implies blockers towards team having heads-down time to write code
Where do we get 3-4 recommended days?
Developers should check code in daily. Most scrum teams have a day of meetings/refinements/plannings/etc, so it will almost never be 5
What kind of teams get 3-4 days?
Typical product/feature based dev teams.
Can be less for teams with architects, data scientists, QA, devops
Pull request response time
Why:
Metric:
Settings to Apply:
Tracks time to response on PRs, as well as approvals and time to merge
Use averages instead of medians (PRs skew overly positive on median)
Old pull requests get stale
Ideally between 1-3 days
Refined backlog ready to work
Why:
Metric:
Settings to Apply:
Try burndown with filters to match team’s backlog
Pick an issue state that represents refined work.
By story points
Open defects by priority
Why:
Understand how quality is impacted by your focus on efficiency and speed.
...