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.
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:-
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.