Mike Lyons uses a pilot/checklist analogy to argue that teams should detail (task out) user stories. He differentiates user stories and tasks by duration (stories: sprint-sized; tasks: roughly day-sized), by ownership (stories may involve multiple roles; tasks should be single-person), and by user value (stories deliver user-facing value; tasks sometimes do not). He advises teams—especially when starting—to break stories into tasks to build shared understanding.
Think about the last time you went on a commercial flight. You sat in your seat, you fastened your seatbelt, and the flight attendants are giving the sort of, you know, safety review thing. Well, up in the cockpit, the pilot and co pilot, they're busy going through a set of checklists. You know, they're checking the fuel levels and they're checking the wind speeds and they're verifying with the tower, the Runway and the taxiway. And they're doing, they're walking through a set of checklists. They're preparing, preparing the plane to get ready to go. Now it may be the first time that they've ever flown, I hope not. Or it may be the hundredth time, you know, but even the most experienced pilot goes through the checklist to make sure that she hasn't forgotten anything. I sort of have long associated the checklist to creating tasks for user stories. Now some people will argue with me and say, well, the user story can be small enough. I don't necessarily need tasks. Oh, look, okay, let me, let me say this. When you're starting out, I want you to task out your stories. Okay? Like you need to do this. Even experienced pilots have a checklist. So, so, okay, so what's the difference between a user story and a task? One is a user story must be completed within a sprint. We know that a user story will be completed within a sprint. A task should roughly be completed within a day. You don't want user stories that can be completed within a day. Those are probably tasks. And you don't want tasks that take three or four days to do. Those are probably user stories. So there's this sort of component about how long the thing might take. But let me also add this. User stories typically will be completed by more than one role. For example, there could. A user story could have some design elements where we need to bring in some UX expertise. It might have some build. Well, for sure it'll have something we build and it needs to be tested and then potentially deployed. Those may be the same person. They may and likely are actually different people. Certainly they're different roles. So depending on how your team is organized, user stories could be, could be worked on by different people. Tasks, however, should be done by one person. So for example, a user story that has design, build, test and deploy. Well, part of it is testing that might be done. That task might be done by one person. The development might be done by a different person. And just one more difference between user stories and tasks. Consider that user stories always have that user facing element to it. Right. We've talked about this. The user story has some sort of value delivery to a user. A task may not. For example, a task to create a database doesn't in and of itself provide value to an end user. Super important, and we totally need to do it. Absolutely. But. But those are the types of things where the users just expect that that will be there. They don't necessari about the database. So think about it that way. User stories have that user value delivery tasks may not. The key takeaway is this idea, this idea of detailing stories so important for teams to do because again, we're getting to shared understanding. We really know a lot about what we're building and what we're testing, what we're deploying. And so tasking or detailing of stories is very common practice and one you should get familiar with on your teams.
