What’s the difference between a user story and a task?
Well that’s an easy question, I thought, the first time it was asked of me in a Certified ScrumMaster class. “The difference is …,” I began to reply and realized it wasn’t actually such an easy difference after all.
I’d been using the two terms, “user story” and “task” in my classes for years, and they seemed pretty distinct in my head. User stories were on the product backlog and tasks were identified during sprint planning and became part of the sprint backlog.
That was fine but wasn’t very helpful—it was like saying “salt is what goes in a salt shaker and pepper is what goes in a pepper grinder.” Sure, stories go on the product backlog and tasks go on a sprint backlog. But what is the essential difference between the two?
I paused for a second the first time I was asked that question, and realized I did know what the difference was. A story is something that is generally worked on by more than one person, and a task is generally worked on by just one person.
Let’s see if that works …
A user story is typically functionality that will be visible to end users. Developing it will usually involve a programmer and tester, perhaps a user interface designer or analyst, perhaps a database designer, or others.
It would be very rare for a user story to be fully developed by a single person. (And when that did happen, the person would be filling multiple of those roles.)
A task, on the other hand, is typically something like code this, design that, create test data for such-and-such, automate that, and so on. These tend to be things done by one person.
You could argue that some of them are or should be done via pairing, but I think that’s just a nuance to my distinction between user story and task. Pairing is really two brains sharing a single pair of hands while doing one type of work. That’s still different from the multiple types of work that occur on a typical story.
I have, however, used a couple of wiggly terms like saying tasks are typically done by one person. Here’s why I wiggled: Some tasks are meetings—for example, have a design review between three team members—and I will still consider that a task rather than a user story.
So, perhaps the better distinction is that stories contain multiple types of work (e.g., programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.
