GUIDE 2025

How I’d set up a Jira agile board for useful flow

Josh Fechter
By
Josh Fechter
Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You…
More About Josh →
×

Start with the workflow

I would not begin by copying someone else’s Jira board. I would map how work actually moves from an idea or request to a usable outcome. The board should make that flow easier to see, not turn every activity into another status.

Before configuring anything, I would agree on the board’s users, purpose, work item types, ownership, and definition of done. A Scrum team may need a sprint view; a Kanban team may need flow policies and work-in-progress limits. The tool should follow the operating model.

What I would configure

I would choose statuses that represent meaningful states, keep transitions understandable, and make blocked work visible. I would add fields only when the team will use them for a decision. Clear descriptions, links to the product goal, and a lightweight definition of done usually help more than a dense screen.

I would set permissions and automation carefully. Notifications should help people act, not create noise. I would test filters, board columns, swimlanes, and dashboards with the people who depend on them before treating the setup as finished.

Review the board as a product

I would watch where work waits, how often items are reopened, and whether the board reflects reality. I would not use story points or a column count as a productivity ranking. If the board is full of stale work, the answer may be a prioritization or dependency problem rather than a new Jira setting.

I would periodically remove fields and rules that no longer help. A useful Jira board makes conversations about flow and trade-offs easier; it does not replace those conversations.

My bottom line

I use this approach to make the work clearer, not to add process for its own sake. Start with the problem, make the trade-offs visible, and revisit the decision when evidence changes.

If you are building the fundamentals behind this kind of work, the Product HQ technical product manager certification is a useful next step. I also share practical lessons in the Product HQ newsletter.

Josh Fechter
Josh Fechter
Josh Fechter is the co-founder of Product HQ, founder of Technical Writer HQ, and founder and head of product of Squibler. You can connect with him on LinkedIn here.