PPPPPP - Proper Prior Planning Precludes Poor Performance

Abraham Lincoln said "give me six hours to chop down a tree and I will spend the first four sharpening the axe", and the parallel with software engineering is stronger than you might think.

The other day I came across a post on LinkedIn that began with:

❓"When did senior engineers start acting like every task needs to be fully scoped for them? Lately, I've heard devs say they want 'clean Jira tickets.'"

The author went on to argue that engineers should be comfortable working in high levels of ambiguity and that it's part of the job.

But here's the problem, even if you do find engineers who are okay with that, it won't last. Over time, ambiguity drains morale. The team won't stay happy or healthy for long.

💡Engineers need clarity before starting work.

Good tickets don't spoon-feed engineers - they provide context, direction, and boundaries. The thinking should be done before work begins, during refinement sessions, and by the team. That's where you align on goals, clarify expectations, and break down work into manageable, scoped pieces.

If your team has product people in it, chances are they've already:

  • Spoken with stakeholders

  • Considered customer feedback

  • Defined what the solution needs to do

⚙️ At that point, it's over to the engineers to figure out how to get from the current system to that desired outcome. Depending on the complexity, the work may go into the backlog as:

  • A single ticket

  • A group of tickets inside an epic

  • Or even as a task with sub-tasks (not my first choice, but some prefer it)

🗒️ Every ticket should include, at a minimum:

  • A meaningful title

  • A high-level description (including relevant background)

  • A clear objective - what is this ticket meant to achieve?

  • Acceptance criteria (I'm a fan of Gherkin syntax: GIVEN, WHEN, THEN)

  • Any developer notes, such as:

    • Steps to reproduce (for bugs)

    • Known issues or constraints

    • Actual vs. expected output (for bug reports)

Some teams use story points - mine don't. I don't believe in them (that's a post for another day).

Until a ticket has this level of detail, it's not ready to be worked on. Engineers should not be expected to start work until the scope is clear. A well-defined ticket allows the whole team to understand:

  • What value the work adds

  • What will change in the system

  • What "done" looks like

✅ If the acceptance criteria are met, the work is complete. If new ideas come up during review, they go into a new ticket. This is important because when scope expands during review, it slows everything down and encourages sloppy ticket writing in the future.

Engineers want tickets to pass review the first time. If things were missed, it's a failure of the team, not the individual (aside from their input into scoping, of course). Although that said, it's always better to catch a problem during review than after it's gone out into the world.

🗑️ Poorly scoped tickets create waste. 🗑️

When engineers dive into vague tickets, it leads to:

  • Long, frustrating reviews

  • Back-and-forth over what the ticket should have done

  • Urgent conversations with stakeholders mid-sprint

  • Tickets being pushed back and reworked

All of which slows progress and irritates everyone involved. 😠

If you want quality work done efficiently, scope it properly first. 👌