Best practice for scrum planning is to spend the second half breaking the stories down into tasks and putting hour estimates on these tasks. From these estimates a sprint burndown of hours remaining can be created. However, some teams view breaking stories into tasks as an unnecessary overhead. While there may be some cases where this is true, there are a huge number of potential benefits that come with breaking down stories into tasks so I would recommend teams at least experiment with it before writing it off as a waste of time. Below is a list of the potential benefits that will hopefully make it clearer why it’s worth spending the time.
The task breakdown section of planning can be a forum for the team to discuss, and become aware of, technical issues, as the less technical people are out of the room. Of course if the discussion starts to get out of hand and put the timebox at risk, that’s a sign that there needs to be a task for technical investigation and further discussion. Take this opportunity to make sure that everyone is on the same page about the technical level of the work planned.
Knowledge Sharing & Support Systems
Another potential benefit is having a chance to identify the experts on a particular piece of work. This means if someone else ends up doing the work they will know who to ask for help. Having the subject matter expert go through how they would break up the work can also be a mentoring opportunity. Task breakdowns can facilitate cross-functional knowledge sharing, as the team as a whole becomes more aware of the analysis work, the testing work and the dependencies between all the different kinds of work being done.
Having tasks visible, and within the context of other tasks, adds more flexibility of who does which tasks. Junior or non-experts are now able to see what pieces they can pick up to contribute towards getting the story across, rather than it being stuck entirely on the senior or expert team members to organize and complete.
Relatedly, tasks breakdowns can help identify opportunities for more developers to work on one story at the same time. Testers can start creating test plans and possibly do initial testing while development is still in progress. This reduces number of stories in progress, which means less complexity and more focus. It also increases the rate of getting stories done and delivering customer value because everyone is working on moving the top priority stories across.
Identify Repetitive Tasks
Sitting down and writing up all the tasks across all the sprint’s stories in one go can increase the chance of identifying repetitive tasks that can be streamlined/automated for productivity improvements. Surprisingly, it is common for these repeated tasks to be overlooked until the task breakdown makes it more obvious just how often they’re coming up.
Usually User Stories are supposed to focus on what the user wants and why that needs to be done. The tasks then focus on how the change will be achieved. Having tasks as a separate artifact from stories further separates the how from the what, which means grooming can focus more on understanding what the user wants. This helps the Product Owner to focus on the user as well, while the development team looks after how to do things.
Reduce risk early:
Identify False Assumptions
Sometimes one or more team members may have made an incorrect assumption about what the user story actually requires. Breaking things down to a task level increases the visibility and the chance of recognising these before too much time is spent coding down the wrong path.
Detect Forecast Over Capacity
Tasks should be estimated in hours and then compared to capacity for the sprint. If the forecast hours is over capacity (or more than 80%, unexpected things still happen), the team needs to seriously consider whether their forecast is realistic and look at updating it based on the task estimates. Updating the sprint forecast to be more realistic allows for better communication to the rest of the organization about what changes are likely to get done.
Detect Expanding Complexity
As task estimates are updated to represent the work remaining, this can be regularly (usually daily) compared to the remaining sprint capacity so that the team knows if things are getting out of hand. If a particular story is expanding in complexity the sprint forecast may need to be updated. Many teams think that the forecast is set in stone after sprint planning but if the forecast no longer looks realistic then it’s important the team lets the Product Owner know so that they can review their priorities and communicate to stakeholders. Alternatively the Product Owner may be able to provide the context that allows the team to revise their tasks and minimize complexity. Either way, without tasks this information is invisible.
Having a full view of upcoming tasks can also help early detection of impediments (or potential impediments). In many cases the impediment can be removed before the team hits the impeded task and the team can maintain their flow without the disruption.
Detect Holes in Knowledge/Specifications
The act of planning through what work needs to be done can often trigger questions about the details of what the user wants. The sooner the Product Owner is asked these questions, the more likely they can provide a solid answer before the question becomes an impediment to completing the story. Similarly, if the team realizes that they don’t have the requisite knowledge to complete the tasks for a story, they can arrange getting the support and/or training that they need from the rest of the organization.
When task estimates are displayed as a burndown, everyone has more visibility of the sprint progress. This should help to reduce surprises for everyone, both internally and externally to the team.
With a clear view on sprint progress, management can more readily know when the team need help and when they need to be distraction free. It’s important that management don’t use the task breakdown or sprint burndown as a method to monitoring developers’ every move. You need to trust the team if you really want them to do their best work. Lambasting developers when tasks take longer than estimated will usually just lead to inaccurate tasks and estimates since no-one will want management to know when things are going wrong if it means they’re going to get yelled at again. Remember: the task board belongs to the team. It’s for their benefit. For external parties it can be an interesting source of information but don’t ever be fooled into thinking that it’s the whole picture. If you’re concerned about progress always consult the team first and ask them if you can help. It’s always better to approach in a helpful and supportive manner.
Don’t try to plan deeper than you can given your current knowledge because that’s when you’ll cross that line and begin wasting time. You have to balance reducing risk and increasing visibility with spending time planning things you can’t know and having to constantly update huge plans. Update tasks as more details arrive and remember that it’s just an estimate, it doesn’t have to be exactly right, it just has to be your best guess given the information available. Over time, breaking down tasks will increase the development team’s self-awareness and, for the most part, their estimate accuracy and ability to break stories down into component tasks should improve, but there will always be unexpected unknowns so don’t expect otherwise.
Hopefully that’s enough of a list to convince you that it’s at least worthwhile having a go at task breakdowns before you decide it’s not worth the overhead. Can you really say you don’t need these benefits?