When should I use user stories and when just tasks?

Question

I'm not sure if it makes sense to always write user stories, even for issues like refactor or backup.

In your opinion in which of the following situations, it's better to write user stories than tasks:

• features
• bug fixes
• additional tests
• refactor
• documentation
• continuous integration
• integration (GitHub with Slack, Jira with Slack...)
• error handling
• vulnerabilities fixes
• deployment
• performance improvement
• research
• import of data from another system
• appearance improvement
• portability improvement
• SEO improvement - database backup

Of course it's fine when I can write a user story to a feature and within this US tasks like UX, backend, frontend, refactor, research, SEO...

However sometimes after completing a user story we want to refactor, improve performance, improve appearance...

Answer 1

All the task types you mention can basically be grouped into feature and bug.

Features are planned and (unless very small) usually take the shape of a user story. Documentation and testing are definitely part of the corresponding feature, and so are research and refactoring if they are the precondition to starting the implementation.

Bugs, on the other hand, crop up unexpectedly and cannot be scheduled, so I wouldn't try to force them into the backlog. However, you should take your current bug load into account when estimating how much time you'll have available at the beginning of a sprint.

Dealing with technical debt falls somewhere between these two lines. By this I mean things that are not strictly implementable features themselves but still need to be dealt with at some point: refactoring, tech upgrades, low-prio bugs, additional tests, documentation updates, but also independent research such as tool evaluation.

All of these can be planned and thus should be treated as tasks that, in turn, can be bundled in a story wherever it makes sense. (For example, you could create a story to add tests for big feature BF, then add one task per class involved in BF that's still missing tests.)

---

Rules of thumb:

• A story can be finished in a single Sprint.
• A task can be handled by a single person in a reasonably short time frame (around 1-3 days).
• If a task can be easily split and worked on independently (or even consecutively) by different people, it's still too large.

---

If a feature is expanded on after its initial completion, you can simply create a new story for the second iteration of said feature.

UX is a good example where you'll pretty much always need a second (or even third) iteration to incorporate feedback. Since you know this in advance, you could already take that into account when creating your backlog: Instead of creating a single story and expecting to be done with it at the end of the sprint, you could already prepare a second (presumably smaller) story for the inevitable polishing, bug fixes etc. Worst case, you won't end up needing one of the iterations and can delete them from the backlog.

Answer 2

What is your definition of done, and is it still accurate?

When I read "However sometimes after completing a user story we want to refactor, improve performance, improve appearance...", it sounds like the user story was not completely Done the first time. To prevent this you should include performance/appearance/code quality in the DoD if it applies in general or use story-specific acceptance criteria. All of these activities could be subtasks for a user story.

However, there might also be valid reasons why these tasks are not included in the original story. I worked on a product where for external reasons we could not ship to production for a while, and where the end users (including the product owner) needed a short feedback cycle to figure out what they wanted. In that project, we'd start with a very raw basic version of a feature (deliberately excluding lay-out, texts/translations and technical optimizations) with just enough functionality for user-testing. Follow-up requirements would then go into a follow-up user story.

---

The different issue types we used in a particular project (after some trial and error, this scheme worked best for this particular team + product owner):

• User story for features and functionality, written from an end user perspective and having immediate business value
• Bugs for things that should already/still work but behave incorrectly (having a separate issue type is helpful if you want to track the amount and resolution time)
• Technical story for everything that is necessary for the end product from a technical perspective but is too technical for the product owner to understand or prioritize
• Task for anything else the team needs to do that takes a significant amount of time. Rarely used, mainly included so that the scrum board would give an accurate picture of what the team was working on at any time.

Answer 3

we want to refactor, improve performance, improve appearance...

Even if these aren't 'traditional' user story fodder, the benefit (I find) in user stories is focusing on an outcome rather than just a task, and giving freedom to the development team to work collaboratively and creatively to solve a problem and meet that outcome, as opposed to 'completing a task'.

Using the "as a role I can action so that outcome" approach to writing user stories could help with this.

I.E. "As a site user, I want the site to perform quicker so that I can do more on it in 'X' period of time". Crap example, I know, but hopefully you catch my drift.