Embedded Files
Overview
Overview
By breaking down work into smaller items, there’s less room for error, dependencies and wasted time through misunderstanding or confusion - as well as the work at the end being simpler to review and implement.
Introduction
Introduction
Breaking down work can be tricky but is a key part of working in an Agile way. It requires an understanding from the whole team on what the end goal is on each part of the work whilst also trying to make sure there aren’t any dependencies between the individual parts.
How to Break Down Work
How to Break Down Work
If you were making a cake you might just have two items on your list; “bake cake” and “decorate cake”. However each of those steps has a wide range of sub-tasks and things to do, so a better way to break this down would be to have each part as an individual task. This means that other people could help with those smaller parts and means if one part goes wrong, it doesn’t affect the whole cake. So for example, you might have “measure ingredients” as one task, and “pre-heat oven” as another.
This translates to how workplaces use Agile as well and is a key part of backlog review and sprint planning. We should always be challenging ourselves to break tasks down into their smallest components. Not only does this allow for better team collaboration but it also means that when reviewing or testing, the workload is lighter on whoever is doing the checking.
In addition, following that testing or reviewing (perhaps by stakeholders), you can quickly adapt your plans before it’s too late - in our example, checking the ingredients are right for the cake and actually finding the stakeholder wants a different flavour now.
In terms of the individual tasks you raise, a good model to follow is Bill Wake’s INVEST:
A lot of this is business jargon, but the principles are good as overall themes; tasks need to not depend on each other as much as possible, should talk about the “why” not the “how”, have a purpose, be achievable by the team and be as small and testable as possible.
There are many ways to split stories down, including:
- by workflow steps (e.g. Step One: As a baker, I can measure out my ingredients so everything is ready for my cake. Step Two: As a baker, I turn the oven on so it’s ready for my cake to bake)
- by input options / platform (e.g. As a team member, I can view the Scrum Board on my desktop...)
- by test scenarios / test case (e.g. Test case 1: If an employee is already assigned to a workflow step, they cannot be assigned to another task)
- by roles (e.g. As a journalist, I can write an article VS As a reader, I can view an article)
- by browser compatibility (e.g. As a customer, I can view product details in Internet Explorer 7)
- by number (e.g. As a stockist, I can load one product and see how that looks before I load them all)
The way you break this down will depend on how you like to work. Some teams will prefer individual tickets for each component. Some like subtasks off a main ticket as more of a checklist for the overall item - you need to try a few options to see what suits the whole team and your stakeholders best.
Summary
Summary
Always challenge yourself and your team to make sure tasks are broken down as much as possible to speed up delivery, allow less room for error and be in a position to change direction quickly if required.
Further Resources
Further Resources
Report abuse