jiratechnicalAPP-041

The Jira-Burdened PM

#jira#project-management#agile#sprint#engineering

Aha Moment

“What was the moment this product clicked?” —

Identity

A product manager or engineering team lead at a software company who runs sprints in Jira. They did not set up the Jira instance they work in — it was configured by someone who left 18 months ago, and the workflow has accumulated technical debt as surely as the codebase has. They know what they need Jira to do. Getting it to do that is a separate problem.

Intention

What are they trying to do? —

Outcome

What do they produce? —

Goals

→Know at a glance what's in progress, what's blocked, and what's at risk — without a meeting
→Run sprint ceremonies that don't require 20 minutes of Jira housekeeping first
→Give stakeholders visibility into progress without exporting a spreadsheet every week

Frustrations

—Ticket statuses that don't map to how engineering actually works
—Searching for tickets by description when they only remember what it was about
—Estimation that the team doesn't trust and leadership takes literally
—The gap between Jira's view of the sprint and what's actually happening

Worldview

Project management should serve the team, not the other way around
Any system engineers have to be repeatedly reminded to use is the wrong system
Velocity as a metric tells you about the past; the backlog tells you about the future

Scenario

It's Monday morning before sprint planning. The board has 11 tickets in "In Progress" from the sprint that technically ended Friday. Three of them are done — the engineers just didn't update them. Two are genuinely stuck and nobody told them. Six need to be carried over. Sprint planning starts in 45 minutes and the board doesn't reflect reality. They are manually updating tickets right now.

Context

Manages a team of 5–12 engineers across a 2-week sprint cycle. Spends 60–90 minutes per day in Jira. Also works in Confluence, Slack, and at least one Google Doc that should have been a Jira ticket. Has tried three different board configurations in the past year. Has a filter saved called "Actually Important" that they built themselves. Attends a Jira admin when something breaks. Considers their admin a minor deity.

Impact

→Boards that reflect reality without manual cleanup before every ceremony save 45 minutes per sprint
→Better search across ticket history means less time asking engineers "what was that ticket?"
→Stakeholder dashboards that update automatically eliminate the Friday reporting tax
→Clearer blocked/at-risk signals surface problems before they become sprint failures

Composability Notes

Pairs with `software-engineer` to map the gap between ticket creation and actual development workflow. Contrast with `linear-user` to surface why newer tools are winning the sprint management segment. Use with `engineering-manager` for planning ceremony design and sprint health metrics.