Agile Estimation Techniques: A True Estimation in an Agile Project

True Estimations in an Agile Project: A Complete Insight with Examples on 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.

With lack of Estimations in Agile Project, there may be no proper planning and management which may end in delivering the undesired product and thereby leaving the customer unsatisfied.

Story point 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.

Introduction

Given below are the 3 main levels of Agile Estimation.

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

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

#3) Sprint Level is the one where the user stories are broken into the 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 Points Estimations In Agile

Story Points estimations is a comparative analysis to roughly estimate the product backlog items with relative sizing. The team members for estimating user stories include: Product Owner, Scrum Master, Developers, Testers and Stake holders.

Given below are few steps to reach the final decision of 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 Owner is responsible for clarifying all their queries and doubts.

#3) Make a list of the things to be taken care 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 the Scrum Master.

#4) Stated below are 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 for implementing this user story. Have we come across any similar user story previously?
• Unit Testing: Are any mock objects required for doing 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 to deliver the desired product as desired by the Customers?
• Expertise: Does any of the participants have done similar story before and is an expert in it?

#5) Do relative sizing for the story selected. If it requires same amount of work and effort, then assign it the same no. of points, as assigned to 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 selected user story as per the definition of done.

#7) After relative sizing of all the product backlog items have been done, ensure that if all the user stories with same no. of points assigned to them, require 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 is having 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 measure in which 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. The 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 same value, then that becomes the final estimate.
• If values are different then the estimators giving highest and lowest values explain their opinions and why they chose this value, until a consensus is achieved.
• A good technique when 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 a perfect technique to give a rough estimation 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 of the team members or 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 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 dot).
• All the stakeholders are asked to give their votes on the user stories that they prefer.
• Product Owner orders the product backlog items from the most preferred (one with most no of dots) to the least preferred (one with least no. of dots).
• It may be the case, where few stakeholders are unhappy with the order decided. In this case, the user stories are divided in 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 is 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 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.
• The 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 is used for reference only. Pick another story at random, discuss all its features and requirements with the group and upon consensus, place it in the appropriate bucket. Similarly, third item is picked and placed at an appropriate bucket.
• The bucket sequence can also be changed, in case the group feels the first item chosen, should belong to the bucket 1 instead of bucket 8.
• Divide and Conquer approach is followed. 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 item 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.
• At last 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 with them. This is done until a consensus for the whole product backlog is achieved.
• The facilitator should make a check that nobody moves the items unless sanity check is done.
• This is also done to achieve the priority order of the product backlog items.

#5) Large/Uncertain/Small

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

#6) Affinity Mapping

• A good technique when the team is small and no. of backlog items is less.
• 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. Product Owner provides 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 solo decision of the participant without any discussion with the other team members. Product Owner or stakeholder is present to clarify the doubts of the participant. Product Backlog items which are too ambiguous to be understood by the team members for estimation are placed separately. It takes 5-20 minutes.
• Editing of 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 correct locations: After the discussions, the team places the product backlog items in their relative 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

• A 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 on the scale, at one time. 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 play an important role in Agile projects. This is done to make sure what is the actual budget 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 the team members should agree upon the estimations done for the listed requirements after 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 Sprints 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 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 burnt down chart to give a clear picture of how much work is left to be done versus how much time is left for implementation. It basically gives the rate of progress of an agile team. It gives a clear picture on how the team is behaving and how it is expected to behave.

The 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’s purchase, tools, infrastructure support, getting licenses for 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 his expertise is considered as pre iteration work or post iteration work. This Pre and Post Iteration works require 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 In 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 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 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 detail of tasks of the Sprints along with status, priority, story points and whether they are assigned to a Sprint or if there are some additional task 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 a 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 the overview of where the project is heading to.

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 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 a project and the no. of user stories to be taken in a 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 for delivering user stories with in a sprint.

S1, S2,S3,S4,S5,S6 are 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 is 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 the software projects. A function point is a metric which 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.

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

How to calculate 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 purpose 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 FP size of all the functions, to get the Total Functional Size of the application.
• At least two persons with expertise in FP analysis, should calculate independently, match results and resolve the differences.

Example for Project-Level Estimation:

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

• A user should be able to login to the website by providing the username and password.
• Post successful login, a user should be taken to the main page with right and left panes defined.
• A user should have an option to logout from the Application.
• A valid user has the option of changing the password by providing current credentials.

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

Following is the analysis done:

• Data storage function here is storing the User Credentials to log in and change the password.
• Since the credentials are stored within application boundary, it is stored in ILFs (Internal Logical Files).
• The Transaction functions include:
  • User login and display of the main page.
  • User logout and display of 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 Caper Jones Table.

STEP #2: List down all the Transaction Functions

UFP (Unadjusted Function Point) is taken from 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. It 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 planning which focuses on estimating the size of the software to be delivered for that release. In this way, no 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 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.
• 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.
• Sizing of stories helps in determining how many stories will be taken within a sprint and release.

Example for Release Level Estimation:

This involves creating a prioritized list of User Stories called Product Backlog. Product Owner creates Product Backlog and provide business value for each of the item listed in it.

We can use the below methods for Story Points Estimations:

• Numeric Sizing: 1 through 10
• T-Shirt Sizing: Each requirement 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. 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. the time required to complete that task for a 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 estimations is to know how many user stories, the development team can commit to a Sprint. The development must be comfortable with the commitment and the 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 the 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 in these estimates among the team members, 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 for Sprint Level Estimation:

There are two parts of 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 necessary to make the Product Backlog item deliverable, should be included. The tasks should be small. Ideally, a task effort should not be of more than six hours.

Conclusion

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

The techniques to estimate story points like Planning poker, Bucket System etc. make use of cards or dots having 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.

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