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.
We are pretty new to Scrum and are experiencing the same thing. If the stories are too broad, most of our story points only get complete at the end of the sprint and we can’t really see the progress. However, splitting up the points to specific tasks can be very time consuming and not always thorough as the developers discover things as they go. Any advice on finding the ‘middle’ ground would be appreciated!
Hi Celeste,
It’s hard to offer much advice without knowing more. Reading your post, though, I’m not sure about some things, so to clarify — you want to estimate your stories using story points but not your tasks. Tasks are usually estimated using hours (a good one is fibonacci numbers) or relative sizes (XS, S, M, L, XL).
You may want to try applying some more constraints, in other words don’t have stories that are estimated to be longer that 2-3 days, and aim for tasks that can be completed in a half day or less. This could mean more prep work, depending on the domain and technical knowledge your team has. It also depends on the length of your sprints — are they a week or four weeks or somewhere in between? The longer the sprint the harder this will be.
Another good constraint taken from Scrumban is to limit the number of stories that can be worked on at once (e.g. if you have 15 stories on your board with a team of five, only allow two or three to be worked on at one time). We physically put paper in front of the other stories to remove the distraction.
Good luck!