Agile estimation is one of the most discussed and debated topic but still it confuse people. We always wanted to know more and more about estimation and planning. A group of people was asking below question during my recent talk in Delhi (PlayScrum meet) then someone requested answer on Quora as well. So I thought why not to write a detailed answer here.
5 most frequently asked questions related to estimation.
- Why to estimate?
- Which technique to use?
- What to estimate?
- How to estimate?
- When to estimate?
1st – Why to estimate because we all wanted to know how much time will take to get required software and how much money someone has to pay for it. So is there a way to answer this question when practicing Scrum? Because Scrum is for developing complex software. Why software development is complex? Because requirement is either not consistent, technologies keep changing or both. If something is complex then estimating duration and cost is not going to be easy but still our sponsor/business/customer wants some estimate. Estimate means approximation so there can’t be something called accurate estimate because accurate estimate is oxymoron either estimate or accurate.
2nd – Which technique to use to answer above question? Any technique is fine as long as everyone understand that this is just estimate and not accurate. 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 then how to do it?
3rd – What to estimate? Size of problem or time to solve problem? If we know how much time it will take to solve problem then there is no harm is estimating in days or hours. But we are talking about complex domain and also team to estimate so it will be difficult and in order to estimate in days we may need lots of input. Then what? Think about sizing problem in the basis of some factors like bigness of problem, requirement clarity and technology complexity etc.
Since we are talking about estimating size of problem then let’s discuss about technique again. Sizing problem in hour not feasible so we need some other technique and relative estimate becomes very handy here. Using story point, complexity point or use case point is useful technique. Since team prefer writing PBI (Product Backlog Item) in form of User Story so story point become popular else you can even think about complexity point or use case point as well if you are using other format for writing PBIs.
4th – How to estimate PBI using relative estimate? Oh yes if there is already an estimated PBI then we can estimate rest in relation to that but what if we don’t have any existing estimated PBI? Then we have to pick one PBI with moderate complexity (example – everyone agreed that PBI is moderate complex because there are 3–4 validations, 2–3 workflows, requirement is well understood and technology is not new). Since we have one now then next can be estimated in relation with 1st and 3rd in relation with 1st and 2nd.
But still our sponsor/customer/business wanted to know when they will get full product even before team start working on 1st PBI so what to do? There are ways to do but with rider. Rider is nothing but huge variation in estimation and there can be even 100% variation. So if team says 300 days then it can be as high as 600 or as less as 150 but this variation is not bad and gap will start reducing as team progress.
So there are many ways but I will describe only one here:-
- Team must estimate all PBI using relative estimate 1st
- Team has to identify available capacity for development for 1st iteration. Like 8 people working for 10 days iteration and 6 hours every day so total capacity will be 480 hours.
- Let team decide how much work team can commit for 1st iteration using 3 point estimate.
- Basically every team members has to give estimate in hours for each PBI. Assume team members has decided 20, 35, 30, 25, 30, 30, 20, 25 hours for 1st PBI then decide Pessimistic Number (35), Optimistic Number (20) and Most Likely (30). Now use formula Pessimistic+Optimistic+4(Most likely)/6 = 29.16 so basically 29 hours. Repeat same activity for other PBI as long as team feels they can take up work in 1st iteration based on available capacity.
- Assume team has picked up 8 PBI and has estimated around 450 hours work. Adding story points of these PBIs will give estimated team velocity.
- Since we know estimated team velocity and we already have estimated product backlog so we can simply divide total story point by velocity that will help to get number of iterations required to complete all PBIs.
- Since Iteration duration is fixed so multiply duration with estimated iterations will give expected duration of development.
- Team size remain same so we know estimated cost of one iteration so we can multiply cost with number of expected iteration in order to know expected cost of development.
- That’s all.
5th – When to do all this? Best time is refinement/grooming session not during sprint planning. Idea to estimate problem is not just number but also having better requirement understanding. So if we do prior to Sprint planning then we can avoid some late changes in sprint.
I facilitate agile engineering and scrum training for developers and testers in India (Bangalore, Chennai, Hyderabad, Pune, Delhi, Gurgaon, Noida), Singapore, Saudi Arabia, Dubai and Europe (Germany and Netherland). Agile engineering training includes Test Driven Development (TDD), Behavior Driven Development (BDD), Acceptance Test Driven Development (ATDD), DevOps, Continuous Integration and Delivery etc.