User stories can be divided without using subtasks
What is a User Story and a Task?
In software development and product management, a user story is an informal, natural language description of one or more features of a software system. User stories are often written from the perspective of an end user or user of a system.
A Task is simply a task. In agile, it would typically be something like code this, design that, create test data, validate test assumptions etc.
- Tasks are about implementation; User Stories are about definition.
Subtasks:
Subtasks are just tasks relates to a User Story.
Once all subtasks are finished User Story is finished.
Subtasks have no value for the user.
The Product owner is not interested in subtasks.
Subtasks are easier to estimate. This is usually the main reason to use them in Refinements Session. Do you really want to estimate?
The problem with subtasks
I'm going to start saying that there is no problem with subtasks the problems are related to how the team work with subtasks.
In my experience teams split user stories in subtasks when they are in the Refinement Session.
This is the very first time the Product Owner and developers talk together about the stories so in my opinion is too early to start deciding what to do. This goes against “Decide at the last responsible moment” principle.
Developers that will take that user story are in someway restricted to the plan created during the Refinement Session.
Apart from this problem another one comes. Let’s imagine that we split one user story in two subtasks, each one is taken by different developers. They both finish their subtasks but:
Who is the responsible for the user story?
Do we have another subtask for integrating both parts or at least verify that the integration is working?. Is this new integration subtask blocked until the others are finished?
Developer’s perspective change, and they think they have to finish subtasks. Seems that another one is going to fill the gap with the integration of those subtasks. Subtasks now are the way we communicate with members of the team.
Conway’s law
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Subtasks are sometimes created trying to communicate experts in different fields (frontend, backend, sysadmins, dba, etc). So we are once and again repeating the same architecture because we repeat once and again the same communication patterns. Just to say that this is not a problem if you and the rest of members of your organization are comfortable with the architecture.
With User Stories we have the opportunity to stop doing this and putting to work closely these different experts. It's not enough having all kind of experts in a team if we don’t start creating a T-Shape team, stop using subtask is a good starting point for doing this.
Big User Stories can be a problem because we will not be able to show progress during the development.
Big User Stories
This is the important point of working without subtasks. When subtasking big user stories we are taking a risk, we are saying that we are accepting that the whole story will be in production or nothing. The alternative is to split the user story in a set of small user stories. In reality this is always what we have to do, small user stories mean less risk to put something in production. So forcing teams to avoid using subtasks will produce a dialogue between the Product Owner and the developers to define how to split each big user story in small ones with value for the user (that’s the definition of the user story).
This cycle will finally produce to create stories of the same size so it will be not necessary to estimate again (NoEstimates).
There are a lot of techniques for splitting user stories but I like a lot SPIDR.
Just to finalize I’m not saying you don’t have to use subtasks, just they should not be the first option.