Bugs, Spikes, Tasks
When a piece of work is not a story. Bug tickets that make the impact reproducible, spike tickets timeboxed to questions, and the plumbing work that genuinely belongs as a Task.
CSV export is broken
Acme noticed something off in their export.
CSV export drops the trailing comma in numeric columns
Reproduced on staging with the Q1 sales report (12 rows, 3 numeric columns). Open the export in any tool that respects RFC 4180 and the last numeric value is concatenated with the next row.
'Sometimes the file looks weird' is a starting point for a conversation, not a bug ticket. Without reproduction, scope, or expected behavior, the engineer is doing the bug investigation from scratch every time.
The right ticket gives reproduction steps, the surface the bug touches, and a test the engineer can write to prove the fix. Anyone on the team can pick it up cold.
Customers can pay with SEPA direct debit
We don't know yet which provider fits, but we want the flow shipped this sprint.
Investigate which payment providers fit our SEPA constraints
Time-boxed to one sprint. The work of integrating becomes its own Story after this spike lands.
A 13-point story with 'pick the best provider' inside it is a bet, not a plan. The team will burn the sprint discovering tradeoffs the spike could have surfaced in three days. 13 is a signal: split it or spike it.
When the team cannot estimate because the implementation approach is genuinely unclear, a timeboxed spike is the right move. Its acceptance criteria are answers to questions, not shipped behavior. The integration story comes after, with real numbers.
Sales reps see deals sorted by close date
Upgrade Next.js from 15 to 16
The subtasks read like plumbing, but the footer gives it away: every sales rep on the dashboard sees this change. That makes it a Story with acceptance criteria, not a Task. Filing it as a Task hides user-visible work from the demo.
Framework upgrade is plumbing. Nobody on the outside notices, the team tracks it because it has to happen, and Task is the right shape: real work, no user, no story framing.
Look into LLMs for support replies
See what's possible. Build a prototype if there is time.
Decide whether to use LLMs for first-draft support replies
Support handles ~120 tickets a day. Most are repetitive. The question is whether an LLM-assisted draft would save time without leaking PII.
'See what's possible' is a curiosity, not a spike. With no question to answer and no time bound, it expands to fill the sprint and produces a half-prototype that nobody owns.
A spike is research. Its acceptance criteria are answers to specific questions and a recommendation. The timebox and 'no production code' line keep the work honest.
Users want infinite scroll on the activity feed instead of pagination
Several users have asked for infinite scroll in support tickets and the #feedback channel. The current pagination feels dated.
Activity feed loses scroll position when a new item is prepended
On Chrome and Safari, when a new activity arrives via WebSocket, the feed jumps to the top instead of preserving the user's scroll position.
'Users want X instead of Y' is a feature request, not a bug. Filing it as a bug ducks the prioritization conversation and lets it skip the line in front of actual regressions.
A bug is something working incorrectly against an existing expectation. Scroll-position drift on a feed update is a regression with a clear before/after. The acceptance criteria are reproducible.