With the growing popularity of Agile Processes in software development, esp. the amazing success of SCRUM, comes the need of planning your project the agile way. This includes having a vision, having a team and having a backlog of requirements big enough to fill at least the next sprint. The main aspects for the planning of the upcoming sprint are the priorities of the items in the backlog, the knowlege about the available resources and the estimates for the requirements that could possibly be selected for the sprint. This is the minimum of information you need to plan the next sprint.
The team should be able to answer these questions:
- Can we complete the selected items within the sprint?
- How does the sprint contribute to achieving the vison?
- Is this selection of the items from the backlog the right one to be ready for the next production release in time?
SCRUM embraces change. This is done by more short-term planning and frequent control of the project’s state at the end of each sprint. This allows for the incorparation of change requests by the customer without a full-blown change management. The process balances the effort of planning with the safe knowlegde that change is going to come. This fact is clearly expressed in the Agile Manifesto: Responding to change over following a plan.
Successful planning of the sprint is the key to a successful project. If you’re constantly failing to achieve the goals of the sprints, you won’t be able to satisfy the customer’s needs when it comes to an important milestone. Yes, there are milestones in a project’s lifecycle, even if they are often ignored in essays about Agile Processes.
The crucial point of the sprint planning is the accuracy of the estimates. To attain estimation accuracy we have to answer three questions first:
- What is going to be estimated?
- Who is supposed to estimate?
- How does an estimate look like?
An estimation refers to exactly one item of the upcoming sprint log. The backlog entries must be defined in a complexity so that they are neither too small (i.e. solvable in minutes) nor to big (i.e. possibly not solvable wihtin a sprint). The sum of all estimates makes the total sprint estimate. That was easy.
The next question is trickier to answer. The estimation for an item can either be done by an arbitrary developer participating in the planning meeting, by the specific developer who will be implementing this feature or by a group of developers. The first option is certainly the worst. You won’t get reliable estimates in the long run. The second option is a valid one, because the person responsible for the implementation will make careful consideration before estimating the effort. The latter option is a good one too. In this case the group is doing a SCRUM poker.
For the actual estimates you’ve got two options: You either estimate story points or you estimate in ideal days or ideal_hours.
Story Points
Story points measure the overall complexity of a backlog item (can both be a feature or a bug, in case also you handle bugs inside your SCRUM process). The complexity is a unitless and discrete measure. At the start of the project you define a set of allowed complexity measures. This can be a list of even spaced numbers like 1,2,3,4,5 or numbers that represent an “over linear” increase in complexity like 1,3,5,10,30. You can also opt for nun-numeric complexities like XS,S,M,L,XL. There is no rule for the number of complexity levels. Personally I would go with the second suggestion. Non-numeric complexities cannot be used to calculate a velocity. Even-spaced complexity distances make it more difficult to identify items too simple or items that are far too large for a sprint. If you are estimating in a SCRUM poker, story points work very well. At the end of the estimation round you will have a set of possible sprint log items sorted by complexity.
But what is this whole story point estiamting all about? How do I know which items fit into the sprint? This might be difficult to answer for the first few sprints. But you’ll soon get a quite exact number of story points that fit into your sprint (for a given team). This number is called velocity, like 50 story points per sprint. This approach works well if the number of developers in your team stays more or less constant. If your team changes often you’ll never get a stable velocity. The velocity also isn’t accurate if the environment changes too much between the sprints. If for example you have to integrate a complete new external system that you have no experience with, your velocity will drastically decrease.
Ideal Time
Estimating a backlog item in ideal time assigns the time span to it that it would take in an ideal world. I.e. the developer is dedicated to this task only, no disturbances, no unpredicted troubles, no off-topic conversations and all of the needed resources are available on your demand, always. The ideal time describes the exact time you are actually working on the task. This method works best when the developer who is going to implement the item is also estimating it. It gets difficult if several roles need to work on a backlog entry. This way of estimation is often chosen by organisations without much SCRUM experience, because estimating in a known measure (hours) seems to be easier at the first glance.
The estimation in ideal time puts more pressure on the developers, because they are constantly comparing the spent real time with the estimated ideal time, which might be demotivating. The estimates in e.g. ideal hours are often used by the project controlling. In these situations a certain part of a developer’s time is often assumed to be non ideal and is subtracted from the expected work load of a developer. For example 20% of the real time would be seen as non-productive, like participating in meetings. Therefore 80% would be seen as ideal time. This is oversimplifying the problem. Just by muliplication a real time by a constant does not give you the ideal time.
Conclusion
The contemporary SCRUM process defines the sum of the estimates for a sprint as forecast. This means: “We are expected to do this amount of complexity in the sprint, but we also know that something can get into the way”. Estimating in story points matches the idea of forecasting much better than the estimation in ideal hours. Estimation in a team also works better with story points. Reaching the sprint goal is understood as a team effort, rather than an individual one. If your velocity is constantly changing to a high amount, think about the project setup. Then SCRUM probably isn’t the right way to go, there are other options available.