Agile teams estimate story size during Release Planning and estimate efforts for tasks during Sprint Planning. This is perhaps true for most Agile teams while some of them have different approaches based on the training and/or coaching they have received. In my experience, I normally suggest the following approach.
During Release Planning, I always suggest size estimation using story points because teams do not spend a lot of time analyzing the stories, don't break down work into tasks, and so on. Teams do not have a firm commitment on entire release but they commit to one Sprint at a time when they start the Sprints. Hence they need to do a high level estimation and size estimation is found to be the best at this point in time.
Once they have the size estimated for all stories which are likely to come in the Release, teams take up stories in each Sprint as per the required order or priority and go into more details of tasking, etc. I have used the following approach with great benefit to teams:
As a first step (mostly true for teams who are new to Agile), I suggest breaking stories into tasks and estimating effort in hours for tasks. This they find it very easy to do but this has several negative points such as:
- The tasks are normally analysis, design, coding, reviews and so on and this creates an internal dependency among team members. Team members often waste time waiting for other tasks to be done before starting on their tasks. Collaboration among team members is not that good here.
- The estimation becomes some kind of commitment. Team members generally try to stick to the number estimated by them and are not motivated to spend more time if the task really needs it. They are also usually worried about completing all tasks which they have committed to and hence a particular task which they are doing needs to be finished in time. The rule of "work expands to fill time" also works here.
- Estimating tasks by giving a specific number is found to be not very accurate. This is one of the reasons why Fibonacci is recommended where we think of a range first rather than a single number.
- The team also goes by task burn down which may not give the correct picture about progress in terms of features completed.
After few Sprints, the teams are recommended to break down the stories into tasks but not estimate effort in hours for the tasks. This has the following pluses and minuses:
- The tasks are not having specific number as estimate for completion but team members can take as much time needed to do a good job of the task. This gives a better focus on doing quality work rather than focusing on completion of task itself within estimated time.
- The size of the story estimated during Release Planning is available for team to use and they may also make changes if needed.
- Team members will not know when exactly the previous task would finish and therefore need to collaborate more, which is good for Agile teams in the long run.
- Progress is more in terms of story completion rather than task completion as tasks do not have an estimation.
- Helps team to make sure all tasks needed for a story are done for every story.
- The negative aspect here is that it still creates a dependency at the task level among team members which may result in wait time and so on.
The next step would be not to break down stories into tasks, but instead have one or several team members commit to stories directly. This has the best results due to following reasons:
- Team members do not have a task list to complete but have just stories to which they are committed. Hence the collaboration is increased and team members often pair up in this approach.
- Team becomes more focused on completing any task that needs to be done to complete the story rather than going by the task list created in earlier approach. They have an option to include more tasks or remove unnecessary tasks based on the progress and state of each story.
- Burn down chart shows only stories completed and hence more useful from DONE point of view.
- Teams start identifying stories or sub-stories for all work being done during the sprint as they are no more thinking in terms of tasks.
In my experience of coaching more than 25 teams using Scrum over the past few years, I have found that teams usually reach stage three within 5-6 Sprints. Almost all teams have appreciated the value in the final step and they all love the approach. Teams become comfortable estimating size using story points and like the collaboration within the team and focus on feature completion.