Scrum is one of the most popular frameworks for software projects. This framework entails breaking down the project requirements into small task-sets or sprints, and executing them in an iterative cyclical approach. A key component of this approach is making estimates for the project.
The genesis of making estimates in Scrum is the user creating user stories.
A typical user story contains a statement of what value a user expects from using the software, a listing of the alternative paths to realize the value, and the acceptance criteria. It answers the questions – what and why, of the project. The project team first breaks down big or “epic” stories into its compound elements, fragmenting them into smaller, achievable tasks. Each of these would take about a day or two to complete. The result of this exercise is a Scrum spreadsheet with a list of tasks, known as Sprint Backlog.
The development team then makes an estimate for each task-set. Such estimation is usually a collaborative effort, and may be done in many ways. Some of them are:
The net result is an effort estimate which will enable the team to decide how much work should be taken up in each sprint. The key consideration would be the velocity of the project team. An established project team would know their velocity, and as such the estimation methods become easier.
With a new team, with unknown velocity, it becomes difficult to make predictions. The way out is to either make educated guesses, or run a sizing iteration for the team to get a measure of its own velocity.
On the face of it, making estimates in Scrum may seem too much of a chaotic or ad-hoc in approach. However, far from it, such an approach actually reflects the realistic and practical nature of Scrum. Scrum sacrifices predictability for adaptability. When the business environment itself is uncertain and unpredictable, it makes little sense to be rigid and inflexible in making project estimates.