Jira Assessment

Jira is only as useful as the decisions it supports. This assessment looks at three things: whether the work in your instance is structured well enough to plan from, whether the board reflects what the team is actually doing, and whether the reports produce numbers a delivery leader can defend. Below is a breakdown of each scored question: what it measures, why it matters, and concrete steps to improve if your team scored low.

Score Interpretation

How to read your total maturity score (0 to 100).

1 to 20: Struggling. Jira is a place where work is logged after the fact, not a plan anyone works from. Stories are thin, sizing is missing or inconsistent, and the reports cannot be trusted, so forecasting happens in spreadsheets and status meetings instead.

21 to 40: Developing. The basics exist in places. Some stories are written well and some are pointed, but the pattern breaks down past the current sprint, and the charts still tell a confusing story because the underlying data is uneven.

41 to 60: Norming. The board holds up for the current sprint and the team can plan from it. The gains now come from the backlog beyond the sprint boundary, from consistent sizing, and from cleaning up the reporting so trends mean something.

61 to 80: Performing. Jira reflects reality. Work is structured, sized, and linked to larger outcomes, flow is steady, and the reports are close enough to the truth that leaders use them. Tune cycle time and the depth of ready work.

81 to 100: Thriving. Your instance is a genuine delivery asset. Planning, forecasting, and stakeholder reporting all run off the same data, and the team spends its energy on the work rather than on reconciling where the work stands.

Backlog Depth

How many sprints worth of work are in the backlog?

Why it matters: Backlog depth is the buffer between your team and an idle sprint. With less than a sprint of work staged, planning turns into a scramble and the team pulls whatever is closest to ready rather than what is most valuable. Depth also has an upper bound. When five or more sprints of detailed stories sit in the queue, much of that detail was written against assumptions that have already changed, and the team pays to maintain inventory it may never build.

To improve your score: Target two to four sprints of refined work and let the rest of the backlog stay coarse. Hold refinement on a fixed cadence so the top of the backlog is replenished before it runs dry. If you are carrying five or more sprints of fully detailed stories, archive or collapse the oldest items back into epics rather than grooming them again.

Sprint Goal Definition

Does the current sprint have goals defined?

Why it matters: A sprint without a goal is a list of tickets. The goal is what lets the team make tradeoffs mid sprint, decide what can be dropped when something breaks, and explain to a stakeholder what the two weeks were for. Teams without one tend to measure success by how many items closed, which rewards small safe work over the work that moves the product.

To improve your score: Write one sentence in the sprint description in Jira that names the outcome, not the ticket count. Set it during Sprint Planning with the Product Owner in the room, review it at the daily standup, and open the demo with it. If you cannot write a single goal because the sprint holds four unrelated efforts, that is worth surfacing to whoever is feeding the team work.

Board Configuration

Does the team use Scrum or Kanban configuration in Jira?

Why it matters: Either configuration scores full marks. Running both at once does not, because the two models produce different reports and different conversations. Scrum boards give you sprints, velocity, and burndown. Kanban boards give you continuous flow, WIP limits, and cycle time. Teams straddling both usually end up with a sprint that nobody protects and a flow that nobody measures, and the metrics from each become unreadable.

To improve your score: Pick the model that matches how the work actually arrives. If demand is planned and batched, use Scrum and hold the sprint boundary. If demand is continuous or interrupt driven, use Kanban and manage WIP and cycle time instead of velocity. Then configure one board accordingly and retire the second. If two work types genuinely differ, split them into two boards with clear ownership rather than blending them.

Acceptance Criteria

Are there acceptance criteria on user stories in the current sprint?

Why it matters: Acceptance criteria are where the team agrees what done means before the work starts. Without them, the definition of done moves during code review or testing, stories bounce back late, and the same story gets reopened after the demo. Criteria are also what a tester writes cases from, so missing criteria push quality work to the end of the sprint where it costs the most.

To improve your score: Make criteria a gate for pulling a story into a sprint, not a nice to have. Write them in a testable form, whether that is given, when, then, or a plain checklist. Cover the unhappy paths and any non functional expectation such as performance or permissions. In refinement, read the criteria aloud and ask the engineer and the tester whether they would build and verify the same thing.

Sprint Story Pointing

Are stories in the current sprint pointed?

Why it matters: Points on committed work are what make a sprint commitment checkable. Unpointed stories in an active sprint mean the team accepted work without agreeing on its size, which is usually a sign the story was not discussed. It also breaks the burndown, because effort disappears from the chart and the sprint looks healthier than it is.

To improve your score: Do not let an unpointed story enter the sprint. Size in refinement so planning becomes a selection conversation rather than an estimation session. If something urgent arrives mid sprint, point it as it enters rather than after it closes, so your velocity reflects what the team actually carried.

Backlog Story Pointing

Are the highest priority user stories in the backlog story pointed?

Why it matters: Sizing only the current sprint gives you a record of the past with no ability to forecast. When the top of the backlog carries points, you can answer the question every stakeholder asks, which is roughly when a set of work will land, using the team’s own throughput instead of a guess. It also exposes oversized work early, while there is still time to split it.

To improve your score: Keep the next ten to twenty items sized at all times and treat that as a refinement output. Points on unstarted work are provisional, so allow the team to resize when it learns something. Use the sized top of backlog with your average weekly throughput to produce a forecast range rather than a single date.

Fibonacci Scale

Does the team use Fibonacci for pointing stories?

Why it matters: The value of a Fibonacci scale is the gaps in it. Widening intervals force a choice between clearly different sizes instead of an argument over whether something is a six or a seven, and that speed is the point. Linear scales invite false precision and slow estimation, and mixed scales across a team make historical velocity impossible to compare.

To improve your score: Standardize on one sequence and post it where the team estimates. Anchor it with two or three reference stories the team has already finished, so a five means the same thing in March as it did in January. When an estimate lands above your agreed ceiling, treat that as a signal to split rather than a reason to add a larger number to the scale.

Largest Story Size

What is the largest story point on the board?

Why it matters: The biggest item on the board is a good proxy for how well the team splits work. Large stories hide unknowns, resist parallel work, and tend to sit in progress across a sprint boundary, which is what makes flow lumpy and burndown charts flat until the last day. A board topped by very large items is usually a board where the real risk has not been examined yet.

To improve your score: Set an explicit ceiling for what can enter a sprint and enforce it. Split by workflow step, by business rule, by data variation, or by happy path first, so each slice still delivers something demonstrable. If a story cannot be split, that usually means the team needs a short spike to reduce the unknown before committing to it.

User Story Format

Does the team use the story format “as a [role], I want to [action] so that [value achieved]”?

Why it matters: The format is not the goal, but it forces three answers a ticket often lacks: who this is for, what they are trying to do, and why it is worth building. Tickets written as implementation instructions strip out the user and the outcome, so engineers cannot make sensible judgment calls and nobody can tell later whether the work paid off.

To improve your score: Apply the format to product facing work and hold the “so that” clause to a real benefit rather than a restatement of the action. Technical enablers and defects do not need to be forced into the pattern, so give them their own clear template. Set the story description field default in your Jira project so the structure is there before anyone starts typing.

Task Usage

Does the team use tasks?

Why it matters: Not all sprint work is user facing. Upgrades, migrations, spikes, and operational commitments are real capacity, and teams that have no place to put them either hide the work inside a story or leave it off the board entirely. Either way the board understates what the team is carrying, and the velocity conversation becomes an argument about invisible work.

To improve your score: Use the task issue type for work that consumes capacity but does not deliver user value on its own, and size it the same way you size stories. Keep the distinction simple so the team does not spend refinement debating issue types. Then look at the split between stories and tasks over a few sprints, because that ratio is a useful conversation to have with a Product Owner.

Sub-task Usage

Does the team use sub-tasks?

Why it matters: This question carries a penalty rather than a reward, and that is deliberate. Sub-tasks fragment a story into pieces that do not carry points, do not appear in most reports, and let a story sit in progress while its children close one by one. Teams that lean on them usually have stories that are too large, and the sub-task list is a workaround for splitting work that should have been split in refinement.

To improve your score: Split the story instead. If a story needs five sub-tasks to be understandable, it is probably three stories, each independently demonstrable. Where the team wants a shared checklist for a single story, use the description or a checklist field rather than child issues, so the story stays the unit of flow and the reports stay readable.

Epic Linkage

Are the highest priority user stories in the backlog attached to a parent epic?

Why it matters: Epic linkage is what turns a list of tickets into a portfolio view. Without it, nobody can answer how much of this quarter went to a given initiative, which epics are nearly done, or what is left before a capability ships. Orphaned stories also tend to be the ones that arrive without a sponsor, so the linkage gap is often a prioritization gap.

To improve your score: Require an epic on every story before it can be prioritized, and treat an unlinked story as a question for the Product Owner rather than a data entry chore. Keep epics scoped to an outcome that finishes rather than a permanent bucket such as maintenance. Then use the epic report and roadmap view in your reviews so the linkage earns its keep.

Burndown Trend

Does the burndown chart indicate negative trends?

Why it matters: This is the second question that can take points away, because a burndown that trends the wrong way is evidence the sprint is not being managed. Scope added after commitment, a flat line until the final two days, or a line that rises mid sprint all point at the same underlying issues: work entering after planning, stories too large to move the line, or status updated only when something closes.

To improve your score: Look at the shape rather than the endpoint. If the line is flat then vertical, your stories are too big or the team batches status changes, so split work and update the board daily. If scope climbs after day one, agree a rule with the Product Owner that new work displaces existing work rather than stacking on top of it. Review the chart in the retrospective and name the cause instead of the number.

Cumulative Flow Consistency

Does the cumulative flow diagram have a consistent flow?

Why it matters: The cumulative flow diagram shows where work accumulates. Bands that widen over time are queues, and queues are where cycle time goes. A widening In Progress band usually means too much started at once, while a widening review or testing band means work is finished by developers but not finished by the team. Flat bands with sudden steps mean work is moving in batches rather than flowing.

To improve your score: Find the widest band and treat it as the constraint for the next two sprints. Set a WIP limit on that column and hold it, even when it means people help finish work rather than start new work. Make code review and testing a shared responsibility with an agreed response time. Then watch whether the band narrows, because that is a faster feedback loop than waiting on velocity to change.

Work Distribution

How evenly is work distributed across team members?

Why it matters: Concentrated work is a delivery risk and a retention risk at the same time. When two people carry most of the stories, the team’s throughput is capped by their availability, knowledge stays trapped, and a vacation or a departure stalls the sprint. Very uneven distribution also usually means the rest of the team is waiting rather than contributing, which is invisible on a burndown but obvious in cycle time.

To improve your score: Pull the assignee breakdown for the last several sprints and look at it as a team in a retrospective. Pair or ensemble on the work that only one person can do, and make knowledge transfer an explicit acceptance criterion on those stories. Rotate who takes the unfamiliar story rather than optimizing every sprint for speed, and check whether unassigned work is actually being blocked by a skills gap.

Backlog View Completeness

Which of the following does the team’s backlog view show for the next 10 stories?

Why it matters: This question scores six habits at once, because the backlog view is where all of them show up together: future sprint buckets created, the backlog ordered using the Priority field, the next ten stories pointed, descriptions and acceptance criteria present, stories linked to epics, and sprints aligned to a two-week cadence if you run Scrum. Any one of these missing is survivable. Missing several means planning is a rebuild every time rather than a selection from work that is already ready.

To improve your score: Open the backlog view with the team and fix it in one working session rather than spreading it across weeks. Create the next two or three sprint buckets, order the list with the Priority field so the sequence is explicit rather than implied, and push the top ten items through refinement until each has a description, acceptance criteria, points, and an epic. Then protect it by ending every refinement session with a look at the same view.

Sprint History in Jira

How many sprints has the team been actively using Jira? (Velocity Chart)

Why it matters: Every forecast you make depends on history, and history takes time to accumulate. One or two sprints of data tells you almost nothing, because normal variation looks like a trend. Around six sprints you can start to see a range the team reliably lands in, which is the point at which velocity stops being a talking point and starts being a planning input.

To improve your score: The only fix here is consistency, so protect the things that keep history comparable: the same board, the same sprint length, and points applied the same way. Avoid rebuilding boards or renumbering projects mid initiative, because that resets the chart. If the team is genuinely new, say so when you forecast and use a range from the sprints you have rather than a single number.

Days in Status

What is their six-week average for days in status? (Control Chart red line)

Why it matters: Days in status is the closest thing Jira gives you to a customer view of speed, because it measures elapsed time rather than effort. Long averages usually come from queues and handoffs rather than from hard work: waiting on review, waiting on a test environment, waiting on another team. Cycle time above three weeks also means feedback arrives too late to change anything within the sprint.

To improve your score: Break the average into the individual statuses and find where the days actually sit, since the fix for waiting is very different from the fix for building. Attack the largest queue with a WIP limit and a service expectation for review and testing. Split large stories, because size is the other main driver. Then track the trend of the red line over six weeks rather than reacting to a single outlier.

Weekly Throughput

How many points has the team completed weekly on average, over the last six weeks?

Why it matters: Throughput is your capacity signal. Points are relative and not comparable between teams, so the value here is in the stability of your own number over time and in whether it supports a credible forecast. Low weekly completion is worth examining rather than judging, because it usually traces back to oversized stories, heavy interrupt load, or capacity split across several efforts.

To improve your score: Do not chase the number by inflating estimates, because that damages the only thing that makes the metric useful. Instead look at what suppresses it: unplanned work entering mid sprint, stories that carry across boundaries, and time spent on work that never gets logged. Fix those and the number moves on its own. Report throughput as a range across the last six weeks rather than a single average.

Work In Progress Versus Done

How does the “To Do” and “In Progress” compare to “Done”? (Cumulative Flow Diagram)

Why it matters: This comparison is a fast read on whether the team is finishing at the rate it is starting. When To Do and In Progress dwarf Done, work is entering faster than it leaves, and the gap is inventory that ages, gets reworked, or gets abandoned. It is also the pattern that produces heroic end of sprint pushes, because the team is carrying far more open work than it can close.

To improve your score: Stop starting and start finishing, in the most literal sense. Set a WIP limit for the team and hold the line for two sprints so the Done band can catch up. Sequence the backlog so only the top items are pulled, and finish what is closest to done before opening anything new. If the To Do band keeps growing regardless, the problem is intake, and that is a Product Owner and stakeholder conversation rather than a board configuration change.

Velocity Trend

How has the team’s velocity changed over time?

Why it matters: Direction matters more than magnitude, and erratic velocity is treated as worse than a slow decline for a reason. A stable or rising trend means the team is predictable enough to plan around. A swinging trend means something outside the team’s control is dictating the sprint, whether that is unplanned work, shifting membership, or estimates that mean different things from sprint to sprint. Erratic teams cannot forecast, so their commitments stop being believed.

To improve your score: Chart the last six sprints and annotate the outliers with what actually happened, because the story is usually obvious once written down. Stabilize the inputs first: hold sprint length constant, keep team membership steady, and cap the unplanned work that enters after planning. Re-anchor estimates against two or three completed reference stories so a point means the same thing over time. Look for a narrowing range before you look for a rising number.