Beyond Velocity Charts

[Evan Fishman - Rally for Jira]

Everyone looks at velocity and burndown charts, but the real insights often hide in the Jira metrics we rarely check.

🟣Lead time - how long tasks actually take from start to completion.
🟣Sprint completion rate - not just what we finished, but what percentage of planned work consistently gets done.
🟣Issue reopening patterns - how often we revisit what we thought was complete.

These metrics reveal more about team effectiveness than velocity alone.

They show where processes break down and where we can make real improvements.

What Jira metrics beyond velocity have helped your team improve?

[Stephen_Lugton]

A big thing for us has been tracking what we are working on; one of the teams I run is a cross functional technology / marketing / digital team where we often have a number of different projects / activities going on at the same time and since this team uses a Kanban approach we don't have metrics like velocity and burndown charts available out of the box. 

To help us with tracking work and resource planning we do actually use story points with the Kanban board, and I can, and do,  use this to pull out throughput and velocity metrics with excel macro wizardry, but the main thing we report on is what we're working on (i.e. what epics) so we can show our stakeholders what we're focussing on and what the competing priorities are with a simple dashboard.

[Evan Fishman - Rally for Jira]

@Stephen_Lugton Tracking your team's progress via what you are working on makes total sense for your kind of team. I am pretty impressed by your workaround with Excel using story points, lol. Would need some insights into how you do that. 

[Dmitry Astapkovich _Colined_]

One of the most painful but useful exercise I've seen is capturing the initial scope and estimates (snapshot, table, static file, etc.) and cross checking the difference in the end of the sprint/iteration. Takes a lot of time and honesty/courage to go through but that helps a lot with realistic estimations in the future.

[Evan Fishman - Rally for Jira]

Love how you emphasized the painful part of this. I see how it could help with realistic estimations, though. I assume this is not something that would be done for every sprint? @Dmitry Astapkovich _Colined_ 

[Dmitry Astapkovich _Colined_]

@Evan Fishman - Rally for Jira , yes, that shouldn't be done every sprint since it's practically a walk of shame right before the planning session. 6-8 weeks feel like a good interval but again it does depend on your team. 


That pain I've mentioned actually is the only reason stopping me from developing a diff report app for Jira. We had an in-house solution over a decade ago for a game project with 100+ people. I can't imaging anyone paying for this tool willingly. It was pretty much a poking stick of unpleasant truth that you can't hide from. 

 

[Evan Fishman - Rally for Jira]

Thought as much. @Dmitry Astapkovich _Colined_ 

😅 definitely will bring up many unpleasant truths. But it seems like something that would help in the long run. 

 Would love to talk more about this on a call sometime. 💪🏻💪🏻

[Dmitry Astapkovich _Colined_]

@Evan Fishman - Rally for Jira , just let me know what time works you: da@colined.com

[Evan Fishman - Rally for Jira]

@Dmitry Astapkovich _Colined_ Will reach out. Thanks.