Making user stories small is hard. I recently ran a story-writing session with a team and their clients. We brainstormed a dozen stories and then prioritized them. We took the top one and talked about how we could make it smaller and simpler. I knew little about the system and the background, so I asked some obvious questions and challenged everything. I bet I was a pain.
The first cut started with an and. The card said “real time and historical reports.” Whenever you see and, or, either, or but, look to split the card.
Fortunately, everyone in this meeting was open to splitting the stories. After awhile we had a multitude of stories derived from the first one.
Looking beyond Stories
Some teams only work with stories. Their stories make sense to the business and to the technical team, are deliverable quickly—a few days at most—and have value. This is probably the ideal situation, but it doesn’t work every time, and it can be difficult when a team is new to agile.
An alternative is to add epics and tasks. An epic is some big piece of functionality the business wants that is delivered via multiple smaller stories. Epics, by definition, break the rule that stories must be small, but they have the most business benefit. Tasks are smaller work items that build a story. They usually can be accomplished in a day or so, but by themselves they are devoid of business benefit.
Go Large with Epics
Sometimes, the business doesn’t want something small; it wants something big! Indeed, it might want more than one big thing. An epic might represent a milestone or notable delivery, or an epic can be a placeholder, something to break down into smaller pieces in future.
It makes sense to use the user story “As a …” format for epics, but there is no law that says you must. Just remember that who, what, and why are useful things to know.
Go Small with Tasks
On the other hand, it sometimes makes sense to break a story down into the work that needs to be done. In calling out the tasks needed to build a story, the development team engages in an act of shared design. Tasks are not normally written in user story format. Instead, they are written by the team, for the team, so use language the team will understand.
A task is a piece of work that needs doing, usually in order to build toward a bigger story. As such, it does not have independent deliverable functionality or generate business value, and, unlike a story, it normally is not a vertical (end-to-end) slice. Most tasks tend to be for programmers, but they could be for anyone on the team.