Popular Post
-
![Agilemania Blog]()
What is a Continuous Delivery Pipeline an...
Nov 17th 2022 - BY Agilemania
-
![Agilemania Blog]()
Agile Transformation and High-Performance...
Dec 6th 2018 - BY Agilemania
-
![Agilemania Blog]()
What is AGILE? – What is SCRUM? An...
Feb 14th 2022 - BY
- Naveen Kumar Singh
- Jul 9th 2016
Estimation in Agile Software Development is one of the most discussed and debated topics, but still, it confuses many people. We always wanted to know more and more about estimation and planning. A group of people was asking the below question during my recent talk then someone requested an answer on Quora as well. So I thought, why not to write a detailed explanation here. 5 most frequently asked questions related to estimation.
- Why estimation needed for software development
- Which technique to use for estimating product backlog
- What are relative estimation techniques in agile
- How to estimate product backlog using story point
- When to estimate story and product backlog
Why Estimation Needed for Software Development
Because we wanted to know how much time will take to get the required software and how much money someone has to pay for it. So is there a way to answer this question while practicing Scrum? Because Scrum is for developing complex software. Why is software development complex? Because the requirement is either not consistent, technologies keep changing, or both. If something is complex, then estimating duration and cost will not be easy, but our sponsor wants an estimate. Estimate means approximation, so there can’t be an accurate estimate because the accurate estimate is oxymoron either estimate or accurate. Estimates help in planning releases, funding development efforts, and mitigate risks.Which Technique to Use for Estimating Product Backlog
Any method is acceptable as long as everyone understands that this is just an estimate and not a contract. You may use user story point, functional point, use case point, complexity point, number of days or hours, etc. But we are talking about complex software and given by a team, not by an individual, so better to use acceptable techniques for everyone. At the early stage of my software engineering career, my manager introduced complexity-based estimation, and it was useful. We were using five scales — very low, low, medium, high, and very high. Very low means approx one day, low means 1–3 days, medium means 3–5 days, high means 4–8 days, and very high means 7–12 days. Later we changed it to T-Shirt size, but it was similar. When we used story points, then it became confusing because points were also numbered. Many tried to convert points directly to days rather than using it as a scale. Although story points are more popular nowadays and you can try the same but be careful.What Are Relative Estimation Techniques in Agile
If we know how much time it will take to solve the problem, then no harm in estimating in days or hours. But we are talking about the complex domain and team to estimate, so it will be difficult to estimate in days and hours. Difficult but possible if everyone understands the purpose of the estimate. If the objective is to forecast releases, have some initial budget allocation, and tracking progress towards releases, then no harm in estimating ideal days. If the aim is to hold an individual, team, or organization accountable for the same, it defeats the estimate’s purpose, and then it turned out to be a contract game. In such cases, people use psychology rather than mathematic to see what number will win the contract. Story points or any relative estimate helps in avoiding the contract game. Relative estimates are about sizing problems based on some factors like bigness of problem, requirement clarity and technology complexity, etc. Since the team prefers writing PBI (Product Backlog Item) in User Story, so story point becomes the perfect choice. You can even think about the complexity point or use case point if you are using another format for writing PBIs.How to estimate product backlog using story point
If there is already an estimated PBI, we estimate the rest compared to that, but what if we don’t have any existing estimated PBI? We have to pick one PBI with moderate complexity (example — everyone agreed that a PBI is an intermediate complex because there are 3–4 validations, 2–3 workflows, the requirement is well understood, and technology is not new). Since we have one now, 2nd PBI can be estimated comparing with 1st PBIs. Similarly, 3rd PBIs can be estimated comparing with 1st and 2nd PBIs. We can use the Fibonacci series to estimate and can define scale: -1 — Very Small, 2 — Small, 3 — Medium, 5 — Large, 8 — Very Large, 13 — Very Very Large
The team can use planning games to estimate. Planning Poker and Estimation Wall are popular techniques among the agile teams. I will write about both in my next blog. Estimates given in points do not answer our initial questions. How soon the product gets completed, and how much will it cost? Our sponsor/customer/business wanted to know when they will get the full product even before the team starts working on 1st PBI, so what to do? Try to understand the purpose of the same before providing any number. Usually, it is for awarding a contract to the vendor or securing the initial budget. Awarding a contract based on only a financial quote is not advisable, and many companies don’t follow it anymore. However, financial quotes are still needed to formulate an initial contract. Some companies follow analogous estimate, few follow PERT estimation, and many follow capacity based estimation. Analogous estimation: it is based on historical data. We look at the total points that the team has identified and compare with past projects and quote some number. It also depends on who owns the risks due to requirement changes. PERT estimation: it is also known as the 3-points estimation technique. Here are detailed steps for the same.- The team must estimate all PBI using the relative estimate.
- Let the team decide how much work the team can commit for an iteration and choose three numbers. The highest number, called Pessimistic, the lowest is Optimistic, and the common one is called Most Likely.
- Every team member has to give an estimate. Assume team members have decided 20, 35, 30, 25, 30, 30, 20, 25 points for 1st sprint. Then Pessimistic Number (35), Optimistic Number (20), and Most Likely (30). Now use formula Pessimistic+Optimistic+4(Most likely)/6 = 29.16 so 29 points. It is the estimated velocity.
- Since we know estimated team velocity and already have estimated product backlog, we can divide the total story point by velocity to get the number of iterations required to complete all PBIs.
- Since Iteration duration is fixed, multiply duration with estimated iterations will give the expected duration of development.
- Team size remains the same, so we know the estimated cost of one iteration to multiply cost with the number of expected iterations to know the expected cost of development.
When to Estimate Story and Product Backlog
The Scrum team can estimate either during product backlog refinement or during sprint planning events. I personally prefer estimating during product backlog refinement. Some companies also follow the release planning technique, but technically it is a product backlog retirement that happens before the first sprint.Where to learn all these?
I teach in my Professional Scrum Master and Professional Scrum Product Owner classes. You can join our upcoming mentoring sessions too. I would suggest exploring the Agilemania website.Find Our Upcoming Trainings
Naveen Kumar Singh
Naveen is a Lean-Agile Coach, Professional Scrum Trainer (PST) and Internationally acclaimed Speaker in many Conferences and Agile events.
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Popular Post
-
![Agilemania Blog]()
What is a Continuous Delivery Pipeline an...
Nov 17th 2022 - BY Agilemania
-
![Agilemania Blog]()
Agile Transformation and High-Performance...
Dec 6th 2018 - BY Agilemania
-
![Agilemania Blog]()
What is AGILE? – What is SCRUM? An...
Feb 14th 2022 - BY
Agilemania is a group of passionate Lean-Agile-DevOps consultants and trainers focused on delivering measurable, sustainable results for our clients.
Connect with us on Social Media
Knowledge Area
Certified Partners
Agilemania Technologies Private Limited © 2024 All rights reserved.
