Before reading on, what would your immediate response be to this question?
One argument is that tasking User Stories creates unnecessary overhead. If teams are working on small, Sprint-sized User Stories, then these stories are all that the team needs to track, progress-wise.
Another argument is that tasking the work and estimating the time it will take to complete those tasks is a step backward, because time-based estimation techniques are we’re trying to get away from with agile.
Finally, there is the point that tracking time spent on tasks does not add any value.
I understand and agree with the merits of relative sizing and using velocity to forecast a release date. Time-based estimates are inherently inaccurate, particularly the further out we look because there is greater uncertainty and variability involved. Planning based on small User Stories that fit into a Sprint – particularly if a Sprint is only a couple of weeks in length – addresses many of the uncertainty and variability involved.
With agile, the team is continually learning as it goes so that the team can incorporate that learning into upcoming work as they flesh out the details, elaborating the User Stories on a just-in-time basis. This learning, coupled with the small sizes of the work items enables a team to be more confident that they can deliver on what they are about to build.
My preference, however, is to guide teams in tasking out their work and estimating the hours they believe that they will require to complete those tasks. The following are my reasons for tasking out user stories and estimating the tasks in hours.
Teams commit to a Sprint. And commitments are not to be taken lightly. The team’s confidence that it can meet its Sprint commitment can be bolstered by tasking out the work and estimating the hours to complete that work.
One factor is that the team needs to gauge how much work they have relative to the time that they have available in each Sprint. Holidays, vacation time and other factors like formal training impact how much work at team can take on in a given Sprint.
Likewise, the work itself contains elements of uncertainty and variability. Continual learning and small units of work reduce uncertainty and variability, but it remains. In addition, the nature of the work may vary from Sprint to Sprint; one Sprint may be more development-heavy and another may involve more testing than development.
Tasking out the work helps the whole team to understand and agree on what needs to be performed, the skills and focus each Sprint requires, and how much time it will take them for a team to complete that work.
Teams define and own the solution. User Stories aren’t the full set of requirements, but statements of intent. The Product Owner collaborates with a team to define the solution. The solution is about defining what needs to be done, and that what includes two aspects:
- The business functionality
- The design and implementation of that functionality
A little time talking about the design and what tasks need to undertaken to implement that design helps everyone understand how that solution will be implemented (supporting collective code ownership), plus it ensures that a good design will be in place that the team can live with for the long-term. I’m not talking about detail design docs, etc. but more lightweight, fast white-board designs and high-level tasks that naturally flow from this design. Invest the minimal amount of time and effort required to satisfy the need.
Teams are responsible for managing their work. With agile, the management of the work is not only visible, but we’re striving to provide ourselves with short feedback loops to gauge our progress and catch issues as early as possible. Certain technical practices provide feedback, such as automated tests that are executable as part of a continuous integration practice, for example. Customer feedback at the end of every two-week Sprint is another example.
Tasks and estimated time provide teams with early feedback on whether the implementation a User Story is jeopardizing its Sprint commitment. Time is a valuable commodity during a Sprint, and the shorter the Sprint, the more valuable time becomes.
If a User Story is expected to take two days to implement based on a team’s historical velocity, but that User Story becomes more involved than anticipated, the team will likely not learn about until the second day has past – 20% into the Sprint (assuming the team started that story first). However, if a half-day task related to that User Story is going longer than expected, then the team will learn about the issue much earlier, giving the team more time to assess the Sprint impact and strategize on how to deal with the issue.
Assessing the impact to the Sprint is also made easier by having a Sprint burn-down chart that plots the hours of work remaining. The goal isn’t to track the team’s hours, but to have a tool available that facilitates the team managing its work and understanding at any point in time what time the team has left on its plate to meet its commitment. (Tracking hours may to support things like R&D tax credits, so there could be a benefit to knowing how much time a team spent on certain projects.)
Do all User Stories need to be tasked out? Not if they are very small. But for these reasons stated above, my guidance to teams is to task out User Stories. But if you feel that I’m on the metaphorical ledge, I’m always willing to be talked off of that ledge, so please chime in with your comments!