Agile Estimation Techniques: Template and Example

True Estimations in an Agile Project: A Complete Insight with Examples of Agile Estimation

It is very crucial to do Agile Estimation at different Levels. This is done for proper planning, management, and estimating the total efforts that we are going to use for implementing, testing, and delivering the desired product to the Customers in terms of time within the specified deadlines.

Due to a lack of Estimations in Agile projects, there may be no proper planning and management which may end in delivering the undesired product and thereby leave the customer unsatisfied. Storypoint Estimations are done in Agile projects using different techniques like Planning Poker, Bucket System, Affinity Mapping, etc.

Different estimation templates at different levels are used for this purpose like Agile Project Plan Template, Release Plan Template, Sprint Plan Template, RoadMap Template, User Story Template, etc.

Agile Estimation Techniques

Introduction

Given below are the 3 main levels of Agile Estimation.

#1) Project or Proposal level is the one that uses Quick Function Point Analysis during the initial phases of the project development.

#2) Release Level includes assigning story points to user stories that can help in defining the order of user stories based on priority and can also help in deciding which stories can be taken in the current release and which can be taken later.

#3) Sprint Level is the one where the user stories are broken into tasks and estimated hours are assigned to the tasks according to their complexity. Here, we also define the person responsible for the task along with the status of the tasks.

This information can be later used to calculate the budget for the Agile project. Calculation of Budget is crucial to make sure that the project does not go over the budget due to the pre and post iteration tasks or some other reasons.

Story Point Estimations in Agile

StoryPoint estimations are a comparative analysis to roughly estimate the product backlog items with relative sizing. Team members for estimating user stories include Product Owner, Scrum Master, Developers, Testers, and Stakeholders.

Given below are a few steps to reach the final decision on relative sizing:

#1) Analyze all user stories and identify the base or reference story. It is important for doing relative sizing. This story can be chosen from the current product backlog or the one that we have done earlier. This story should be chosen as the reference story upon agreement of all members.

#2) Pick another story from the current Product Backlog and the team members are free to discuss any questions or doubts with the Product Owner while understanding the requirements of the story. Product Owners are responsible for clarifying all their queries and doubts.

#3) Make a list of the things to be taken care of while implementing the user story. These can be done by writing notes in the notes section of the tool or by adding bullet points on the story card. This is mostly done by Scrum Master.

#4) Stated below are a few common questions among the participants:

• Design: What is the prior and mandatory knowledge that we should have before starting to work on it?
• Coding: How much coding is required to implement this user story? Have we come across any similar user stories previously?
• Unit Testing: Are any mock objects required to do unit testing for this user story?
• Integration Testing: Does this story impact the other functionalities of the same module and other modules also?
• Acceptance Testing: What are the points to be taken care of to deliver the desired product as desired by the Customers?
• Expertise: Have any of the participants done a similar story before and are you an expert in it?

#5) Do relative sizing for the story selected. If it requires the same amount of work and effort, then assign it the same no. of points, as assigned in the reference story. If it requires more effort, assign it some higher value. If it requires less effort, assign it some lower value.

#6) Reach a consensus with all the participants to finalize the relative size for the selected user story as per the definition of done.

#7) After relative sizing of all the product backlog items have been completed, ensure that all the user stories with the same no. of points assigned to them, require the same effort and size to be consistent.

Different Agile Estimation Techniques

There are many techniques for doing estimations in an Agile Project. The main principles for doing estimations include Relative Estimation, discussions to get more information of items whose estimations need to be done, and ensuring the commitment of the whole team towards the tasks assigned to them.

There are mainly 7 Agile Project Estimation Techniques:

#1) Planning Poker

• In this Estimation technique, all the people who are supposed to do the estimations, sit in a round circle for the Planning Poker session.
• Each estimator has a set of Planning Poker Cards of values: 0,1,2,3,5,8,13,20,40 and 100. These values represent story points or measures that the team estimates.
• At the start of the session, the product owner or customer reads out the user story, describing all its features and requirements.
• After the story is read out, the discussions among the estimators and with the product owner/customer take place. Estimators can ask questions or clarify their doubts with the product owner.
• After the discussions, all estimators are asked to select one card to estimate a user story. If all estimators give the same value, then that becomes the final estimate.
• If values are different then the estimators giving the highest and lowest values explain their opinions and why they chose this value, until a consensus is achieved.
• Good technique when a small no. of items is to be estimated in a small team.

=> Further detailed reading on Planning Poker Estimation Technique.

#2) T-Shirt Sizes

• Just as in the case of T-shirts, we see sizes: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). A similar approach is followed here. Items are estimated in T-shirt sizes.
• This is the perfect technique to give a rough estimate of the large backlog of items.
• Useful when quick and rough estimation needs to be done. Later these sizes can be converted into no’s as per the requirement.
• A relative size (mostly Medium) is decided after mutual discussion and agreement between the team members and estimators. Then, the no’s are assigned to the items according to the relative size that is assigned to Medium size.
• Disadvantage: What seems L to someone may seem to be XL for someone.
• All estimators assign their own size to the items. After discussions and resolving the mismatches, a consensus is reached to get the final estimate.

#3) Dot Voting

• This is basically a ranking method to decide the order of the Product Backlog from the highest priority stories to the lowest priority stories. This is done to select the most important stories which should be taken forward.
• To start with this, post all the user stories along with their description on the wall or board using yellow stickies or in a way that distinguishes them for receiving the votes.
• All stakeholders are given 4 to 5 dots (mostly in the form of stickers, pens or markers can also be used to make dots).
• All the stakeholders are asked to give their votes on the user stories that they prefer.
• Product Owner orders product backlog items from the most preferred (one with most no of dots) to the least preferred (one with least no. of dots).
• This may be the case, where few stakeholders are unhappy with the order being decided. In this case, the user stories are divided into 3 groups after the discussions: high priority, low priority, and medium priority. High-priority user stories are posted on the wall to receive the votes. This will not be done until the final order is achieved with the agreement of all stakeholders.

#4) The Bucket System

• It is a good technique when a large no. of items are to be estimated by a large no. of participants. It is faster and more reasonable than Planning Poker.
• Different buckets are created with values: 0,1,2,3,4,5,8,13,20,30,50,100, 200.This can be extended if required. These buckets are nothing but cards representing values arranged sequentially on a table.
• Stories need to be placed within these where the estimator finds them suitable. All the items to be estimated are written on the cards.
• Pick an item at random and put it in bucket 8. This can only be used for reference. Pick another story at random, discuss all its features and requirements with the group, and upon consensus, place it in the appropriate bucket. Similarly, the third item is picked and placed in an appropriate bucket.
• The bucket sequence can also be changed in case the group feels the first item chosen should belong to bucket 1 instead of bucket 8.
• The divide and conquer approach follows. All the remaining items are divided among all the participants. All participants can place the item without the approval of other participants.
• The items should be placed properly. No items can be placed between the buckets.
• If a participant does not understand the product backlog item or if the other participants have finished up placing their user stories then the user stories can be transferred to the other participants.
• The final Sanity check is performed by all the participants. If any participant finds a wrong bucket assigned to an item, then they can bring it to the notice of other participants and discuss it with them. This will be done until a consensus for the whole product backlog is achieved.
• The facilitator should make a check that nobody moves the items unless a sanity check is done.
• This is also done to achieve priority order of product backlog items.

#5) Large/Uncertain/Small

• This is a rough version and is the simplification of the bucket system where there are only three sizes: Large, Small, and Uncertain.
• Participants and estimators are asked to place the items in one of the categories. First, simple user stories are chosen and placed in large and small categories. Then the complex items are taken up.
• Product Backlog is a good technique when there are comparable items in the Product Backlog.

#6) Affinity Mapping

• Good technique when the team is small and the. of backlog items is less.
• The first step is Silent Relative Sizing: On a wall, a card with ‘Smaller’ written on it, is placed on the leftmost side and the card with ‘Larger’ written on it is placed on the rightmost side. The Product Owner will provide a subset of the items to all participants. All participants are asked to size each item relative to the sizes on the cards on the wall, considering the effort required to implement them. It is the sole decision of the participant without any discussion with the other team members. The Product Owner or stakeholder will be present to clarify the doubts of the participant. Product Backlog items that are too ambiguous to be understood by the team members for estimation are placed separately. It takes 5-20 minutes.
• Editing of the wall: The team members can change the location of the items on the wall. They can discuss design and implementation requirements with the other team members. This activity can be closed when little change is happening on the wall. It takes around 20-60 minutes.
• Placing items in the correct locations: After discussions, the team places product backlog items in their relevant and appropriate positions. We can use T-shirt sizing, Fibonacci series, etc. here to relatively estimate the size of the items.
• Product Owner Challenge: The Product Owner may find some discrepancy in the estimations done by the team and need to discuss more features or the requirements for an item with the team. After discussions, final estimations are made.
• Export to Project Backlog Management Tool: To make sure the information about the final estimations is not lost, export it to a product backlog management tool.

#7) Ordering Method

• Good technique when large no. of items and small no. of people are there.
• It gives accurate relative sizes for the product backlog items.
• A scale is prepared ranging from low to high. All the items are placed randomly on it. Each participant is asked to move any one item at a time on a scale. The movement can be one up, one down, or pass the turn to another member.
• This continues until all the participants are satisfied and don’t want to move any item on the scale.
• This also gives the priority order of the Product Backlog items.

Calculating Budget in Agile

Calculating Budgets plays an important role in Agile projects. This is done to determine what the actual budget is provided, what more budget is required and how are we going to divide the budget for different product backlog items.

It uses the data collected from the previous projects and uses the mathematical formula to get the estimated budget for the current project.

Below is the sequence of steps to calculate the budget in an Agile project:

#1) List down all the requirements of the project and do the estimations for them using Planning Poker, Bucket System, Fibonacci series, etc. All team members should agree upon the estimations done for the listed requirements after a clear analysis and understanding of the user stories. Estimations are done based on the features to be implemented in a user story.

#2) Determine the duration of the iterations called Sprint and product backlog items assigned to it. It is usually 2 to 3 weeks long. The user stories are picked in a sequence starting with the user story of maximum priority, moving to lesser priority, and with the least priority user story at the end. This helps in deciding which user stories must be picked up in the first Sprint and which stories can be taken up later.

#3) Prepare a burnt-down chart to give a clear picture of how much work is left to be done versus how much time is left for the implementation. It basically gives the rate of progress of an agile team. It gives a clear picture of how the team is behaving and how it is expected to behave.

Team progress is measured in terms of Completed tasks, Remaining Effort, Ideal burndown, and Remaining Tasks as shown below:

#4) Add Additional Costs like Equipment purchase, tools, infrastructure support, getting licences the software tools to be used, Project Management Tools, Antivirus installation, and updates.

#5) Add Pre and Post Iteration Budgets. All agile members are supposed to be cross-functional, but there are limits to it. Anything done by a team member outside of his expertise is considered pre-iteration work or post-iteration work. This Pre and Post Iteration work requires an additional budget for implementation.

#6) Keeping an eye on the hidden risks. Risks in the Agile project include: Risk of the project going over budget, Absence of team members, Members do not have a clear or complete knowledge, Members do not have the required skills, deadlines have been crossed, etc,

Estimation Templates for Agile Development Project

There are many estimation templates that are prepared at different levels in the Agile development project. The sole purpose is to clearly state the estimates required for implementing a requirement or item and tracking its progress.

The main templates are as mentioned below:

1) Agile Project Plan Template:

It gives a high-level view of how much time is required to deliver the features of the requirements and what is their status. It also mentions the person responsible for a specific task.

(Note: Click on any image for an enlarged view)

2) Agile Release Plan Template:

It gives release details of the tasks corresponding to the requirements, along with their status and Sprint in which they need to be executed.

3) Agile Product Backlog Template:

It describes the complete product backlog defined for the project. It gives details of tasks in Sprint along with status, priority, story points, and whether they are assigned to a Sprint or if there are additional tasks like defects, etc.

4) Agile Sprint Backlog Template:

It gives a description of the user stories mentioned in the backlog of a particular Sprint. It gives the total story points assigned to a user story and how these are broken into different tasks. It also gives the status of the corresponding tasks and what is the work carried out on a daily basis for the corresponding tasks.

5) Agile Test Plan Template:

It breaks the whole test scenario into sub-scenarios. It gives details of the sub-scenarios like Implementation date, Expected Result, Actual Result, Status, etc.

It also mentions the Project Name, Compatible browser, Version of the Application under test, Test Case ID for a selected scenario, Written-By, Tested By, Description, etc.

6) Agile User Story Template:

It gives the details specific to the analysis of the user story like What are the roles required for specific functionality to be tested, what is the pre-requirement (environment set up and links enabled), and what is the expected outcome?

7) Agile Road Map Template:

It gives a direction to the project in the company, on a short-term and long-term basis. It helps in setting expectations within the company. and an overview of where the project is heading.

Stages of Estimation in Agile Project

In an Agile Project, estimations are done at 3 levels as mentioned below:

• Project/Proposal Level: Total functional size of the whole application is estimated using the Quick Function Point Analysis (QFPA) method when only high-level requirements are available.
• Release Level: Story points are assigned to the user stories which help in determining the no. of releases planned within the project and the no. of user stories to be taken in the release and sprint.
• Sprint Level: Estimated hours are assigned to the tasks of the user stories within a sprint. This is done to ensure the commitment of the development to deliver user stories within a sprint.

S1, S2,S3,S4,S5,S6 are the sprints.

#1) Proposal or Project Level Estimation

It is a very high-level estimation for the project. It focuses on the total no of requirements in the Product Backlog item. Function Points are used to estimate the size of the software/project before a detailed description of the functional requirements is documented.

Function points are the universally accepted way to calculate the size of the software. It focuses on the functionalities found in software projects. A function point is a metric that converts the requirements or user stories into a number.

During the initial stages of the project, it is recommended to adopt Quick Function Point Analysis (QFPA) method.

The Quick Function Point Analysis method is a unique approach for estimating FP when only high-level requirements are available.

How do I calculate the Total Functional size?

• Understand all the functionalities of an application with the help of domain experts.
• Identify and list all the possible functionalities of an application.
• Data storage functions are classified into Internal Logic Files (data stored internally within the application) and External Interface Files (data used for reference purposes only).
• Transaction functions are classified into External Inputs (data coming from external sources to application), External Outputs (derived data goes from application to outside), and External Inquiries (data retrieved from one or more External Inputs and External outputs).
• Calculate FP size for each function by calculating its average complexity.
• Sum up the FP size of all the functions to get the Total Functional Size of the application.
• At least two people with expertise in FP analysis should calculate independently, match results and resolve the differences.

Example of Project-Level Estimation:

Below is the list of requirements for a project, as in the Product Backlog:

• Users should be able to log in to the website by providing their username and password.
• Post a successful login, the user should be taken to the main page with right and left panes defined.
• Users should have the option to log out from the Application.
• A valid user has the option to change their password by providing their current credentials.

The team used a Quick FP estimation to estimate the project size.

The following is where the analysis is done:

• The data storage function here is storing the User Credentials to log in and change the password.
• Since the credentials are stored within the application boundary, they are stored in ILFs (Internal Logical Files).
• Transaction functions include:
  • User login and display on the main page.
  • User logs out and displays the logout screen.
  • Ability to change the password.

Below are the steps executed to estimate the project size using Quick Function Point Analysis:

STEP #1: List down all the Data Functions

UFP (Unadjusted Function Point) is taken from the Caper Jones Table.

STEP #2: List down all the Transaction Functions

UFP (Unadjusted Function Point) is taken from the Caper Jones Table.

STEP #3: Deriving the estimated project size in Function Points

UFP = Data FP + Transaction FP

UFP=10 + 12 = 22 UFP

FP = UFP * VFP = 22 * 1 = 22 FP (Assuming VFP (Value Adjustment Factor=1)

Productivity = 16 FP/month (Normal Standard)

Effort = FP/Productivity = 22/16-person month = 1.37 person month

#2) Release Level Estimation

Release level estimations are done during the Release planning. This is the next activity after Project level estimation. The prioritized requirements are taken from the Product Backlog which is in the form of User Stories.

The user stories are estimated in terms of story points during the Release plan which focuses on estimating the size of the software to be delivered for that release. In this way, the of releases and total no of story points in each release is planned.

A story point basically represents the relative effort required to implement a feature or the functionality, when compared to the other features. It is basically for sizing the Product Backlog items.

Story point estimation is done on the basis of:

• The complexity of the feature is to be implemented.
• Experience and technical skills of all the members.

S1,S2,S3,S4,S5 are sprints.

Steps for assigning story points to a user story:

• All the team members gather around a table going through the user stories present in the Sprint Backlog.
• The meaning of one story point and corresponding effort is decided.
• One of the team members reads out a user story and then asks the team members to assign the relative story points.
• If there is a significant difference between the story points assigned by the team members then they give an explanation for story points that they have assigned, thereby reaching a consensus at the end.
• The process is repeated 3-4 times until there is no major difference between the estimations given by the team members.
• The sizing of the stories helps in determining how many stories will be taken within a sprint and released.

Example of Release Level Estimation:

This involves creating a prioritized list of User Stories called Product Backlogs. Product Owner creates Product Backlogs and provides business value for each of the items listed in it.

You can use the below methods for Story Points Estimations:

• Numeric Sizing: 1 through 10
• T-Shirt Sizing: Each requirement is classified as Extra Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL).
• Fibonacci Series: Estimation done through Fibonacci Sequence (1,2,3,5,8,13,21,34,….)

Estimation of the above user stories through the Fibonacci sequence:

#3) Sprint Level Estimation

Sprint level estimations are done during Sprint Planning. The highest priority product backlog items are taken and divided into different tasks like Detailing, Design, Analysis, Development, Create Test Cases, Execute Test Cases, User Acceptance Testing, etc.

Tasks are estimated in terms of estimated hours i.e. time required to complete that task for the corresponding user story. The Bottom-Up Approach is used for the Task estimations where the business requirements are broken down into low-level activities and each activity is assigned estimated hours.

The purpose of the estimates is to know how many user stories the development team can commit to Sprint. Developers must be comfortable with the commitment and Product Owners must be confident that the team will deliver on the commitment.

Steps for assigning estimated hours to the tasks:

• Team members pick up user stories. Then, they are asked to estimate the actual effort, in terms of hours or days, for the tasks corresponding to the user story.
• If there is a disagreement among the team members in these estimates, then they discuss it and come to a consensus.
• If any task is of more than six hours, it is split into smaller tasks.
• If there are two or more tasks with estimated hours less than two, then they are combined to form a new task.

Example of Sprint Level Estimation:

There are two parts of the Sprint Planning meeting:

• First Part: Focus is on clarifying the requirements for User Stories, selected from the Product Backlog.
• Second Part: Focus is on breaking the requirements into tasks and estimating the hours required to complete them. All the tasks that were necessary to make the Product Backlog item deliverable should be included. The tasks should be small. Ideally, a tasking effort should not be of more than six hours.

Conclusion

The estimations in the Agile project play an important role in ensuring proper direction, planning, and management. It provides steps on how to take up the project in the future.

Techniques to estimate story points like Planning poker, Bucket System, etc. make use of cards or dots that have values or numbers printed on them and then assign these nos. to the user stories for relative size estimation.

The sole purpose is to set the items in a prioritized order from maximum priority to minimum priority. The relative sizes estimated for the product backlog items help in estimating or calculating the budget required for the project.

I hope you have gained great insight into the Estimations of Agile Projects. Feel free to express your thoughts about this tutorial in the comments section below.