The topic of Estimation Techniques gives rise to heated debates among Agile Practitioners. There are those who state that Estimation Wastes Time. They suggest that it should be removed from Planning completely. This is fine under the following situations:-.

• The Project is small and involves only one Scrum Team (Scrum Master, Product Owner and Development Team).
• The Scrum Team has Worked together before and understand each other’s abilities. The Scrum Team have a good concept of their Velocity (the Work achieved in one Iteration or Sprint).
• The Customers are comfortable with Agile Development. They have seen several Agile Projects completed before the present one.

Consider the following situations:-.

• Agile has only recently been embraced and the Stakeholders in the Company are more familiar with Traditional Project Planning.
• The Agile Team is new and have never Worked together. They do not know anyone else’s experience and capabilities.
• This is a big Project with several Scrum Teams and Inter-dependencies.

Reasons for Estimation In Planning

Any one of these scenarios, or a combination of them, is a good reason to use Estimation when Planning. The Stakeholders expect the Product to be Developed within the constraints of the budget. They also expect it delivered within a reasonable timeframe. If the Agile Team are all strangers, they know only their own capabilities. Each team member has no idea what the Team Velocity will be.

Where a Project has multiple Scrum Teams, Team A could be dependent on Team B finishing a specific Feature in order for one or more Features in Team A’s to Work. Team A for that reason needs to know when Team B expect to have actually “Done” the Work. When Team B finish the User Story, this impacts Team A’s Sprint.

Let us accept that this scenario is more likely to be found than the ideal scenarios that we first described. Estimation is therefore a necessary evil. We can even make it fun by Gamifying it with a Technique like “Planning Poker”.

Estimation Techniques & The Power of Planning Poker.

‘ Planning Poker’ is a Technique that needs the entire Scrum Team to Estimate User Story Size and Complexity. Each team member assigns it a variety of Points (we will go over scoring techniques a little later). Each Team member has a deck of cards with a sequence of numbers or some other Measure. These cards are utilized to reveal the Value they wish to offer to a particular Story. Everybody in the Team places their selected card face up in front of them. The goal is for everybody to provide the Story the very same rating.

Consider the case where the following ratings have actually been chosen:-.
3, 3, 5, 5, 5, 5, 7. The Team members who have selected 3 and 7 must briefly discuss why they have actually picked those Values. The Team then chooses their cards again, up until agreement is reached, or the bulk vote is accepted by all. This is not a long drawn-out process and needs to take no more than a few minutes per Story.

Among the Benefits of Planning Poker is that it is an excellent Team-Building Exercise;- everybody has to get involved and Communicate why they made a certain option. This tells the remainder of the Team a bit about their colleagues.

The democracy of Planning Poker is very different from Traditional Project Planning. Where a specialist viewpoint is used as a Measure of effort for a specific activity or Feature. What is being Estimated in Agile is likewise not the time required to finish a Task, but the Effort required. There are various Units of Measure which can be used, too.

Points, T-Shirts and Fibonacci Series.

Just enough thought and effort needs to be used by the Team to get an Estimate for each User Story. Some Teams will offer the exact same Value to every Story in the Backlog, state 5, and get a Reasonable Picture of the total effort, which equates to the expected Velocity of a Sprint. This normally Works well for Teams who have actually Worked together before.

The Cards for Planning Poker can use different sets of Values, ranging from 1,2,3 … 10 to a Fibonacci Sequence, where the next number in the Sequence is the amount of the previous two numbers, or 1,2,3,5,8, and so on. Some Teams utilize larger numbers, state, 50, 100, 150, 200, however the technique is to minimise the choices available to the Players. Where a Team member is struggling to make an option, they can utilize previously Estimated Stories as a Yardstick, for circumstances “is this Story more difficult or easier than User Story number 3, which we offered a score of 5”.

As soon as all the Stories have been Estimated, and when the Velocity for a Sprint is understood; it is the sum of all the Estimates for the User Stories in the Sprint Backlog.

We found these books great for finding out more information on Agile Scrum:

Estimation Techniques for Large Projects.

Where there are several Scrum Teams within a Project, it is essential either to schedule some Planning sessions where all the Teams are involved or to Communicate a Common Yardstick for Estimation. This is in order to guarantee that when it comes to Estimation, everybody is on the very same page. It is no use if one Team has a different set of Goalposts from the other Teams. The Sprint Velocities would likewise vary by Team for the same quantity of Effort, rendering the Estimation of little Value.

Re-estimating, the Good, the Bad and the Pointless.

Re-estimating is an even touchier subject than Estimating, but it does have a part to play. One of the pillars of Agile is the expectation of Change. This implies that new User Stories will emerge and existing, Estimated Stories will Change. The knowledge of the Team increases and the capability to Estimate improves as the Project Progresses.

A common circumstance where Re-estimation can be used is where a User Story was not finished in the previous Sprint and now should be finished in the next Sprint. Let us say it had an Estimate of 8, there are 3 alternatives:-.

• the Story Value for the previous Sprint will be used in the brand-new Sprint (if the Story was not Delivered in its entirety, no Points are acknowledged).
• The 8 points are accepted as complete in the previous Sprint and points are estimated for conclusion of the Story in the present Sprint.
• Some of the Points are awarded to the previous Sprint (state 5) and the remaining Work is Re-estimated for the existing Sprint. Ideally, the story Points ought to be 3 here.

Some Teams spend time Re-Estimating completed Stories. This affects the ability of the Team to commit to the correct Volume of Work for the next Sprint, because the Velocity Defines how numerous User Stories can be packed into the Sprint Backlog, and it could take a few Sprints to re-establish what the Velocity for future Sprints will be.

The Value of Estimation Techniques.

Unless a Team is really mature and all the Strengths and Weaknesses within a Team are known, Estimating must not be done without. Estimation assists development of the Team and offers Stakeholders some Measure regarding what will be finished when. It establishes a Value for Sprint Velocity, which enables the Team to make a precise commitment to the Work they can finish in subsequent Sprints. It also provides an indicator to other Teams in big Projects regarding conclusion of the specific User Stories on which they rely. Estimation likewise enhances the understanding of everyone in the Team regarding their own capabilities when they commit to a Story and assists them with assessing just how much effort they have to put in for comparable Work in the Future.