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
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
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
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?
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
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.
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.
What's your experience with estimations, do you have some best practices that worked well in your team?
Man! I am not sure what is your exact profile but you have super clear way of explaining things!!!
Thank you! I'm happy it's easy to follow
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
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
@@NotOnlyCode Ah, got it - thanks for the insights, very helpful!
Yet another fantastic video! Thanks!
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
Story points should never be used to measure individual performance, it leads to gaming the system and unhealthy internal competition
Very nice explaination, Thanks so much!!
story points blow, can you imagine story point poker
Very nice and clear explanation on estimations.
Glad it was helpful!
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?
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
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.
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.
trying to abstract points from time is pointless as its ultimately what they are there for just by a different name
Great video!
Thanks!
Gud one