Looking at this task breakdown, it felt like 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 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.
1. Create 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.
2. Use the Definition of Done as a checklist
Let us see what a DOD is very quickly. The 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
3. Create tasks that are right sized
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.
4. Avoid explicitly outlining a unit testing task
If possible, make unit testing not a separate task but part of the implementation task itself. This encourages people to practice Test Driven Development as an approach. However, this practice may not be ideally suitable for new Scrum teams.
5. Keep your tasks small
Do not have tasks that span across days together. Its makes it difficult to 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 a journey for new Scrum teams to get there, and requires a strong cohesive team, and many sprints of working together.
So, how often do you think, as a team, you have to revisit the DoD, so that your task breakdown may change?