That was brilliantly illustrated. Thanks

hey, I am not normally the type of person to comment but I just wanted to say thank you, I really appreciate the little memes you used for humor, I have an exam in few hours and I am really tense and they memes helped me to relax a bit, pulse they are really fun XD

Super simple explanation however the biggest hurdle is the reference point i.e. the bottle (some work) for comparison and somehow teams start their journey towards absolute.

Thanks, interesting esaier explained.. but 99% of companies IT count on FTE units, so "man day" as costs of every single role, and it changes according to expertise. All the Program/Projects end up on the Division Budget, counted on FTE for cost allocation and accounting. Actually that is the challenge, inside a Scrum team you can have a tester, or achitect , junior Dev, or Senior Dev and BA's, that the FET cost by day is different. The questions are: 1. who have the final word on assigning FTE to each actvitiy? as the PO is responsible for the backlog, does it include the FTE assignment? 2. how do you balance that each person on the Scrum team is fully busy to avoid cost losses? so fulle FTE of single role allocated to a task 3. How you manage a scrum team who is working on some Stories inside a Sprint that doesn't need 2-3 memebers expertise in that sprint? 4. which technique or method do you use to move from Story points to FTE? only average of past Sprints? then it might have differences with other vendors-teams as comparisons 5. Fibonacci numbers are 1, 2, 3, 5, 8, 13 and 21 (most of the videos use 20) why?

Good job 👍🏻. I wish everyone watch this video and correct their understanding about SP

Good explanation, you made it very easy to understand. Thanks

So why estimating in the first place? The first thing is, that the team can plan their sprint. But the sprint usually takes a defined amount of time (e.g. two weeks). When the team now decides how much storypoints they could fit into two weeks, based on their velocity, then it's an exact translation to time again, isn't it? If so, then why should the team use storypoints in the first place? I mean, they could compare time estimated work with another. The reference story took 2 days, how do we compare that with the new story? I think using story points over time is to loosen up the focus only on time and consider other factors such as complexity and give it a new scale

Short & clear!!!

So to avoid the variance of answers of how long something takes , we create another variance of how big something is relative to another. Yeah that makes sense .....

Nice and clear, thanks!

Very nice and clear explanation. Thx

Very clear explanation, thank you very much

Very good explanation!

Amazing answers.

Dude this is an amazing explanation, I watched couple of videos and still not sure of Story points, but now it is crystal clear. Will subscribe to your channel and hope to see more and more videos for people like me who are new to Agile and have recently started applying for Scrum Master roles.

This is the biggest part of agile I disagree with. Even with relative comparison I would argue you’re still using time. I dont think the key is not using hours or days etc but telling the team you only have a limited number of choices to choose from. That’s essentially what you’re saying from the wine example.

You can either look at one thing, you did and estimate another thing in relation to the other using time. Advantage is: Effective time it took for the first thing can be measured way more exactly than complexity or story points. How do you know the complexity of one thing afterwards? You cannot measure, so you either have only an approximate value for something already done.

Good one, thanks

very helpful !

Hi, the video is great however I am still missing clear understanding of why not estimate in say days vs story points? Just as story point takes into consideration complexity and amount of work, so can day. So, the only benefit of story point I see at this stage is really if you define date ranges to each story point. If you say 2 story points = 1-2 days, 3 story points = 3-5 days, 5 sp = 5-8 days. But then, estimating would be much clearer and easier to use the date ranges and it would answer the question when something can be done like 30-40 days (vs 2-3 springs). So, again, I dont see benefit other than less talking (it is easier to say "2" than "1-2 days". Could you try to explain that please and much appreciate?

I want to embrace story points but again... story points is just the frosting on the hours cake. Thirty (30) points of velocity/sprint is 15 points/week is 3 points/day... so 3 points == 8 hours. It always comes back to time no matter what anyone says.

Clear, Concise, Informative and Relevant! Not easy to do! Thanks!

Thanks.. But how a team can calculate the velocity for the first sprint? If they don't, again we are back to that point where as a team we do not know how many story points we can cover in first sprint!

It is trivial to convey the point that all estimates have uncertainty. I am so very sorry that so many people in the world of software development don’t understand that. But, that doesn’t concern me. My need is far more narrow. About every 4 weeks, my task is to ensure that I’ve entered my User Stories into ADO. After years of working in Agile I remain baffled as to why I write my User Stories instead of my boss. But that is the way it is. After I beat ADO into submission and ensure that the Sprint’s total for my Story Points is about 9, I don’t touch ADO until the end of the Sprint. But, when writing a User Story, One field I must populate is Effort, which has units of Story Points. Maybe one assignment is a quarter time assignment, implying about 40 hours over the next 4 weeks. It would be so much easier if the experts in Agile would just plainly state that a Story Point is on-the-order of 15 to 20 man-hours. Instead, I regularly forget that conversion in the 4 weeks since I last looked at AGO and waste another 2 hours trying to figure it out. Writing User Stories into ADO has no impact on by daily work. It is only a mind numbing, clerical and worthless task. User Stories don’t help identify the Unknowable Unknowns that dominate my work and they certainly don’t help me solve the problems that are discovered along the way.

How do we then relate story points to staffing. So, i have a staff that comes 22 days if i work out the estimation using days/hours - i know i can hire 2 resources or 3. but with story point - we are not able to do it.

Very useful video. qq, how do we estimate features and are feature estimated by the team or product managers at the program level? I see you estimated the feature as 60 when the velocity is 30. So who estimated the features and how. Thanks

@James Halprin - velocity stabilizes over multiple sprint practically, then how to we calculate time for first iteration when we dont know the velocity ?

If everything is comparative to a reference/ base story , what are relating our base story to .. is it time ?

What if the reference story itself is estimated incorrectly, that sets wrong benchmark for the team which could lead to overall estimation error at the sprint level. How do we rule of this possibility of error n ensure that ref story is well understood n estimated correctly

I need you to write a strongly worded letter to my client so they stop equating story point to days and then wonder why they can't project where features will land with any reliability

Academically, it's really simple right? Use Velocity. Reality is different, you have no historical Velocity data or dramatic changes in skills, project, resources that you cannot rely on historical performance (much like betting on stocks' past performance?). Then what do you do? And how do you plan and track schedule and calculate your team capacity? What's your NEW team's capacity?

You still don’t need points. Ideal hours (i.e. not elapsed) are just as effective. That doesn’t rule out relative estimates; if a piece of work took 2 hours and you face another piece of work that looks twice as hard/uncertain, etc. then it might well take twice as long. The fact that in the end, you’ve converted your velocity (based on points) into time just highlights points are just conflating the problem of estimation.

Great explanation. Thnx a lot

Wonderfully explained 👏

What a load of garbage...the example was using a concrete measure (glass height) vs cm..not abstract story points vs concrete measurement....Please read more! comparative estimates is best using CONCRETE MEASURES..

It's not ad-jill it is ad-ji-ill