Learn agile estimation in 10 minutes

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

Is planning poker a relative estimation technique??

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.

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 !

super !

I am still confused.. unable to understand iterations and 55/2 weeks, how much hour for each story card.. very confusing explanation

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

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!

but during 1st iteration how did we know that 2 weeks of sprint was enough to complete build wall story? please correct me if I have missed something, thanks you.

thanks for making this digestible

Excellent explanation 🙌👏👏👏🤩🙏

thanks so much for your clear explanation!!!

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

perfectly Explained , Thanks

In 11 minutes you did what my Master's Degree PM' professor didn't do in two years. Hope he is not here in this chat :) Thanks

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

I find the reverse engineering of SP to time units an agile anti-pattern. A story will be delivered by the end of the iteration, that’s all we need to know. Otherwise, good explanation

Nice

Thanks a lot for this valuable and neet video! Very helpful.

Short and sweet explaination.Thank you

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

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

This was truly a great video. thank you.

Good job 👏 👍

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

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…

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!

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

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.

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????????

Useful. Thanks for the detailed information given.

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.

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!

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

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 😂😄

My friend, if there is a word more that excellent job, pls let me know!.
You have done an excellent job that the majority of Agile Instructors couldn't manage to do in 3 days of continuous talking.
Pls keep the good job up!
Your fan, from Iraq 🇮🇶

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

Thanks a lot. Cleared every doubt in a most practical manner.

Amazing

This is EXACTLY how I want everything in life to be taught.
So brilliant! Thanks

Can you be less ASMRish?

Very nice explanation, Thanks so much!!

Excellent explanation - most comprehensive video on this topic so far

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.

The following could help in some situations. Ann Latham suggested the following assessment:
1. Unfamiliar Complex
2. Unfamiliar Simple
3. Familiar Complex
4. Familiar Simple

Decent video, here is a comment for the algo

Excellent!!

A story point is NOT an abstract unit of time. Classic beginner's mistake.