Breaking down user stories into tasks
After reading User Stories Applied by Mike Cohen, as well as several articles and blog posts, I’ve come to the conclusion that there is a dearth of specific advice out there on how to break down user stories into tasks. Cohen suggests breaking them down by CRUD functions, using data boundaries, and breaking stories into investigative spikes. This is a good start, but I was hoping to get more details or examples on the actual tasks, instead of just how to make stories smaller.
I’ve actually come to the conclusion that the best course of action would be to not break the stories down at all, as seen in Scrum-ban, but we’re not ready yet, and I’m not sure we will be in this project. So in the mean time we have to come up with a better way to break them down.
The team has typically been breaking them down into functional tasks (analysis, implementation, testing). The challenge here is that it tends to lead the group into mini-water-fall iterations of a story. The tasks also tend to be somewhat meaningless.
For our last sprint we tried being more specific (e.g. “query rate factors for coverage object”). The result was that the team got fairly deep into analysis during our planning session. If you break down your story into the specific tasks, you need to have a pretty good idea of how you’re going to execute the work before you start, which means there needs to be a lot of details available up front. But that goes contrary to the intentions of the story — it’s not a detailed requirements specification.
So what’s next? I think a middle ground is necessary. One thing Cohen mentions is that the team needs to have sufficient domain and technical knowledge to break down the stories. I agree and think that should be enough. It also drives home the point that team members can’t get away with only understanding the technology — they have to understand the business drivers and context of the application they’re building.
Of course, the big question is what that middle ground looks like. I hope to get some clarity out of our upcoming sprint review.