breaking backlog work items down to subtasks is a good thing if it helps the team members who will be completing the work item to coordinate their work efforts.
However, if using them is imposed "from above", that is NOT a good thing.
I'd also discourage using them as a crutch to avoid slicing or splitting work items.
And, they can make it easier for team members to backslide into the "this is my activity, that is yours" mindset vs. the "we all OWN this work item" one.
Finally, remember that story point credit is given for completing a full work items, not just for individual sub-tasks within it.
Kiron Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I am in line with @Kiron. User Stories should not (perhaps I have to use must not) split into task. The same with story points that must not be translated into time. Saving Changes...
Kiron, Thank you, just want to clarify what you mean under "using them as a crutch to avoid slicing or splitting work items" Also about partial crediting, I know that some scrum masters do this when the team identifies in early sprint stages that the story is big enough to finish and splitts it in subtasks. But this is about team growth, when previosly were claimings like "we did 80 per cent of a story - give us some story point credits" Saving Changes...
Ganesh KumarProgram ManagerBangalore., Karnataka, India
Hello Jacob,
we use subtask, if we are creating a specific features, testing team will create subtask under that story. If multiple developers are working on the story they create subtasks for that story they will be doing. If we need UX, we will create UX subtask and we assign this to respective individuals so that they finish their subtask and mark it as done.
Until all the subtask of that story are marked as done the user story cannot be marked as completed.
Its an important feature of creating subtask and so that's the advantage of creating subtask.
The disadvantage is if people forget to mark their subtask as completed, and when you are closing the sprint, it cannot be closed until all the subtasks are closed.
Its also an advantage to ensure all the subtasks are closed for the sprint to complete. Since user stories are dependent on multiple stakeholders, in one story we can track all the dependencies, tag people to complete their subtask, instead of creating stories for individual stakeholders.
