Agile estimation - why story points are better than using time?

Hi! In this video I'm talking about why we use points estimation instead of estimating how much time will features take to implement.
This is something I often need to explain to junior developers and I believe it deserves a few minutes video. Agile software development, while in my opinion strongly overrated and in the past overhyped, became a standard in our industry and whether we want it or not, sooner or later we have to deal with agile estimation, Scrum and other rituals.
🎥 Video timeline:
0:00 Intro
1:05 What's wrong with time estimation
3:30 Example from non-software world
4:15 Introducing (story) points
7:12 What is "velocity"
8:50 Outro
As always, if you have any questions, suggestions or foodback, you can contact me:
✉️ email: [e-mail]
🐦 Twitter: @GregoryWitek
🌏 website: notonlycode.org
Credits:
The Kenyan gentleman is Eliud Kipchoge and I took the photo from Wikipedia: By Denis Barthel - Own work, CC BY-SA 4.0, commons.wikimedia.org/w/index...
The Mongolian gentleman is Takanoiwa Yoshimori and I took that photo from Wikipedia: By FourTildes - Own work, CC BY-SA 4.0, commons.wikimedia.org/w/index...

[@NotOnlyCode]

What's your experience with estimations, do you have some best practices that worked well in your team?

[@mohammadawaydah]

Man! I am not sure what is your exact profile but you have super clear way of explaining things!!!

[@NotOnlyCode]

Thank you! I'm happy it's easy to follow

[@dawidkotarba5146]

Yet another fantastic video! Thanks!

[@majed5006]

Very nice explaination, Thanks so much!!

[@deeptilenka]

Very nice and clear explanation on estimations.

[@NotOnlyCode]

Glad it was helpful!

[@futuresavers9564]

Hello and thanks buddy, funny how am just seeing your channel. This is the best video on story points have watch. I have a QUESTION: How do you determine the velocity of a team. The accurate velocity of a team that is new to using story points?

[@NotOnlyCode]

Hi, thanks for your question. Since it's a one-time thing for every team, I don't have much experience with it, but there are a few ways you can try: 1. don't - just accept that for the first 2-3 sprints you don't know the velocity; you can have a number of tasks prioritized and ready to start, but don't commit to any stakeholders (this might be quite challenging) 2. estimate old tasks - this is an interesting approach, you can look at the tasks delivered over the last 6 weeks, define their size, and base your velocity on that; this has one more benefit, which is that these older tasks can act as reference tasks when estimating (especially that they're already done, so it's more like deciding their size rather than estimating) 3. less accurate but much simpler - base it on a number of tasks delivered over the last few weeks, without estimating them. Estimation of a single task varies a lot (from 1 to X points), but when you look at a group of tasks, usually their size on average is similar (in most of the teams I worked with, using Fibonacci scale, the average is like 3.2-3.8 maybe). So you can assume that if the team delivered 10 tasks every week over the last 6 weeks, if you take 10 tasks from top of the list (make sure you don't skew it by sorting by size), then you should be kind of ok

[@ruslanvidnichuk6425]

Great video!

[@NotOnlyCode]

Thanks!

[@secemployee7726]

Gud one

[@bassemawhoob]

But isn't estimating story points in that manner still relative to individual capabilities? In your example, if Alice estimates a new feature in story points it will be completely different than if Charlie estimates it

[@NotOnlyCode]

Not really, because we have constraints. Let’s say we have scale 1,2,3,5,8 - 1 is the smallest task what we might do (let’s say changing something small in the UI) and 8 is the biggest single task we have (lets say a complex form with 15+ fields). Now everyone will estimate other tasks knowing what 1 and 8 stand for. So no matter how skilled senior dev is, they know that a complex form is 8, so the reference is not their skill, but some example task

[@bassemawhoob]

​@@NotOnlyCode Ah, got it - thanks for the insights, very helpful!

[@Thkaal]

So basically story points are just ways to say how much more you should be paid I mean two coders who put out the same product and the exact same product one does it in a day and one does it in 100 days that guy who did it in a day should be paid more because he put in more effort therefore he put in more story points is that correct

[@NotOnlyCode]

Story points should never be used to measure individual performance, it leads to gaming the system and unhealthy internal competition

[@hthring]

story points blow, can you imagine story point poker

[@hthring]

trying to abstract points from time is pointless as its ultimately what they are there for just by a different name

[@user-zs1rc5bn8w]

Sorry not buying. How would you tell the relative estimate of a 100 different stories with different requirements. Also seems like the solution to Alice/Bob/Charlie problem is just have Alice estimate all the issues.

[@NotOnlyCode]

You don't have to sort 100 different stories in order, you have to just categorize them into 5-6 boxes, and for each box you prepare a story that fits it perfectly. So let's say for 1-point box the reference story is "change a text on the site" or "change a color of a single element", for 2-point box it might be "add a button that will clear the form", and for 8 points it can be "add a new form with 10 different fields" etc. this way when you estimate a story "add a search form that will fetch results based on input" you can think which reference story is the most similar in size. Regarding Alice estimating all the issues - sure, you can do it, but Alice is the most experience developer, so she might estimate all the tasks to take 10 days, but then in reality they take 30 days, because not all tasks were done by Alice, but it was the whole team, where others are not as experienced.