Mastering Agile Estimation: How to Perfect Story Points Estimation

[@OeLean]

📚 GET OUR FREE AGILE BOOKLET WORTH 39$ oelean.com/agile-booklet/

[@9gager87]

This link is not available

[@JasmineSmith-y5x]

Update the link to access this book.

[@twinklebedi1921]

All your videos on agile are awesome. I had been struggling to understand agile, watched a few videos and read a few blogs, but nothing was as crisp and efficient as your videos. Finally I have a good understanding of how this works. Thanks a ton!!

[@OeLean]

Thank you do much, these messages are giving more energy to produce even more videos. Thank you

[@TheConfidenceFrequency]

This is such a great example. Your way of explaining things really resonates with me. Thank you!

[@funmijeje8072]

Thank you so much for this short and clear explanation of estimating user stories using story points.

[@usmansaeed4850]

Very easy way of teaching, thanks

[@AbdulWahid-yc7pt]

My sincere thanks to you for this professional explanation.

[@leespain9536]

This was a very understandable and succinct explanation. TY.

[@9gager87]

Such great examples, thank you!

[@SuperAbhishek333]

You are awesome ,explained so beautifully , God bless you. 😀

[@umaravi6158]

very nicely presented

[@kevindurham685]

Great explanation, but in the end it's still manpower that management cares about, not effort/complexity. The VP of IT cannot say "the feature is delayed by 13 story points" management wants to know about $ = hours.

[@bitaligners]

The time required to complete a tasks depends on who takes in charge the task in the team (a senior? a junior? a new joiner in the team?) and variables like meetings, emails, learning, code reviews, mentoring, other daily chores and the human factor (mood). Management needs to know about the budget for a milestone and the delivery date, of course. Story points and velocity can help to calculate the budget more precise than summing estimated working hours. Once you've got the average velocity of the last sprints and the gross estimation of your milestone in SP, you can calculate how many sprints you need to reach the milestone. Finally, you can multiply the cost of the team per sprint and you will have the budget $, as well. Keep in mind that are estimations.The bigger is the milestone, the harder is being accurate. Slice milestones, epics, stories in smaller ones, when you need more precision.

[@boerieza]

I love the video. My only objection is that when we start using a reference story, the video explains that the team only looks at the Effort aspect of the stories rather than the complexity or uncertainty (as described earlier in the video). We've encountered many situations where effort is usually less than the reference story. Still, complexity or uncertainty is way higher...so my comment would be that when sizing against a reference story, all three (3) aspects need to be taken into account, not just effort.

[@OeLean]

You are absolutely right, I might have missed that clarification indeed, thank you

[@akshaychari1703]

I guess effort collectively defines the 3 types here

[@Lateralus46x2]

Such a great video. Thank you for helping me understand how this works.

[@jaidevsharma975]

Simply and beautifully explained. Thank you.

[@ColoxixP]

Very concise and useful! Thank you so much!

[@Agilebatais]

well done 👍👍

[@suhailsultanmirani4630]

Your all videos are really interesting

[@kamal-hg5jg]

I always love it. It’s analytical

[@kartikkatyal7061]

Excellent video

[@deandaniel8307]

Very clean explanation, I'm glad that I understood concept well, but concentrate on slang... Some of the world's unble to understand... Just use basic pronunciation... Keep it up... Guys

[@khaoulagammoudi1094]

Thank you so much ! It was very helpful to me :)

[@noamsonnenberg1733]

A great video! Clear and easy to understand

[@a.nicholson1578]

Great overview, thank you!

[@Mav_Mahi]

It was great. Thx

[@srirambalakrishnan1990]

This is awesome . Loved it.

[@rajithkumar3424]

well explained , yet remains simple

[@marioooooo2]

Nice explanation thanks

[@elontrudeau]

Best video yet after watching 6.

[@gobbaka]

good and simple

[@ahmedelkomy413]

thank u for ur effort, is it logic to mix using relative and absolute estimation in the same project?

[@ajwathasan2317]

Relative estimation creates two problem in my opinion. Firstly it is really difficult to create a forward looking plan if we don’t have absolute value of each task and secondly if you have third party supplier then it will be difficult to understand where supplier resources spending time.

[@Sargam_Cafe]

please make a video on -" how will you estimate a story if you are very much uncertain about a story what it does and how complex it will be in future?"

[@bitaligners]

Usually the uncertainty can be cut down, clarifying the requirement with the stakeholders. Instead, the risk of unforeseen issues can be taken into account knowing whether the card involes 3rd parties, contractors, etc.

[@gokfaromika955]

Excellent!

[@someshpuppala47]

Great explanation... I have a one query I hope you can clarify.My question is what are the points should consider while giving story points as a tester

[@deronthornton924]

4:10 took me out el oh el....great video!

[@fouadchahd2969]

I love ur explanation, but imagine implementing scrum on a new team it's hard to estimate tasks for the first sprints is there any hint ?

[@dikshamasurkar1223]

How to handle such situation or scenario where team members are consistently estimating user stories not correctly. Let's take an example there are 1 user story which are simple can be done in 2-5 hrs but still team members are estimating it for say 2 days or so by saying buffer time in that we have experience members as well. How to approach as a SM also how to handle PO and other stakeholders in such case if it is consistently happening for few sprints.

[@OeLean]

Thank you for your comment Diksha, I think this is where it is important to break the link between Time and story points, The Scum master can ask the team to not think about time anymore and think about the complexity of the task (by using the fibonnacci sequence or Tshirt sizing), we do not necessiraly think about 2h or 2 days but we think about how complex is the task. if we are able to estimate the user stories in Story points instead of hours or days, then in the sprint planning, we will be able to see how many story points the team has accomplished in the previous sprint and that will be the amout of story points that we should take in for the upcoming sprint. Estimating user stories in time creates a lack of agreements between PO, SM and the team, and I highly recommend you start looking at how you can estimate your user stories using relative estimation

[@Gaming214-y3g]

Dont mix story points and man days. Story points are have nothing to do with time. If you are going to estimate in time, just stick to time based estimation. The whole purpose of story points being invented is to tackle the problem with time based estimation where everyone will have different perspective, experiences, skillsets and so on. To keep it simple, you might remember that story points is always about 'comparison'. Imagine someone show you a table and ask you what do you think of it's size? Is it big, small, medium? By only give you 1 table and nothing to reference, can you estimate its size? No. When given two tables of different size, you can easily tell which is bigger and which is smaller... AND most importantly, EVERYONE will agree and have the same point of view, regardless who you are, your experience, your skillset, and so on. And the estimation is fast and simple, that's the purpose of story points. Unfortunately, many developers or people find it difficult to accept and loves to complicate things by introducing formulas or their own interpretation, which is you research about story points, the author himself was disappointed and don't recommend people to use story points because it was misused and cause more problems (e.g. use formulas to calculate story points and every developer has to learn this thing which is different in different projects and in the end, the translate to man days??? Why then in the first place, they don't just estimate in man days? Why go around in circles and convert back to man-days?) Story Points, if used correctly, is fast efficient and can easily be understood by anyone, that means by the customers, stake holders and estimation can be done on the spot during refinements very quickly. It promotes transparency and trust to the customers, stake holders. My team has been doing this estimations in front of the customers, and they were very happy with it because they were able to understand and see why it was scored this way. Furthermore, any new joiner in the project could participate in the estimation, regardless of their skillset, experience or knowledge on the project. If you're going to use story points, never translate or relate to time or man-days. There more to share on how this is done and why we use story points in numbers format instead of the 'size' like S, M, L, XL, etc.

[@ajibolaibrahim4425]

​@@Gaming214-y3g Thank you for this great point

[@inframatic]

Great video! Why is there a value in, for instance, a tester giving a story point estimation to a complex development task? wouldn’t that tester be in capable of adding true input to the fields of complexity, uncertainty, or amount, if they know nothing about the task at hand Besides how it works and what it should look like in the end?

[@InfoLunix]

Tester estimation is for the testing process. They will estimate how simple/complex will be to test the feature. As testers, we need to create certain amount of test cases following different techniques before the actual testing.

[@gretchenkhoury2480]

great!

[@chandrakalamadgula3449]

Thank you

[@mageshkumarthangavel7801]

Nice explanation about the story points, one quick query here, Story estimation is performed in story planning ceremony or refinement?

[@OeLean]

Preferably in refinement sessions but it might happen sometimes that we need to review it in sprint planning

[@azizmech]

I like the video

[@bitaligners]

Complexity and uncertainty are often confused with individual skills or the time needed to complete a task. It's a common mistake, especially when you see big differences in estimations between senior and junior developers, or between those with a backend vs. frontend focus. The way is adopting a comparative estimation and thinking about the capacity of the team, instead of our individual skills. I talk about it in this video kzbin.info/www/bejne/gGKamI2vZ7Jle5I

[@sunnyescorel458]

Nagustohan ko ang ,story point mo.

[@reubenstephen1721]

If it's 13 Story points, it is recommended to break it up into smaller user stories, isn't fvaf right ?

[@OeLean]

The thing is that every team has its own understanding of what 13 story points mean, but in general I would say that if a story is 13sp maybe you can try it in one sprint and see if team is able to finish it, if not then of course 13sp should be split, in some cases some team are completely able to close a 13sp within a sprint and some are not, so I would say it depends on your team :)

[@reubenstephen1721]

One of the other things I struggle with is nowhere us an ideal scrum team size defined. A scrum call with more than 8 members presumably from attempting bring render a user story of a larger story point size, would not finish the scrum ceremony in 15 mins. Leading to either effort wastage or partial participation of the team.

[@OeLean]

What is in general said to be the best size for a scrum team is 7 +/- 2 which means anything between 5 and 9 is the best fit for a scrum team

[@najatrafiki211]

👍👍❤

[@LWarrenF]

Rather than using story points to estimate, consider COSMIC, which has been shown to more uniformly correlate with effort and which you could even use as a framework for adding items to your backlog. I've created a somewhat fun, and somewhat polished relatively quick introduction: kzbin.info/www/bejne/fnaZpqRjnMqFbaM

[@hanyelhadysoliman3604]

There is no tester roles in scrum !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[@chardeeluayon4046]

T

[@leeswitzer8242]

Why do you guys always use heavily accented commentary?

[@chakibbensari1850]

Excellent !