Learn agile estimation in 10 minutes

If you found this video useful, you might like to watch the entire course that was created as a result:
www.oreilly.co...
Each of the videos follow this same style, plus there are exercises and more details about the underlying values of agile, and how they can be used to adapt agile to fit your particular needs.

[@sheetalbade9727]

I am a certified Agile Coach, and this is probably the best Agile Estimation explanation I have ever seen. Thanks for sharing.

[@gava2439]

It took my lecturer 4 three hour classes to explain this and I still left confused at the end. You did a fantastic job explaining everything in just 11 mins. Very well explained. Thank you 🙌🏻

[@OmarRam]

I took several online courses, and none of them could explain how to properly do an estimation. This is the best explanation on the web! Thanks so much for sharing!

[@nirmalmaheshwari9385]

This was the best i have ever seen regarding estimation in Agile, even various online courses would not be able to tell this in their 5 hour recordings. Thanks

[@joynandi9906]

So True

[@SOlah-yc1bk]

every time someone asks me, what the idea behind the story points is, I am sending him this video because it really left no open questions, thx for the good work!

[@mmuradiqbal-technuggets-ja3597]

Thank you. That was very very helpful. Value points for this video 89, Story points, 13, BFTB = 6.8. This was on the top of my list. I shall mark the estimation task done now.

[@nedcpa]

Great video. In summary: In agile estimation, story points are used as an abstract time unit to avoid absolute time estimates, while value points measure task importance. The Fibonacci sequence is favored for story and value point estimation in agile because it fits human thinking.

[@FawwazSyarif]

I can't believe this video is 6 years old but still very relevant to how to estimate agile! Thanks a lot!

[@payrollcontinuouslearningp3096]

...I can't believe this comment is 3 years old but still very relevant! LOL!

[@Chevindu]

@@payrollcontinuouslearningp3096 hahaha. Indeed!

[@TaqveemKhalid]

Standing ovation! this is the best explanation of story points I have come across in my career as an agile developer. Thank you so much!

[@unoproperties9286]

Absolutely!

[@the_wizard_exe]

you're very kind what you invested in your video with , everything's clear you just helped me lots !

[@kuriousketo642]

The best video yet! Just went through this sizing exercise yesterday at my job but had no idea how to apply. This is going to be so helpful for our next meeting. I understood the whole Fibonacci number adding, but how to apply it. That is where I needed help. Thank you!

[@sayedfaiztanvir4733]

We don't have value point concept in our project as customers don't accord such point to a story. Product owner prioritised stories depending on how important it is for release deployment, in consultation with client. I enjoyed this video since explanation is incisive and invokes tremendous interest amongst Agile practitioner.

[@nicopicco]

LOL....it's Sept 2020, 6 years after this video. And I have to EXCELLENT. This is the best video., It is bang on with exactly what I've seen happen with my development team.

[@vinodk3960]

Very crisp and clear. Thanks for the video David.

[@crownkedar]

David requesting you to please continue making such very valuable to all, Thanks

[@DavidGriffithsEsq]

Well you ask me four years ago, so I should probably start doing them again :D

[@kingsleyokoeri1177]

This is, in all palpable sincerity the best explanation for agile estimation I’ve seen❤

[@abhijitchaudhuri3723]

Beautifully explained

[@GauravGupta-nc7kn]

I want to thank you from the core of my heart for explaining such a tedious topic with so simplicity.

[@brownthepaper]

Its such a great example for how story points works Thanks so much, I struggled hard before this vid!

[@prateekm1145]

A clear-cut & very informative explanation. Maximum "Bang for the buck"!

[@exchequerguy4037]

Outstanding -- had never heard of value points before.

[@seleniumautomation7409]

simplest & best i have seen till now , keep it up. you rock

[@mukulgupchup2503]

Complex understanding is made very simple! Great to watch and understand the concepts. Thank you so much!

[@amitmelb]

Very well explained. Clearly articulated the heart of the matter. Valuable !!

[@londonolson5375]

Thank you. This was a useful overview of Agile estimation

[@LL-lb7ur]

Very clear explanation. And very nice mindmap. I now understand the whole picture

[@gizmo51383]

This is good. The 'bang for the buck' calculation is awesome. However, using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story. Your longest story may be a number that would break the Fibonacci sequence and you may have tons of smaller stories with similar or even exact story point numbers and maybe just a few larger stories (or vice versa) that won''t follow the sequence at all. Also, I do understand delivering value early but it is really the customer that is going to let you know what they want built first and then you meet with the team to see what is realistic or not and try to be as close to what the customer wants built as possible. That may mean a lot of smaller stories early or it may mean just larger stories...in my experience, we usually start working on bigger stories and tie in smaller stories for the initial Sprint...usually it balances out. It is usually best to focus on building, testing and deploying a smaller story that is of high value first so the customer can see it, test it out and be happy while your team works on bigger stories (if possible!). The video does a good job in presenting what should be the velocity for each Sprint (which does usually drop)...overall, a very good video with some great points...but note that it will never be as clean as estimating things in terms of the Fibonacci sequence.

[@uhrihriavbenagha1826]

if using the Fibonacci sequence as a way to estimate story points is not realistic and actually would superimpose a rigid time structure per story, what do you prefer to use for story points estimation?

[@mabobine420]

Very informative and I appreciate you sharing your experiences and knowledge. Could you please guide on the following: 1. Conducting a story point estimation throughout cross functional team means 1 representative from every functional group or all team members across organization? 2. A developer estimate 3 points for story vs tester estimate 8 points. Tester has to perform cross browser testing hence the scope of testing is large + different permutations/combinations to test the business rules. Which one will be taken as correct story point: 3 or 8? 3. Is there a baseline for effort based on story points e.g. 1 story point take 4 hours, 2 take 6 hours and so on 4. Say story point estimate consensus built on 3 story points. How do you schedule it if it's a 3 hour estimate by team. I mean in the end it will be development, testing, bug fixing, regression so will it be 3 hours each all the tasks together or 12 hours i.e 3 hours × 4 tasks

[@uhrihriavbenagha1826]

Nice video, thanks. What is the point of all the ordering, prioritization processes & calculations until the BFTB sores & reordering, if the team would still have to brainstorm & reorder finally based on the dependencies? why not just prioritize based on the dependencies in the first place instead? like in the traditional PM

[@majed5006]

Very nice explanation, Thanks so much!!

[@nainakhullar4366]

Beautifully done!!! It makes so much sense to me.

[@balaloganathan2621]

Awesome, never seen better elucidation in this topic!

[@williamfox7773]

Conflating story points with time is a fundamental misunderstanding of their use. They’re meant to convey complexity and risk. The reason we remove time from points is because different developers code at different rates of speed but, as a team, we need a way to relatively size the lift, agnostic to developer…

[@rajeshparkar5683]

superb, very well articulated!!! Thank you.

[@alejandragarcia429]

You are sooo good at explaining. Thank you so much for this video ♡

[@rupinjeremiah9589]

Outstanding presentation - simple and clear!

[@gokulgopinath7373]

Awesome. This cant be explained any way better. Thank you..

[@ignacio_uco]

Great job! Clear and simple!

[@deepaktak4659]

perfectly Explained , Thanks

[@rakumarudu]

Thanks for taking a common topic and making it interesting video. Please add more videos

[@jmsterdam]

This explanation could have been perfect if you had used ‘new product development’ examples instead of ‘production work’ with little uncertainty. Dropping the story points and value points into the value/effort matrix would have been even more visually appealing rather than the calculated ratio. Other than that, i couldnt have explained it better... well done!

[@DavidGriffithsEsq]

I will take that onboard for any future videos :)

[@hafizalnaseer8741]

All Scrum masters should go through this.

[@thangtrinh6599]

thanks so much for your clear explanation!!!

[@cspalmisano]

The whole point of story points (pun?) is to abstract away time. i.e. - Don't correlate story points to hours. If you want to use hours, just use them and leave story points out of the conversation.

[@cspalmisano]

But I like the idea of assigning BV to stories. Helps Product Owners / Managers prioritize their backlogs

[@emezar83]

The best explanation, thanks!

[@roliverkim]

Outstanding! Congratulations!

[@sooryanarayanan3503]

Fantastic tutorial! Just like the formula for calculating the Bang for the Buck, is there a formula to calculate the velocity and the time taken for the user story to be completed even for the 1st iteration? Thanks in advance !

[@DavidGriffithsEsq]

Hello Soorya. The first iteration is when you really are guessing based on virtually no evidence (other than any other similar projects you work on). The good news is that *after* the first iteration you start to gather real world knowledge (the number of points you completed) which you can feed back in to future iterations. Over time, the estimates get more and more accurate.

[@silky2204]

Thank you.

[@NicO-cm2xo]

Awesome story drawing👍

[@rheroberts868]

This was sooooo good. Where can I get more of his Vid? I only saw 2 on this channel 😔

[@DavidGriffithsEsq]

Hello Rhea, It was actually turned into a full course by O'Reilly Media, which I drew and my wife narrated www.oreilly.com/library/view/the-agile-sketchpad/9781771376099/

[@oddiiiyadav7409]

Good job 👏 👍

[@scotttheus9529]

This is a great explanation. However, not even a minute into it the presentation defined a story point as a measure of time, which is incorrect. The standard definition of a story point is measurement of "the relative work, risk and complexity of a requirement or story." (PMBOK Guide, 6th Edtion) Linking a story point to a unit of time is misleading and will result in teams taking the easy route by saying 1 story point = 1 hour.

[@DeOPe]

Yep that's the point, thanks for your comment - that was the same what I thought. Maybe at the beginning with less knowledge you need for 3 SP more time than weeks later when you gained more knowledge or experience. The complexity of 3 SP will be the same but you are maybe faster and are able to produce more output in the same amount of time => velocity goes up. Never bind time to SP

[@rodneymuniz9259]

awesome video! GOLD content! thank you!

[@SamTraynor-zc2wt]

Hi this very informative, however I don't see how it can work within a construction contract scenario for example JCT ect ??? all it basically gives you is a predicted Program of works with a cash flow forecast????????

[@erikschaepers]

Excellent - thank you very much

[@Lateralus46x2]

How do dependencies come into play? You may have roof as the greatest value but you can't get it in because realistically, you have to pour the concrete for the foundation first, then build the walls, etc... until you can actually get to the roof.

[@JoeBaloney]

I still don't get it. It's like estimating distance in miles, then record it as Fahrenheit. During the estimation process, we slip in intimidating words like Fibonacci so people will think we know what we are doing

[@svendtang5432]

Funny like Scrum videos always consider things as projects.. We usually sit on feature or platform teams never project based just strings of epics so we measure constantly

[@cantugcavusoglu7656]

It's okay up to a point. I only have a question in first iteration. When you are starting to first iteration of a new product, you gonna need to tell a roughly time that it is going to finish. You cannot say to the team that I have a story but I dont know how many sprints it is gonna take. Have you got answer for this question ?

[@krisputnam2143]

Very well explained!

[@cleytonsilva6879]

Very good method !

[@MahmoudSeoudiCEO]

Amazing

[@RobertJones-cr7pb]

How can the 'value-points' model apply to teams that have multiple, discrete stakeholders? How can the value-points of different stakeholders be evaluated against one another?

[@kasperlarsson8648]

Quick question, how do you know that the first estimate you make of 55 is right? You just said we make estimtes bad without anything relative? Doesnt that also mean that when you @wrongly say 55 every other estimate between the lowest and highest will be wrong? Thanks!

[@DavidGriffithsEsq]

Hello Kasper. Apologies for taking so long to reply. I'd missed you'd asked a question :) All estimates are guesses, and so when you guess that the 55 story point story is about 26x the 2 point story, you may well be wrong. But you will find through the iterations that your guesses will become more accurate. Why? Because you will have more and more completed stories and real world experience on the project, with a given team of people. Please note, that story points *are* relative. In the example the smallest story was given the value 2, and the largest given the value 55. You could have given the smallest story 21 points, and the largest 610 points. The ratio of 55:2 is pretty close to 610:21 (610, 21, 55 and 2 are all Fibonacci numbers). What matters is the relative size of the smallest to the largest. What those story points translate into actual hours and minutes will become clear as the project progresses. In reality, you might not even care what 1 story point equates to in absolute, because all that really matters is making an estimate as to how much work you are likely to complete in the next iteration. Apologies for the long, waffly response. I hope this helps :)

[@Divinecitizen]

Voice is very low. The video is really good.

[@marcotroster8247]

Development time estimation doesn't matter. Use cost of delay to figure out how bad you need the feature. Usually the value of really important tasks is high enough (multi million costs) to justify basically any activity. Then you can leave out estimation entirely and actually get the work done which will make your customer happy 😂😄

[@koresam9351]

Great explanation, thank you 😇😇😇

[@GeovaniBruno]

Brilliant!

[@johnsondsouza2469]

very well explained! Thank u.

[@sandeepnain5074]

Perfect!!!

[@essianenelson6545]

This is awesome!

[@julianwieg]

Thank you!

[@nkommukuri]

Thank you for the valuable video explanation on estimations

[@omerriaz2535]

My question is here, how we are calculating the Value ?? Story points make sense to me coming from Fibonacci. But value Number?

[@DavidGriffithsEsq]

You don't really calculate value. A customer defines the value that the story has to them. They can choose Fibonacci numbers for value, but value and story points are quite distinct entities.

[@itorres008]

I was trying to apply this method, not to development, but on prioritizing some company projects. Then I found that the projects have an additional variable, which is material costs. That variable is not specifically considered in this model - let's say for development some of the stories require buying hardware or software which is not effort, but nevertheless affects the decision making process. Value and effort can be the sae for two stories, but one requires HW or SW costs which makes the other one a higher Bang for the buck. Would you favor this cost be abstractly considered in the Story Points? Or should we incorporate the actual cost of materials per story and incorporate via formula in Story Point or as a third number in calculation. Such as Value Points / (Story Points + Material Cost Points)?

[@ziddib8522]

You estimate the 2nd story based on first Story. But hiwbdo you estimate the 1st story?

[@DavidGriffithsEsq]

You place it in a range of of low to high. Remember: you are not making estimates in actual money and actual time. Each story is relative to all the others. The estimates are just abstract numbers.

[@kishoregeorge1129]

Great!! Very well explained!

[@mancobamancoba9844]

Kishore P. George h

[@WildTraderAppeared]

super !

[@nihar1213]

precise. Thank you.

[@serpentinefire2337]

Is planning poker a relative estimation technique??

[@DavidGriffithsEsq]

It generally would be. There's nothing to stop anyone using a poker-type game to make absolute estimates. But you are likely to adapt more to reality if you use it for relative estimates.

[@liviafernandes3640]

Can you answer me, do we do the estimation during the sprint planning? If not, in what moment of the project must we estimate the value and story points for each task?

[@darreljackson5422]

Typically just prior to it (eg day before). You’ll get into a regular cadence. Don’t forget it’s relative so you are re-estimating the new backlog items with the existing ones. Since it’s a reoccurring, sustained activity you may want to introduce a ceremony for it at whatever cadence makes sense for your team.

[@noranel-sherif1263]

Well Done !!

[@AlergicToSnow]

Excellent

[@dianal3627]

How do you decide which point to give 21 vs 34? Maybe 0-5 is low, 8-13 med, and 21-55 is large?

[@VanessaKlinger]

I think He said that would be determined by the developers or whoever is doing the work..

[@peeya4966]

How do we make sure that value point is always greater than the story point? I see that this should be mandatory for division. What do we do if we have story point 20 and value point 10?

[@tookootek]

Hi Peeya, Just a friendly input here, Story Point and Value Point are two different items, they are not dependent with each other. In a way we can say Story Point pertains to size of work while Value Point lean towards prioritization (A must have VS good to have) of work/feature. With this in mind it does not matter which one is higher, SP or VP as long you include the decimal place in your BFTB the result should hold true when you sort it.

[@kiran7161]

Thanks. How do you set team velocity for first sprint when we start agile?

[@RobertHoffmann]

You don't, or just a rough ballpark estimate to get you going. Thus a good idea not to use 1 month sprints :-)

[@kiran7161]

Robert Hoffmann thank you

[@patchesrich6690]

A must to react now. When you placed the number 55 then the sequence ref of said math equation I came up with 6 in my head instantly. IMO trim back considering the mean value of constant for think of waveforms in relativity to WL•WH=? Use this formula perhaps and input the variables that still give continuity but the end sum be greater as I work out the details? One wave pattern I am thinking that is off the top of my head is sound wave pattern is the fastest with less resistance. Watch bottom factor being input as HRR = >44 within no lower limitations than given as for the limiter revv max constant mild variable w/given range of 120.0_ 130. Hope this helps.

[@Tiefschneegiftler]

I still need to understand one thing when comparing it to Kanban: is the "story point" a story and the house is the epic or is the house a initative? Or am I getting this all wrong?

[@darreljackson5422]

The story is the “card” in this example. You could interpret the group of cards that make the house as the epic, yes. But in this video he called it “project”. The “story point” is a unit of measure that measures size/effort of a story.

[@donaldewart2275]

I'm sorry, but this is not good. It make the rookie error of equating SP to time - it's not. Then showing fibonacci equation turns people off and doesn't describe why it helps (it's not about accuracy) just 'how people work...'. We also typically don't use the strict fibonacci series, but use 20,40,100 for higher values. Can a large story (55point) be done in a sprint? seems unrealictic and will lead people into a trap. no mention of breaking down at 13... No mention of reference stories to help the calibration. Then mentions project Manager - are we doing projects? It would have been good to see how to track using burndown and burn up charts.

[@LWarrenF]

For Agile estimation, 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

[@svendtang5432]

It’s funny how these videos always talk about “when the project ends” what if the projekt “never” enes.. like our commerce site ? Valmue May decline temporarily but because it’s relative to the running backlog the last comments are not valid

[@arthurmarques1794]

This system is better applicable on product development. I don't think that you can use it without adaptation to business management.

[@tookootek]

Hi Svend, Interesting question you have there. I agree with you that it is usually presented that way but I believe that is due more on being a best 'Hello World' example while special cases like Software Maintenance or Enhancement may need more context and perspective to present. The word 'project' itself has a lot of meaning, for example in Project Management, a project is aways has start and an end. Anyway David did an awesome job presenting the estimation however at the end of the day Agile is a framework, you adhere to the principles but you are not required to follow certain or specific method to the letter. You apply what best work for your team. One team may work on a software development (New, Enhancement) while another work on Software Operation (Continuous), both may use Agile but their work prioritization defers. Please let me know what you think, it is always good to have a friendly share back and forth.

[@stefano8936]

The problem is ALWAYS people

[@FijiSleepy]

Did you use agile to create an Agile estimation video 😂🤟

[@TitanicTiming13]

Can you be less ASMRish?

[@wewantthefunk73]

Story points aren't time, they are complexity, effort, and risk. This video is bad.

[@letsbesane]

There is no credible scientific evidence that a human being is naturally accurate at making a relative estimate. This is a false premise. The agile point system fails for most teams because it is mathematically broke, scientifically it's not provable and a unit-less number has no meaning. If someone has never framed a house before they are going to take a long time to do it the first time. The second time could actually take a lot longer when building a house with a different design. The fact is there are many variables in completing 2 similar tasks. The skill of the person, the tools that they posses, their educational background, their knowledge through an epistemology review all produce drastically different capabilities and speeds for the same task. The variability of skill level in many cases precluded developers from even completing tasks. The notion that a plumber would show up to your house and tell you that he could replace your water heater in 13 points is the most ridiculous notion and if this is a valid method for software development then it is also valid in every other profession.

[@108109093]

The balancing between the story point and value point using "Bang for the buck" is important! Nice explanation

[@koresam9351]

Great explanation, thank you 😇😇😇

[@brandonpearman9218]

Nice explanation but not sure about the name "agile estimation". The Manifesto for Agile Software Development makes no mention of story points. So why are story points referred to as "agile estimation", I assume it is because a few frameworks include this style of estimation. Unfortunately it gives the impression that you are not agile if you don't use story points. Maybe it should be called Fibonacci estimations or story point estimations or scrum estimations?

[@kote.shengelia]

Scrum guide does not mention this either :)

[@scotttheus9529]

Does it really matter how it is named? Agile frameworks estimate in work effort, while Waterfall estimates duration. The primary goal is to determine how much work a team can have in process at a given time (WIP limit) and when the MVP will be done (velocity.)

[@brandonpearman9218]

@@scotttheus9529 yeah it does matter because agility has nothing to do with your estimation style. And the moment a person implies that part agility is to do estimations in a specific way, that person has lost the plot of what agility is. By correctly defining agility you are able to start taking advantage of its benefits.

[@scotttheus9529]

@@brandonpearman9218 I understand and agree that "agile estimation = story points" takes away from agility. I also agree that by not mentioning other means of estimation the video implies by omission that story pointing is the only "agile" technique, and that the Fibonacci scale is the only "agile" method to determine the points of a story. Any good Agilist worth the paper their cert is printed on knows that this is not true. My point is that "story points ∈ agile estimation;" they are an element of all the estimating techniques used for agile frameworks. The Agile Manifesto makes no mention of estimations at all, the Scrum Guide discusses estimates, but does not name a single technique, and the video uses a very common method used for estimating stories.

[@brandonpearman9218]

@@scotttheus9529 yeah sure, i get you. I think we on the same page regarding meaning. But if i were to re-express my point, my concern is using language which the broader community may take and limit the views and techniques for agile software development. This is a valid concern because it has been happening the past 20 years, and now most people don't actually know the difference.

[@boodyghadban]

Great. i did not get the Agile estimation 100 % until i watched this. Thank you so much

[@GirishReddyvariR]

This is the simplest and best explaination of the agile estimation in limited time. Thanks a lot.