Software development tickets: stories, bugs, spikes and technical work explained

Ticket types clarify the kind of decision being made

A ticket is a shared record of work, not a substitute for a conversation. Its type should help people understand why the work exists, what evidence is needed and how it should be prioritised.

Calling every item a user story creates confusion. A production defect, an investigation and a customer capability have different starting points and different definitions of done. Giving them distinct names helps the team avoid pretending that all work has the same shape.

Keep the system simple enough that people use it consistently. The purpose is useful context, not an elaborate taxonomy that requires a meeting to create a card.

User stories describe a valuable change in behaviour

A user story describes an outcome for a person or another system. It normally explains who needs something, what they need to do and why the outcome matters. The familiar format “As a…, I want…, so that…” can help, but a plain description and concrete examples are often clearer.

A story should be small enough to deliver and learn from, but substantial enough to be meaningful. It may contain design, implementation, testing and deployment work. Splitting those into separate tickets can hide whether the user-facing outcome is actually complete.

Define done through observable behaviour and relevant constraints. For example, a user can download a report, only authorised users can access it, and the audit event is recorded. Avoid acceptance criteria that merely list implementation tasks.

Outcome: An account holder can download their annual statement.

Why: They need evidence of their account activity without contacting support.

Examples:
  - A signed-in account holder can request one statement for a selected year.
  - Another account holder cannot access it.
  - The download request is recorded for audit.

Bugs describe behaviour that is wrong now

A bug records an observed difference between expected and actual behaviour. Start with what happened, who or what was affected, the environment or version, how to reproduce it and any evidence such as an error code, log reference or screenshot.

Do not label a missing requirement as a bug merely because somebody expected different behaviour. First establish whether the product rule was known and implemented incorrectly, or whether the rule itself needs a decision. That distinction affects priority, ownership and the eventual fix.

A bug is done when the reported behaviour is corrected, the underlying cause is understood enough to prevent an immediate repeat and the appropriate regression evidence exists. For a high-impact issue, include the mitigation, customer impact and follow-up actions as well.

Spikes buy down uncertainty before committing to a solution

A spike is a timeboxed investigation. It is appropriate when a team cannot yet estimate or safely choose an approach because an important fact is unknown: whether an integration supports a flow, whether a query can meet a performance target or whether a migration route is viable.

The output is knowledge, not production code. A good spike states the question, the time limit, the evidence to gather and the decision it should enable. It may produce a prototype or a small experiment, but that artefact should not quietly become the production implementation without normal review.

End a spike with a clear result: proceed with option A, investigate option B, defer the work, or create follow-on stories with a more credible estimate. An investigation that has no decision question can expand indefinitely.

Question: Can the existing provider return a signed document within five seconds?

Timebox: Two engineer-days.
Evidence: Provider documentation, a sandbox request and latency measurements.
Decision: Choose synchronous download, asynchronous generation or another provider.
Output: A short recommendation and follow-on work.

Technical stories improve the system while supporting future delivery

Technical stories describe work whose main value is to the engineering system: upgrading an unsupported dependency, adding an index, replacing an unsafe library, improving deployment recovery or creating a needed service boundary.

They are still outcome-oriented. “Upgrade framework” is a task; “the service runs on a supported framework version and passes its production checks” describes the result and the evidence needed. Explain the risk being reduced or the capability being enabled so the work can be prioritised honestly.

Do not force a fictional end-user benefit onto every technical story. A team can state the engineering value directly, including security support, reduced operational risk, lower change cost or an upcoming platform constraint.

Chores are small maintenance tasks with a clear owner

Teams use chore for low-complexity maintenance that does not need discovery or a full story, such as rotating a test credential, updating a runbook link, deleting obsolete configuration or renewing a certificate.

The label should not become a hiding place for important technical work. If an item changes customer behaviour, carries operational risk or needs a trade-off decision, give it enough description and review to match that impact.

Keep chores visible in planning if they consume meaningful capacity. A backlog that tracks only feature stories creates the false impression that maintenance and operational work are free.

Incidents track urgent service disruption and learning

An incident is an active or recent disruption that affects users, data, security or a service objective. It needs fast coordination, a clear incident owner, regular communication and a record of the mitigation taken. It is not simply a high-priority bug.

After recovery, create follow-up work for the contributing conditions: a code defect, missing alert, unclear runbook, capacity limit or product decision. Keep the incident record focused on impact, timeline and response; use linked tickets for changes that need ordinary planning and review.

Blameless learning matters here. The aim is to understand how the system and its safeguards allowed the failure, then improve them, rather than assigning fault to the person who was closest to the final action.

Use tasks as children of a clear outcome

A task is a concrete action such as add a migration, update a client, prepare test data or arrange a review. Tasks are useful when they sit beneath a story, bug, technical story or incident follow-up that explains why the action matters.

A board filled only with tasks makes delivery hard to understand. It shows activity but not whether the customer outcome, risk reduction or decision has been achieved. Keep the parent item visible and update it with the evidence of completion.

When a task reveals a new unknown or a larger outcome, promote it to the appropriate ticket type rather than letting a vague action card absorb more work.

• Use a story for a valuable behaviour change
• Use a bug for observed behaviour that differs from an agreed expectation
• Use a spike for a timeboxed question that enables a decision
• Use a technical story for an engineering outcome or risk reduction
• Use a chore for small, clear maintenance work
• Use an incident for active or recent high-impact disruption
• Use tasks beneath the item that explains the outcome and priority