Mastering Agile Estimation: How to Perfect Story Points Estimation

[Music] there is different ways when talking about estimating we either use relative value or absolute value relative complexity is easier to judge the absolute one look at these two dogs if I ask you which one weights more than the other pretty easy right but what about if I ask you to tell me how many pounds does each one weight this hard writes relative estimation means that we judge how big or complex a task is with respect to other tasks and one of the unit of complexity that can be used in this kind of estimation is

the story point so a story point is a number that tells the team about the effort required to implement in a given news of story one of the important reason to use the story point estimation instead of absolute estimation in hours on Mondays is that the absolute estimation has a kind of an emotional attachment to it if you estimate a task to take ten hours and it ended up taking you thirty hours then what do you tell you a manager why did you take more time than planned this could be frustrating for people as it

could turn to a blaming game if we are not able to finish tasks within the time frame agreed on storyboards estimation removes this emotional attachment by removing the link that we can have towards time as explained earlier story points estimation takes into consideration the effort needed to accomplish a task an estimate of the effort involved can be influenced by the amount of work to do the risk in uncertainty and the complexity in terms of amount of work needed consider the task of folding papers into the first task is to fold step papers and the second

task is about folding 100 papers although it's the same actions and the second task is not more complex than the first one but still the second task requires more work and should be given more stubby points it probably doesn't get 10 times more points even though there are 10 times as many paper Bob it should definitely have more story points the amount of risk and uncertainty in a user story should affect the story point estimate given to it if a team is asked to estimate a user story and if what needs to be done is

unclear then that uncertainty should be reflected in the estimate and if implementing a user story involves change in a particular piece of old code that has no automated test in place for example that risk should be reflected in the estimates tube last thing to be considered when estimating is the complexity complexity should also be considered when providing a story point estimate think back to the earlier example of folding 100 papers instead of 10 imagine now that the task is to fold 100 paper and make airplanes with it in this case even though we are still

holding 100 papers but there is more complexity to it and it should be reflected in the story point estimation in most cases a story point uses the Fibonacci sequence as a scale for sizing some teams will use t-shirt sizing as a measure stove a point estimation is typically performed during the product backlog refinement sessions and the product backlog is evaluated by the team who is responsible to turn the product backlog items to read customer value the product owner does not contribute to the estimation but he will have the responsibility to explain what the product backlog

items is about in order to estimate user stories each team would have to find one or two baseline stories as a reference these booths of stories don't need to be the smallest ones but this should be ones that everyone within the team understands and can resonate with once defined estimating all the other user stories should be done by comparing them to the reference using story so the team will give the Rivermen story and number from the fibonacci sequence then they will take the other use of stories one by one and each time ask the staff

use of story require more efforts than our reference story if it's the case they put it after that user story or they ask will it be less effort than the reference story and if it's the place then they put it before [Music] the team can then proceed and give story points to the other user stories if it requires twice as much effort as the reference story then we give a double amount of story points if it's twice less then we give it less during the estimation session it is very important to involve everyone in the

team developers designers testers each team member brings a different perspective on the product and the work required to deliver a user story I hope this video gave you a good understanding of story points and why we use a relative estimation instead of absolutes estimation please leave us a comment and follow us for more contents thank you [Music] you [Music]