4. Ticket readiness and clarity

Date: 2025-10-01

Status

Accepted

Context

We sometimes begin work on tickets without a clear understanding of what’s involved, how to handle edge cases, or what the desired outcome looks like. This leads to:

• Wasted effort building the wrong thing
• Multiple iterations to clarify requirements mid-implementation
• Frustration when work needs to be redone or significantly changed
• Delays due to blocked work waiting for clarification
• Misalignment between what’s delivered and what stakeholders expected

While we acknowledge that Agile Methodology emphasizes frequent iterations and feedback from users and stakeholders, this doesn’t mean we should start work without understanding what we’re trying to achieve. We can iterate on the solution while still having clarity on the problem and the MVP scope.

Decision

Before starting work on any ticket, the engineer must verify ticket readiness by asking:

“Do I have enough information to proceed with reasonable confidence?”

Specifically, the ticket should provide:

1. Clear objective - What are we trying to achieve?
2. Acceptance criteria - What defines success/completion?
3. Scope boundaries - What’s in scope for this iteration, what’s out of scope?
4. Key edge cases - Are major edge cases identified (even if we decide to punt on them)?
5. Context and constraints - Any technical, business, or user constraints to consider?

When information is missing or unclear:

• Don’t start the work - Clarify first, code later
• Ask questions - Comment on the ticket with specific questions
• Propose solutions - If multiple approaches are possible, suggest options and get alignment
• Push back on the requestor - Request additional details, mockups, examples, or decisions
• Escalate if needed - Involve other engineers, product owner, or CEO to get clarity

What this doesn’t mean:

• We don’t need perfect specifications or waterfall-style documentation
• We can still iterate and gather feedback during implementation
• We can still use spikes to investigate unknowns
• We can still make reasonable assumptions when explicitly documenting them

The key is: We decide the MVP and iteration scope with clarity, not discover it through trial and error.

Consequences

Positive

• Reduces wasted effort on work that needs to be redone
• Improves alignment between what’s built and what’s expected
• Encourages better ticket writing over time
• Empowers engineers to push back on unclear requirements
• Reduces frustration and context switching
• Leads to more predictable delivery timelines

Negative

• May slow down the start of some work while clarification happens
• Requires engineers to actively evaluate ticket quality
• May create tension when pushing back on urgent requests
• Requestors need to provide more detail upfront

Neutral

• Creates a feedback loop that improves ticket quality over time
• Shifts some planning work earlier in the process
• Makes scope decisions explicit and visible
• Encourages collaboration between engineers and stakeholders before implementation

Review Schedule

Review after 3 cycles to assess:

• Are tickets generally better defined before work starts?
• Are engineers comfortable pushing back for clarity?
• Has this reduced rework and wasted effort?
• Do we need to provide better guidance on what “ready” means?