Fantastic explanation, you resolved all of my confusions, but still I have some queries, such as 1) Planning poker is a bit lengthy and time consuming process do we have another option which can allow us to make the bulk estimation. 2) In JIRA if we are capturing the efforts in a form of user story then how we can capture worklogs against those user stories. 3) In the work from home conditions which tool can be used for poker planning.
Best video on Story Point Estimation, I have ever seen among all existing ones, specially Capacity and velocity concepts are really clearing all the doubts.
If we talk practicality, story point vs hours will always be debatable. When we estimate tasks in hours, inherently we do relative sizing based on our experience so that is also not really absolute(except something entirely new). While things like story points on paper sound developer-friendly but practically all devs are now being pressurized for velocity improvements, Story point at a time during sprint does not give the real picture of progress, like maybe a developer is almost done with the work but the burndown chart will still show flat line. Also the context of the story point based on different elements, I don't see any reason we cant do that with hours. A person practically doing scrum for years can demonstrate a lot of cons of using story points as well. Research suggests relative sizing gives somewhat accurate estimates but not precise, An agile proponent needs to think about all these things before answering a question.
Hey Sandeep, You are right. they are many debates on it. Please see my response to Tony R. you will understand my reply. Story point estimation is very powerful if we understood it correctly.
Really a great video and explation given with realtime examples on story point estimations.Can you please make a video on capacity, Velocity as well. It will really helpful. Thanks
Thank you for the video. Lots of good info...I have a question but I start with the context of my thinking below first: It's really abstract and difficult for the dev team to think in terms of fantasy user story points when asked about efforts estimate. Even though we all know that efforts are to be measured in hours and tasks in story point, when it comes to the real-world we are committing to dates, not actually story points (although we pretend to say that in the agile framework). In reality, there's a specific date when sprint starts and another when it ends. Regardless of ALM tools, we need to track burndown by hours and days (time dependent, not size dependent). Having no correlation or industry standard to convert the user story points to hours creates more confusion...making the user story point estimates and extra, unnecessary step. If we apply efforts in hours for each task for each user story with similar flexibility as a sliding scale (or fibonacci buckets), then don't you think user story estimation is redundant and unecessary? I'm curious as to what most successful companies are doing...are they tracking hours AND story points, or one or the other? And has anyone come up with a statndard conversion between the two scales? Thank you!
Hi Tony, I totally appreciate and I get this question in almost all discussions. Here is my reply, 1. The story point estimation is required when you don't want person dependency, any person in the team can do this story, it's independent. 2. You can measure tasks in hours and it depends on the skill level of the person. for example, person A can do a task in 5 hours whereas another person B can do the same task in 8 hours. Each human is different. Does that mean the story point will change? No. that's where we struggle to understand the logic of story point estimation. In this case, the story point may remain the same because of the 4 factors I mentioned in the video. How? Person A is having more knowledge than person B, and when you do story point estimation it will come to the discussion while playing story point poker and both of them will agree on the intrinsic logic of development. When they decide on story points, they will mutually agree that it will take such efforts. Generally, what happens is we assign a story to a person and then start comparing it with hours. I hope I am able to explain it.
@@greatsim Thank you very much for the explanation! Is there a guideline to how to assign a story point? I mean, if my team says, in T-shirt sizing, the task is small...should we assign 1 story point or something else? I think if we understand the story point scale better, at least the starting story point, then we can apply fibonacci series on that going into next sizes. I hope you get my question. Best regards.
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 for the tasks or 12 hours i.e 3 hours × 4 tasks
![Twenty One Pilots - “The Line” (from Arcane Season 2) [Official Music Video]](http://i.ytimg.com/vi/E2Rj2gQAyPA/mqdefault.jpg)
You the best … cleared my head on few confusions hanging around… it’s one of the best video available for agile enthusiasts
The Best Explanation, Simple language, concept growing step by step
One of the best if not the best video on relative estimation and story point sizing
Fantastic explanation, you resolved all of my confusions, but still I have some queries, such as
1) Planning poker is a bit lengthy and time consuming process do we have another option which can allow us to make the bulk estimation.
2) In JIRA if we are capturing the efforts in a form of user story then how we can capture worklogs against those user stories.
3) In the work from home conditions which tool can be used for poker planning.
Best video on Story Point Estimation, I have ever seen among all existing ones, specially Capacity and velocity concepts are really clearing all the doubts.
Excellent Session with all details. Mustwatch for all Agilists
Thanks
Very good understanding and well explained...tqqqqq
So nice of you
I highly recommend to those who are still confused about the concepts
That was a crystal clear explanation really great and helpful, wish to see more videos. Thanks for the knowledge sharing
Very informative and crisp to the point session. Thanks a lot.
Simply superb, please post more videos with case studies
When will you share the capacity, velocity and load video?
If we talk practicality, story point vs hours will always be debatable. When we estimate tasks in hours, inherently we do relative sizing based on our experience so that is also not really absolute(except something entirely new). While things like story points on paper sound developer-friendly but practically all devs are now being pressurized for velocity improvements, Story point at a time during sprint does not give the real picture of progress, like maybe a developer is almost done with the work but the burndown chart will still show flat line. Also the context of the story point based on different elements, I don't see any reason we cant do that with hours. A person practically doing scrum for years can demonstrate a lot of cons of using story points as well. Research suggests relative sizing gives somewhat accurate estimates but not precise, An agile proponent needs to think about all these things before answering a question.
Hey Sandeep, You are right. they are many debates on it. Please see my response to Tony R. you will understand my reply. Story point estimation is very powerful if we understood it correctly.
Excellent video.
Excellent my dear
this is very good explanation, please post some more videos.
Really a great video and explation given with realtime examples on story point estimations.Can you please make a video on capacity, Velocity as well. It will really helpful. Thanks
Thank you for the video. Lots of good info...I have a question but I start with the context of my thinking below first: It's really abstract and difficult for the dev team to think in terms of fantasy user story points when asked about efforts estimate. Even though we all know that efforts are to be measured in hours and tasks in story point, when it comes to the real-world we are committing to dates, not actually story points (although we pretend to say that in the agile framework). In reality, there's a specific date when sprint starts and another when it ends. Regardless of ALM tools, we need to track burndown by hours and days (time dependent, not size dependent). Having no correlation or industry standard to convert the user story points to hours creates more confusion...making the user story point estimates and extra, unnecessary step. If we apply efforts in hours for each task for each user story with similar flexibility as a sliding scale (or fibonacci buckets), then don't you think user story estimation is redundant and unecessary? I'm curious as to what most successful companies are doing...are they tracking hours AND story points, or one or the other? And has anyone come up with a statndard conversion between the two scales?
Thank you!
Hi Tony, I totally appreciate and I get this question in almost all discussions. Here is my reply, 1. The story point estimation is required when you don't want person dependency, any person in the team can do this story, it's independent. 2. You can measure tasks in hours and it depends on the skill level of the person. for example, person A can do a task in 5 hours whereas another person B can do the same task in 8 hours. Each human is different. Does that mean the story point will change? No. that's where we struggle to understand the logic of story point estimation. In this case, the story point may remain the same because of the 4 factors I mentioned in the video. How? Person A is having more knowledge than person B, and when you do story point estimation it will come to the discussion while playing story point poker and both of them will agree on the intrinsic logic of development. When they decide on story points, they will mutually agree that it will take such efforts. Generally, what happens is we assign a story to a person and then start comparing it with hours. I hope I am able to explain it.
@@greatsim Thank you very much for the explanation! Is there a guideline to how to assign a story point? I mean, if my team says, in T-shirt sizing, the task is small...should we assign 1 story point or something else? I think if we understand the story point scale better, at least the starting story point, then we can apply fibonacci series on that going into next sizes. I hope you get my question. Best regards.
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 for the tasks or 12 hours i.e 3 hours × 4 tasks
wonderful explanation
Great content brother, thanks for sharing
Your content is great. You should post more 🙂
Hi, what are other story point estimating techniques apart from planning poker. Pls name them?
thank you for this
You're very welcome!
the best video for story point.
Do you email I can contact you for training
Please release PI planning session 🙏
I badly need pi planning session to implement safe in my new job.. pls help