Providing an estimate for the work to be completed is a must for any project. Estimates help businesses figure out how much time a project will take to be completed and how much it will cost. Agile projects also need to be estimated to evaluate the effort required to complete items on the product backlog, which in turn will help in stakeholder buy-in. Agile estimation techniques help in this process and allow teams to schedule their resources and ensure that the project is on track all the time.
Traditional estimates once made are not revised. A project plan is created with all the associated dependencies and tasks are assigned to team members. In Agile, estimates can be revised at every sprint, which makes it easier to accommodate revisions.
Traditional project management uses task-based estimation. A list of tasks or a work breakdown structure is created by the project manager, a process in which the team also assists. Subject matter experts then must determine the time in hours that each task would take to complete. Agile on the other hand, uses feature-based estimation and the features are typically slotted as small, medium or large. So, while traditional estimation techniques will help you answer the question “how long will it take?”, agile helps you answer the question, “How big is it?”.
Estimations, whether in traditional project management or agile project management, are often tricky tasks to be accomplished. There is a whole lot of ambiguity with regards to a project before it has started. The project can run into risks, requirements may change, there can be scope creep and there can be several unseen and unavoidable factors that may send our estimations out the window. Yet, software estimation is a task that must be completed in order to help development teams determine task allocations, to help product owners develop the product backlog and to help management approve the budgets needed for the project.
Agile is not a one-size-fits-all framework. It can be customised to fit the needs of the organization. Agile estimation too can be customized depending on the type of Agile project. These simple, yet effective estimation techniques help teams to plan and carry out project tasks successfully.
Let’s look at some of the Agile estimation techniques available:
Popularized by Mike Cohn in his book "Agile Estimating and Planning”, planning poker is an estimation technique that is used to estimate the relative size of user stories. This is a consensus-based estimation technique, which means that the estimates are drawn with consensus from the whole team. Like its namesake card game, planning poker estimation requires team members to write down story point values on separate cards. The values are assigned based on complexity and are based on the Fibonacci sequence-- 0, 1, 2, 3, 5, 8, 13, 20, 40 etc. Each value represents a different level of complexity.
The estimation starts with the team members meeting and sitting together. The team members have their cards with different values written on them. A team member who has been assigned the role of a moderator, reads out the story. Team members are free to ask questions and discuss the story with each other. Then each team member will pick up a card value which they believe should be assigned to the story. If all have assigned the same values, then that is taken as the final estimate for the story, but if there are different estimates then team members are asked reasons for assigning the value to the story.
While this is a popular and effective estimation technique, it will not work for large and complex projects with more team members. Small teams working on small projects can arrive at effective estimates with the planning poker technique.
T-shirt sizing is an effective estimation technique when quick estimates need to be provided for many items. It is a flexible approach and effective for first level of estimating and large backlogs.
The method starts with assigning t-shirt sizes to user stories. These sizes can be S for small, M for medium, L for large and so forth. Depending on the size of the task, the user stories are assigned these different t-shirt sizes. Just like in planning poker, T-shirt sizing also requires teams to come to a consensus before fixing on a task’s estimate. Once all stories have been assigned sizes, they are placed into S, M, L, XL etc sized buckets so that teams get an understanding of the number of tasks based on their sizes.
While T-shirt sizing is a great way to provide stakeholders and the team a relative initial estimate it must be noted that these are not absolute estimates and may be prone to many changes and revisions. The t-shirt sizes may need to be assigned a numerical value in case velocity needs to be calculated.
Dot voting is again a great estimation technique for small teams and small projects with fewer tasks. Although it is a decision-making tool, dot voting as an estimation technique makes the process simple and effective. This process too requires the team to sit together. Each team member is assigned several dots, which are used as votes to indicate the size of a task or a story.
A greater number of dots corresponds to a bigger task or higher priority and fewer number of dots means smaller tasks or lower priority. Team members can only add a fixed number of dots as defined before the start of the voting process. If two tasks receive the same number of dots, the voting can take place again. Members are also asked to justify why they have assigned a particular number of dots to a particular task.
While this seems relatively simple, it has several disadvantages. If any team member lobbies for a particular task, then there is a tendency for other members to get influenced, which is why in some teams, no discussions are allowed before the dot voting commences.
Dot voting also has its fair share of advantages as it helps all team members to cast their opinions, reduces time associated with the estimation process, priorities are recognized, and the estimation is a collaborative effort.
The bucket system, like T-shirt sizing, helps to estimate many items quickly. It is a collaborative approach among members of a small or medium sized team where every member gets to decide on the complexity of the task. As individual members are not held accountable it also fosters collaboration in the team.
The bucket system starts off with having pre-defined buckets of different complexities. Like the poker planning, buckets can be assigned values based on the Fibonacci series-- 0,1,2,3,4,5,8 etc. The process starts off with the team discussing each product backlog item. A task is picked up at random, which can be (for example) a medium complexity task and is placed in a mid-point bucket like 3. This is the reference item.
Now pick one story after other and relatively size them against the reference story, placing them in the appropriate bucket. The trick to this approach is to use stories that are similar in size. If the story is too big to fit into the bucket, then assign it as an epic that needs to be further split into smaller stories.
Similar to the bucket system, but more rudimentary, this estimation has only three sizes into which items are sorted. Team members discuss all items and place them in these three categories. Easier and smaller tasks are sorted first and then the more complex stories or tasks are taken. This is also an easy estimating process and works best when the product backlog consists of items that are comparable with each other.
Affinity mapping is again a great method when many user stories need to be estimated. It’s a good technique to use if the product backlog has not been estimated yet. It is a transparent technique and involves collaboration among all team members. The process starts with the product owner giving the user stories to the team who then establish the relative sizes of the stories. The stories are arranged in an ascending order horizontally. This process is also called the silent relative sizing as the team works in silence and there are no arguments or confrontation on the sizing.
Once the basic arrangement is done, the team re-visits the list and re-arranges the items till the team is satisfied with the arrangement. There can be discussions during this step. Following this, the items are placed in definite buckets which may be labelled as Small, Medium, Large etc.
This method does not involve any bucketing but simply ordering items on a scale labelled from low to high. Items are first placed in a random order. The team members then take turns making moves and shifting the item up or down the list and offering a justification for their move. If a task has not been re-ordered, then it is left in the same position and the next task is taken up.
The estimation techniques are a wonderful way to forecast schedule and budgets. If the estimation method involves assigning numbers or points to the stories, then the velocity can be calculated by adding up the points. Velocity can used for drawing up long term schedules. If the team has a record of velocities, then it can use it to determine the most optimistic completion date or most pessimistic completion date and so on. The optimistic dates are calculated by using the average velocity numbers while the pessimistic dates are calculated based on the team’s worst performing sprints.
Velocity calculation on order to estimate forecasts for schedules and budgets requires values, which is why estimation techniques like t-shirt sizing may need velocity points to be assigned to the story sized.
|1||Allow customer to view order delivery status||2||√|
|2||Provide option for customer to bill to third party||3||√|
|3||Allow customer to use discount codes when paying||5||√|
|4||Allow customer to use gift certificates when paying||8||√|
|5||Hold remaining value of gift certificate for customer's future use||8|
Source: Determining Team Velocity
Determining the budget of a project at the start can be difficult for the planning team. Budgets are usually drawn using an algorithm that uses previous estimates or on the tasks that have been estimated till now. This budget is bound to change as more releases are planned and more requirements are added. A commonly used formula for determining the budget for the first release is:
Σ (loaded team salaries for period n) / points completed in period n
(Cost per point x total point value of items to be completed) + other expenses = forecast budget
For the subsequent releases, the team can add to the above algorithm. For example, the second release could be calculated by adding 20% to the above formula and for the third release an additional 5% can be added to determine the budget.
Most of the Agile estimation techniques offer simple and relative methods for estimating the effort required for projects. Given the complexity of projects these days, estimation is a tough job for anyone to get accurate, but it’s an exercise that must be carried out to ensure that the project progresses on time and within schedule.