I had an interesting conversation last week about what our teams perception of a task, story and chore are and the differences between them. This then led to a discussion around task breakdowns and whether these were necessary.
This got me thinking………I’d never even considered this before, breaking a user story down into tasks is all I know. It’s like I’ve grown up with it. I never like to do things just because that’s the way were always done, like in the Pot Roast Story, so this gave me the ideal opportunity to lend it some thought and consider why I think breaking down a User Story into tasks is important.
What is a task?
A task is a small unit of work that can be literally or theoretically sized between minutes and hours. (I won’t cover the pros and cons of sizing tasks in this post) The task falls at the bottom of the natural breakdown hierarchy
- A Product Backlog is broken down into epics
- Epics are broken down into User Stories
- User Stories are broken down into tasks.
Tasks make up the smallest visible piece of the puzzle. It’s important to note here that tasks do not form any unit of business value, they are a list of practical things that need to be done in order to deliver the User Story as a unit of business value.
How does it fit into the Story process?
As the smallest piece tasks form the final piece in terms of identifiable work, therefore they often come at the last most point before work begins. This maybe at the iteration/sprint planning or may take place at a User Story kick off meeting immediately before the first task would begin.
Who does it have value for?
The mere existence of tasks has value for everyone immediately involved in the process including the developers, testers, scrum masters, product owners. This may also apply to any stakeholder depending on how close they are to the process. You may think that this is odd and that the User Story breakdown has no value for anyone other than the people working on the User Story, but there are 2 sides to this; the act of breaking down the User Story and the Visualization of this broken down work. Each side will have benefits to different sets of people.
Breaking down a User Story
The process of breaking your User Story down into tasks provides a collective and common understanding of the work that needs to be done. The discussion and review of the tasks can create further conversation on the scope of the work. If you choose to estimate tasks, whether or not you use that for planning or not, this may also give you an indication of how valid the estimation for your User Story was. This process add value for your team and the Scrum Master.
Tasks can also form non-code-specific items such as questions that need answering, assumptions that need validating or business as usual operations that you want to remind yourself to do as part of your delivery process. Tasks are a great way to achieve your definition of done. Without noting all of these things down whether they be on stickies or part of a check list they are a great way to make sure you have not forgotten anything.
Visualising your work
The second part of this process is visualising your work ( a key tenet in Kanban). By displaying your tasks in a visual way you are able to see the progress of the story as it moves through to completion. This is effective whether you’re using a Scrum Board or a Kanban Board.
The granularity of the tasks enables a Scrum Master to aid the team with their impediments and recognise bottlenecks without the need to rely solely on the teams feedback throughout the day. The board is always in the same place (hopefully) and your team as they move around and collaborate are not.
If you’re using physical boards and stickies the tasks also allow conversations to arise during the stand-ups where, just like index cards, team members can point, move or generally gesticulate at the specific items they want to talk about making it clearer to the rest of them team.
There are other ways of showing the progress of a User Story and maybe questions about whether people need this information at such a granular level, but on an information radiator this information is made available to all stakeholders and gives clear transparency whether they choose to use it or not.
Tasks are not compulsory by any means. They have some great benefits with little overhead and it works for me.