Scrum Teams often fixate on Sprint planning, particularly the estimates Even as Team members protest about spending too much time in meetings, and they’ll wrestle over individual task estimates. Let us quickly recall the reasons why we do this activity. We estimate tasks in order to
- Develop an attainable team pledge to deliver an assured amount of Customer value, articulated as User Stories selected for the Sprint
- Track the team progress through a sprint through a Burndown chart. This is extremely important if we do not want “Type-A Stakeholders” leeching the time of the Core Team.
Part of the reason for decomposing User Stories into tasks is to develop more accurate estimations. Each step of the decomposition will convey some awareness in the higher level and is used by the Scrum team to familiarize with their prior estimates and use this retrospection to develop their upcoming estimations. Without this estimation, the team is not well informed and cannot improve. The organization needs reliable information for predictable planning for marketing activities. So how does one estimate Tasks effectively?
A Good Scrum Master should start by allowing the Sprint planning meeting to take its own course, irrespective of the time it takes, until the Scrum team can establish steady velocity. The Product Owner should however, make sure the team’s deliverables pass the test of creating potentially shippable deliverables each sprint. When the team self-organizes and the project has attained constant velocity, the Scrum team will be competent to make, and meet sprint pledges based only on verified velocity and their estimates of Story Points. Some Scrum Masters may want to continue enabling this freedom as a good Scrum implementation.
The Scrum Master should then start focus on the Burndown chart. The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. The initial Sprint Burndown Chart is accompanied by a planned burndown. It begins with the sum of all the tasks for the ongoing sprint. The Sprint Burndown Chart should be updated at the end of each day as work is completed. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. For best results, the Scrum Master should insist that the task breakdown results in the smallest possible tasks. The burndown chart reveals the estimated work effort left. This works best if there are lots of small tasks, typically ones that require a day or less to do.
The Utility of the task estimation is improved if there are numerous small tasks in the Sprint Backlog. This is because the daily updates of the task estimates are more current. Burndown chart for large tasks would be unresponsive on a daily basis, because progress on the large tasks would not show up for multiple days until a task was completed. Thus the remedy is to make tasks small. Ideally, a task should be completed in a day or less.
