Lately, we have struggled with deviations like the Backlog not being ready, Forced capacity and Developers who take too much into the Sprint. But there are more. This time let’s talk about the Tasks that Developers do not assign to individual User Stories during the Planning.
There has a been a lot written about Planning, but to refresh our memories, let’s again mention the possible impacts that not creating Tasks may have.
As breaking User Stories down into Tasks is still a relatively new activity for some teams, Developers tend to postpone or deliberately forget to create and estimate Tasks. By not creating Tasks, the team can forget to have discussions that may lead to additional questions and that may result in additional clarifications. By not estimating Tasks, Developers may not be able to properly plan and manage their time during the Sprint.
To give you an example, we at RWS created a custom dashboard in our project management tool for Developers. One of the pros is that all the Tasks that are supposed to be done by each Developer are in one place. Since the Developer can see the progress of a particular Task, they can better organize their time. Another advantage is that the whole Scrum team can use the Burndown chart that is generated from these estimated Tasks to monitor the Sprint’s progress. But, when there are no Tasks created, there is no Sprint Burndown chart at all. We cannot keep track of the Team’s progress from the very beginning, and if there are obstacles along the way, it will be more difficult for the Scrum Master to identify the problems.
Let’s think of the reasons why Developers do not break User Stories down into Tasks. Sometimes, they simply do not understand why they should. Or, they do, but are not sure about the implementation steps and are afraid to ask for help.
Here, the Scrum Master needs to have a discussion with the team and provide explanations justifying this activity. They should encourage team members to ask for help or voice their concerns when they are unsure about a Task’s implementation.
Developers should understand that when all team members do Tasks, the whole team can better navigate through the Sprint and better understand the complexity of the work as a whole. Furthermore, Tasks capture the selected technical solution for future reference, so Developers can prepare an outline for documentation and a simple to-do list for themselves.
In our next article, we will write about the last Planning deviation. See you soon!