...
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.
Metric:
Velocity, by issue count or story points.
Settings to Apply:
Group series by parent properties to represent your team’s roadmap parent type.
Filter out “Won’t Do” statuses via Advanced Filters
Utilize a pie chart and look at all work completed over the past 60 or 90 days.
Velocity
Why:
Understand if your team is consistently delivering based on their estimation and pointing.
Metric:
Velocity
Save a view by issue count (to avoid hiding unestimated items) and story points.
Settings to Apply:
Use a default view utilizing story points or issue count based on how your team estimates work.
Filter out “Won’t Do” type statuses using advanced filters.
Group by month to
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
avoid the inconsistencies of weeks.
Sprint Attainment (for Scrum Teams)
Why:
Understand if your team is correctly committing to planned work.
Determine if interruptions are coming into your sprints after the start.
Metric:
Committed vs Completed
Settings to Apply:
...
Using the “Descendants of” selector, choose the individual sprints that your team wants to track.
Goas to Consider:
Did we complete all of the issues committed to at the beginning of the sprint and meet our goal?
Threshold goals can vary, but a standard goal is between 80-90%
Committed vs Committed Completed
Filter by project or individual sprint names.
Added vs Added Completed
Percentage changes over time
committed work completed during the sprint.
Cycle Time
Why:
Understand if your team is consistently sizing and estimating work.
Metric:
Cycle Time
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.
Story Points: Understand if the team is consistently pointing work of relative technical complexity and time.
Issue Type: Confirm the team has consistent definitions of work by issue type.
I.e. The smallest issue type (sub-tasks or tasks) should be work that is always completable within 2-3 days.
Aggregate by median to remove statistical outliers.
Filter out “Won’t Do” type states
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.Series grouping to consider:
Lead Time
Why:
Understand how quickly your team responds to high priority bugs, defects, and customer inquiries.
...
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.
Aggregate by median to remove statistical outliers.
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.
Metric:
Issue Time in State
Settings to Apply:
Aggregate by median
Group monthly
Defect/Bug creation over time - filter by backlog
...