Work on tasks, not stories
Monday, March 11, 2024
One tenet of big-a Agile1 is that developers should all work on individual user stories as the smallest unit of work2. That a ticket should almost always be a story, because that means it's something that delivers concrete value to the users.
There are some cases in which this leads to absurdity. I've written tongue-in-cheek tickets of this type at work before, on a platform team:
- "As a DAYJOB engineering team, I want..."
- "As a configuration file, I want..."
I've also seen this done as a serious story, or Poe's law struck and it's impossible to tell if it's satire.
This has it all backwards. User stories are great for tracking what users should be able to do and how to deliver value. But they're not great for understanding the work to be done.
A story can require a surprisingly large or small amount of work. You don't know until you break it down by analyzing how to do the task that's behind the story. We end up doing this and using stories in a way that leads to convoluted ticket titles, which all but tell you what the hidden task actually is.
Instead, tickets should be honest and be a straightforward task:
- "Add port option to configuration file"
- "Make checkout button disabled if any fields are invalid"
These tickets can be related to stories, either multiple tickets to a story or one-to-one, but they are a far better mapping to the work done on an engineering team than stories are3. It makes it clear what is to be done, and it avoids convoluted stories for things that are just absolutely not user stories.
To be clear: you must still think about what the user needs, and think critically about the implementation at hand. It's just that writing it as a story doesn't give you this for free, just as writing a task does not. Writing a story masks the task behind a veneer, but it is still fundamentally a task. So if you have a task and the task does not clearly relate back to something that's needed for the user (or the org, or some useful purpose), then that's a great time to clarify why this task needs to be done. Maybe it doesn't!
But it's still a task, not a story.
This is to draw a distinction between the industry that's sprung up around "Agile", vs. the principles/practices recommended in the agile manifesto. The former is cargo-culted quite a bit and has some problems, while the latter says to emphasize flexibility over dogma.
See, for instance, this Atlassian article.
Splitting it up this way also makes responsibilities clearer: product management is responsible for creating stories, and engineering is responsible for creating the tasks to achieve those. Without this split, it's ambiguous and varies team-to-team and day-to-day.
If this post was enjoyable or useful for you, please share it! If you have comments, questions, or feedback, you can email my personal email. To get new posts and support my work, subscribe to the newsletter. There is also an RSS feed.
Want to become a better programmer? Join the Recurse Center!