Scrum/Estimations
Estimations are used in Scrum as a basis to roughly predict the future.
There are 2 ways we use estimations:
Contents |
Release Planning
Estimating
For the Product backlog, the Product owner asks the team to provide rough estimations for each item.
Since at this point little is known about the details of the work, the estimations can only be a rough guide. In order to avoid the illusion of precision these estimations are not done in hours, but Story points or similar units.
It is advisable to only estimate as far as predictions are necessary, e.g. until the next release that needs to be planned.
Measuring the speed
During every sprint, the number of completed story points is counted.
This way we get an idea of how many story points the team can process in a sprint or per week.
We also find out how much variance is in the speed - so how strongly and how often the speed of the team varies.
Doing the math
Knowing the remaining points to be done before the next release and the speed we now know the average point in time where our release will be ready.
With the historic variance we can now also determine worst and best case scenarios and state how probable the various outcomes are. This is important data and should always be provided since a "most likely" date often has less than a 50% chance of actually being met.
Sprint planning
Depending on how much experience and routine a team has, its ability to plan its workload varies greatly. In order to track progress and know when things are going wrong it is therefore common to use a Burnup or Burndown chart based on hours.
Estimating
In the second part of the Sprint planning meeting the individual steps necessary during this sprint are being determined and written down.
For each of them, the team or team members estimate how much time they will need. The time is typically estimated against 6 hours per workday - since everybody has the tendency to forget factoring in time used for meetings, administrative tasks etc. this makes estimates more realistic.
Tracking
In the Spreadsheet used to track the sprint, team members update the time remaining every day. Doing so they write how much time they think is remaining, *not* how much time was spent. If a task was underestimated or runs into complications, the number of hours can also increase from one day to another.
Every day's remaining time is entered in the column of that day, so a history of numbers is generated.
For each day, the hours of work remaining are summed up. The spreadsheet also calculates the working hours remaining before the end of the sprint, so they can be seen in comparison.
This comparison is visually represented in a burnup or burndown chart.
Acting
If it becomes clear from the tracking data that the remaining work will not be able to reach 0 at the end of the sprint, it becomes necessary to rediscuss the scope of the sprint.
The ScrumMaster will therefore invite the team members and product owner to discuss what needs to be dropped out of the sprint in order to finish on time.