Agile Fundamental

Agile Estimation

What is Agile Estimation?

(Scope of our this article to cover estimating user story)We definitely need estimation to plan our software development, in agile we do estimation in a little different way than traditional effort estimation, it’s easy, interesting, and yes effective too. In Agile Estimation, we can estimate its different hierarchy items ( read about story hierarchy ), in this article we are focusing on estimating user stories and their tasks. Traditionally we use to estimate efforts to develop functionality, wherein in agile we estimate Business values or Complexity of a user story level. And estimate efforts at the Task level. The unit of estimating a user story for its value or complexity is story points, and the unit of estimating a task for its effort is Hours. We usually relate T-Shirt sizing with Story sizing to mark the relative difference between user story sizes, e.g., Extra Small, Small, Medium, Large, Extra Large, etc., We will discuss story points in detail, later in this article.

The below diagram will help you understand story level estimation and Task level estimation.

Task estimations are not always followed, Many Agile practices run their execution (sprint or iteration) with only Story points. Tasks are used for better planning and tracking.

How Agile estimation is different?

How estimation of a user story is different than traditional effort estimation, Traditional Estimation Vs Agile Estimation

The table below highlights the major difference between

Traditional Estimation

Primarily estimation of tasks takes place to get the timeline of the project.

Estimate to get the timeline to complete the entire product

We estimate development, Testing, and another effort separately for any functionality

We estimate absolute values in Hours or Days

Estimate Before the development start

Estimates to create a Plan of schedule, and the development is plan-driven

Estimates of an absolute number of times have a high chance to miss estimates.

Panels of technical Experts, Architects, and other members involve estimating.

Agile Estimation

Estimate the size of the story for its value and complexity, task estimation is secondary.

Estimate to plan how much business value we can deliver in a single sprint or iteration duration (typically 2 to 3 weeks)

Estimate the size of a story keeping in mind, its development, testing, or any other activity to complete the functionality. However, if required, we can estimate different tasks for independent resource-specific efforts.

We estimate Relative sizing and learn more about relative sizing in our next section of an understanding story point.

Estimate the development for upcoming Stories of future iterations, by applying lessons learned from past sprints

Estimates to Identify Value, and the development is value-driven

Estimates to Identify Value in a range in Fibonacci numbers have very less chances to deviate from the estimated business value.

The Agile Team, mainly Developers and Testers do the estimation collaboratively, with the presence of the product owner or business analyst & Scrum Master. The Team may seek input from external Technical or functional experts, but the estimation is always owned by the team

Traditional estimation always focuses on how much time it will take to complete the work hence the scope is always constant and Time and cost vary based on estimation. wherein Agile we focus on what is the functionality we can complete within the fixed time box. Explained this concept in a diagram below Agile Estimation.

End of Section “How Agile estimation is different”

Understanding Story Points

Influencing Factors of Story Point :

Story Points are the measurement unit to estimate the size of a user story, on the basis of its.

Business Value
Complexity
Risks
Dependencies
Amount of work

Story Point in Fibonacci Series:

To Estimate the size or the story point, we map a numeric value, it does not matter what are the values, what is important is the relative deference. Three stories having story point 1,2 and 3 is equivalent to having a story point of 10,20 and 30. however the industry standard and to keep the practice uniform within, team, organization, or even in the Agile world we use the points in Fibonacci series i,e, 1,2,3,5,8,13,21,…Fibonacci series numbers have relative differences from each other to give a virtual difference in your estimation. Where story point 1 means: very easy development with no risk, complexity, dependencies and adds “nice to have” business value whereas story point 13 means: a significant amount of complexity, possibilities of risk or dependencies, and High business value. Any story appears to be more than 13 points, we strongly recommend breaking the story into smaller stories.

Uncertainty of Higher story point :

We always try to break the story into smaller stories for better estimation and visibility of its Risk, dependencies, and technical aspects. But we need to keep in mind that each story has to be potentially shippable. We should not break a story on the basis of its tasks like Development in one story and testing in one story. Breaking a story means splitting an expected functionality into two independent smaller functionality. Higher points mean its increases the uncertainty of its completion in time because it has a bigger risk, dependencies, and other unknown facts.

Story Points Vs T-Shirt Sizing :

During Estimation, we need to think about all its aspects, Complexity, Business value, Risk, Dependency, Amount of work in development and testing, etc., and make a judgment of its overall size to assign a story point.

It’s maybe sounding complicated, but once you will started doing it, you will find its a fun and exciting exercise to do an estimation.

To correlate your imagination to assign story points of a user story, categorize the size bucket as T-Shirt size and map a story point from the Fibonacci series with that. Refer to the picture for that mapping will help you understand how you can estimate a story point with a user story.

Relative Sizing: As mentioned earlier, we do a relative sizing to bucket the user story with a Story point, why relative sizing is easy, Refer to the Picture. From this picture, it’s very hard to measure the difference between the amount of water each container can contain, but it’s very easy to measure which container can contain more water and which container can contain less, that’s a relative difference in size, that is what we do to measure story points.

Let’s elaborate on the above concept further :

From the picture below, let’s assume we have four stories to estimate their story points, Keeping the above theory in mind we can estimate the story point like this as mentioned in the picture. The wine glass we know is the smallest here, but there can be smaller containers than this like a teacup, so let’s give it small not extra small, from our map we know small is Story point 3. In a similar fashion, we estimate the glass as 5, the water jar as 8, and the aquarium as 13. Yes, 13 not 21 or more because we know there can be much larger containers from this.

Few points on Story Point:

Estimating a story point needs the estimator to have depth knowledge of the domain, product, technology, potential risks, dependencies, etc. will talk about the techniques to estimate a story point later in this article
Don’t Relate Story Point with the effort of work, if required we do the effort estimation on task level, Tasks are a child of a user story. The Value of the Story point has not how related to development or testing effort.
At the end of each sprint/Iteration, the completed/accepted story’s story points get credited to the team.
Keeping story point as 0 is a good practice for story type as Spikes or Discovery Story, as it does not add any business value or ship-able
The average of total completed story points for 3/5 or even more sprints is called the velocity of that team, Velocity is used to measure the sustainable pace and trends of teams.

End of Section “Understanding Story Point”

Agile Estimation Techniques for User Story:

Commonly used techniques to estimate a user story

There are many estimation techniques for User Story, like Delphi, Wide Band Delphi, Complexity Bucket, Planning Poker, etc. We will discuss the two most commonly used techniques in the software development industry which are

Planning Poker
Complexity Bucket

Planning Poker (with Video)

Planning poker is a technique to estimate the story point or size of a user story in the software development industry using an agile framework.

In this technique, The Team member Development team including Tester, Scrum Master, and Product owner participate, and optionally any external technical or functional expert can join on the invite. But Only the Development team member can estimate the user story, the development team can clarify any of their doubts.

As per the name “planning poker,” the estimator used to contain sets of cards that look like playing cards, and have the number from the Fibonacci series printed on each card. during expressing the story point each estimator shows the card to everyone to cast their feeling like the size of the user story, The Scrum master then mutually takes the most voted number and assigns it to the user story.

However,, if the team doesn’t have the story card handy, it will not stop them to estimate using this technique. Then can estimate by

Using Poker Card (as discussed earlier)
Simple Speak the number
Raise their Fingers
Smartphone app for planning poker

Normally the story point estimation takes place during the grooming session and marks the story to the groomed status once the story is estimated. And no further changes are advisable to that story.

Planning poker in distributed Agile Teams

We can estimate user stories with the same technique, even when our team is distributed in different geographic locations. The only difference is they are connected on the telephone and live screen sharing like WebEx, blue jeans, etc.

Story Points estimation Vs Effort Estimation

Remember We don’t and should not relate Story Points and Efforts.

Story Point is to estimate the Story Size, Value, Complexity, Risk, Dependencies, etc..

Where Tasks are the child of a user story is to estimate its efforts in Hours, for better planning and capacity Mapping

Too much difference between two points from different member

We always do voting to assign the most voted story point for a story, however, if there is a big difference between any two voting’s, The Scrum Master needs to intervene and ask the team member why one team member thinks its that high and another team member thinks its that low.

After the discussion once again within the team, The Team concludes with a final story point to assign.

Complexity Bucket (with Video)

Using a complexity bucket is another technique to estimate the story point for a user story. This technique is mainly used by calculating the technical aspects of the story, by creating a matrix of Areas of Complexity and Levels of complexity, and Aggregate the matrix values to get the story Point in Agile Estimation.

Refer to the picture for your quick Reference, Or explore the video to understand how it works with a demonstration the Agile Estimation.