How to decompose user stories into tasks?
Recently I was looking at the sprint backlog of a team, which just started their agile journey. When I looked at the task break down of the user stories, I noticed something like this.
User Story
- Coding
- Testing
- Check-in
- Build
- Demo
Looking at this task breakdown, I initially felt it as a sequential process steps defined as tasks for a story. I also noticed that every story had the same task break down with different effort estimates. I was looking at their done criteria of a story. I could not really relate their Definition of Done (DoD) and their task break down. Immediately, I asked one of the team members, “How do you make sure that you complete every task listed in the DoD? “ He stared at me with a confused smile, and said “We just do it! Sometimes there were tasks, we forget few of them and will get them done in the next sprint!”
Ah! Here is the catch…
I see that the task break down of the team just reflects a sequential process and doesn’t convey anything meaningful about what is happening with that story! Moreover, the task “Coding” doesn’t convey how much portion of coding completed for a specific story.
I also found a similar pattern of task splitting with other team’s sprint backlog too!
Somehow, I find that many teams are struggling to do an effective task down of a user story!
A task is simply a piece of activity that is required to get a story done. Here are some effective tips for breaking down a user story into tasks.
- Pen Meaningful tasks
Describe the tasks in such a way that they convey the actual intent. For example, instead of saying Coding, describe the tasks as “Develop the login class”, “Develop the scripting part for login functionality”, “Develop the password encryption for the login functionality”, “Create user table and save the login data to DB” etc.. Such tasks are more meaningful rather than just saying coding and testing.
- Use Definition of Done as a checklist.
Let us see what a DOD is very quickly. DOD defines the completeness criteria of a story. It includes all items that have to be completed to claim that the story is done by the development team. A simple example:
- Acceptance criteria is verified during testing
- Coding tasks completed.
- Exploratory Testing completed and signed.
- Regression test reviewed and passed.
- Unit testing – written and passed.
- Code reviews conducted.
- Defects are in an “acceptable” state to the Product Owner.
- User story accepted by the product owner.
- Regression tests run and passed
- Smoke / automation tests run (if applicable)
- Check for memory leaks
- Automated unit tests are checked in
Now how do you ensure that all items of DOD are done by the team? One way is to use the DOD as a checklist to come up with tasks for the user story so that the team can take each one of them and complete without forgetting.
- Do not have too small tasks, it is an overhead
Another syndrome I have seen is tasks which are very small, broken down to a minute level like, 10 min, 30 min, 5 min tasks, for example: Write Accept User Name Password, Validate Login, and Give Error Messages. Breaking the user stories with too many details is an overhead. What is the ideal size of the tasks?
One guideline is to have tasks that span less than 8 hours so that each one of them can be completed in at least a day.
- Avoid explicit testing task at unit testing level as far as possible
If possible, prefer unit testing not to be a separate task and be part of the implementation task itself to encourage people to practice TDD approach. However, this practice may not be ideally suitable for new Scrum teams.
- Do not have very big tasks
Do not have too big tasks that span across days together as we really do not know the actual progress.
In, some mature teams, I have seen, they do not do the task break down at all. They just pull in the user stories and complete them, but it is journey for new Scrum teams to get there.
So, how often do you think, as a team, you have to revisit the DoD, so that your task breakdown may change?