Tools & Metrics

Jira is the most powerful and most abused project management tool in the industry. I have seen Jira instances with 14-status workflows, 30 custom fields, and boards so complex that engineers spend more time navigating the tool than writing code. That is tool-serving-process instead of tool-serving-people.

The best Jira setups I have built share a common trait: simplicity. The tool should reflect how work actually flows, not how management wishes work would flow.

The 5-Status Workflow That Works

After experimenting with dozens of workflow configurations across different team sizes and domains, I have settled on a five-status workflow that works for 90% of software delivery teams:

Why not more statuses? Because every additional status is a transition someone has to remember to make. "In QA" as a separate status from "In Review" makes sense in theory. In practice, it creates a dead zone where tickets sit in the wrong column because someone forgot to move them. If your team has a dedicated QA function, you can add "In QA" as a sixth status. But test it for two sprints before committing.

Practical Jira Configuration Tips

• Use the "Ready" column as a quality gate. A ticket moves from Backlog to Ready only when it has acceptance criteria, an estimate, and no open questions. This prevents poorly defined work from entering the sprint.
• Set WIP limits on "In Progress" and "In Review." Jira supports column constraints on Kanban and Scrum boards. Use them. A visual warning when a column exceeds its limit is a gentle nudge toward flow discipline.
• Minimize custom fields. Every field you add is a field someone has to fill out. Start with the defaults: summary, description, story points, assignee, priority. Add custom fields only when you have a specific reporting need that cannot be met otherwise. I have seen teams with 25+ custom fields. Nobody fills them all out. The data is garbage.
• Automate transitions where possible.Use Jira automation rules: when a PR is opened in GitHub, move the ticket to "In Review." When the PR is merged, move to "Done." This eliminates manual status updates and improves data accuracy.
• Use labels sparingly, components wisely. Labels are uncontrolled text that becomes inconsistent over time ("frontend" vs "front-end" vs "FE"). Components are admin-controlled and consistent. Use components for team areas (API, Web, Mobile). Use labels only for cross-cutting concerns that span components (tech-debt, security, accessibility).

The metrics you track shape the behavior you get. Track the wrong metrics and you incentivize the wrong behaviors. Let me break down the three most important delivery metrics and how to use them correctly.

Velocity: A Planning Tool, Not a Performance Metric

Velocity is the number of story points completed per sprint. It is useful for one thing: sprint planning. If your team has averaged 35 points over the last 4 sprints, you should plan for roughly 35 points next sprint. That is it. That is the entire value of velocity.

Cycle Time: The Metric That Matters Most

Cycle time measures how long a work item takes from the moment someone starts working on it ("In Progress") to the moment it is done ("Done"). This is the single most actionable metric for delivery improvement.

Why cycle time matters more than velocity:

• It is objective. No estimation inflation possible. A card either took 3 days or it took 7. The clock does not lie.
• It measures flow efficiency. If your average cycle time is increasing, something in your process is getting slower, whether that is code review bottlenecks, environment issues, or unclear requirements.
• It is predictive. Once you know your cycle time distribution, you can tell stakeholders with confidence: "85% of our stories complete within 5 business days." That is a far more useful statement than "we do 35 points per sprint."

Target cycle times vary by work type. For a well-functioning team: bug fixes should average 1-2 days, standard stories 3-5 days, and larger features (broken into stories) should still have individual stories completing in 3-5 days. If any story takes more than 8 days, it was either too large (split it) or got blocked (investigate).

Lead Time: The Customer's View

Lead time measures the total time from when a request is created to when it is delivered. This includes all the time the ticket sits in the backlog waiting to be prioritized, refined, and started. Lead time is what the customer experiences. Cycle time is what the team controls.

Lead time = queue time + cycle time. If your cycle time is 4 days but your lead time is 30 days, you do not have an execution problem. You have a prioritization problem. Work is sitting in the backlog for weeks before anyone touches it. That might be acceptable for low-priority items, but if high-priority customer requests have a 30-day lead time, your intake process is the bottleneck.

Most delivery dashboards are data graveyards. Someone builds them, shows them off in a meeting, and then nobody looks at them again. The reason is always the same: the dashboard displays data, but it does not answer questions.

A good dashboard answers one question at a glance. A great dashboard answers three questions. A dashboard that tries to answer ten questions answers none.

The Three-Dashboard Model

I recommend three dashboards, each serving a different audience and cadence:

The weekly status report is either the most valuable artifact you produce or the biggest waste of your time. The difference is whether it answers stakeholder questions or just documents activity.

After years of iteration, I have settled on a format that every stakeholder, from the engineering director to the business sponsor, can scan in under two minutes and get what they need.

The Two-Minute Status Report Template

The Art of the RAG Status

Red/Amber/Green status is deceptively simple. The problem is that most PMs default to Green because Red feels like failure. This creates a pattern called "watermelon status": green on the outside, red on the inside. The project looks healthy until it suddenly is not.

Here is how I calibrate RAG:

• Green: On track to hit the committed scope and date. No unmitigated risks. The team is operating within normal parameters.
• Amber: A risk or issue exists that could affect scope, timeline, or quality if not addressed. You have a mitigation plan. You may need a decision from leadership. This is the most useful status because it invites help before things break.
• Red: Scope, timeline, or quality will be impacted unless leadership intervenes. You need additional resources, a scope cut, or a timeline extension. Red is not failure. Red is transparency. The PM who goes Red early gets help. The PM who stays Green until deadline day gets blame.