Great video, thanks! Small mistake at 7:12 : The definition of done can actually be shared between multiple teams of the same product or even thoughout the whole organization, in some cases.
Many thanks for your videos. Always well detailed and easy to follow. Differnce between Acceptance Criteria and Definition of Done, well explained. Thumbs up!
Hi Vibhor, thanks for the awesome explanation! I have been enjoying n leaning a lot from your videos. I have one request, If you could slow down pace of your speech a bit..it would give more time to listeners to absorb and understand the whole thing more easily as there is so much to pick from each video.
Hi Vibhor...I disagree on one point..the mistake 4...the ref. Baseline for a story will not change It will change Vibhor. As the team gains experience, a 5 Storypointer could become a 3 Storypointer bcoz. There are now APIs which are reusable, and I have automated testing and my team also improved technically. Let me know ur thoughts
Hi Srividya, Your question and concern are obvious and very common. Let's break your concern into small pieces and see what we find. Your belief is that with experience a 5 point story becomes a 3 point story Let's see what made a 5 point story a 5 pointer in the first place. Story point represent Complexity+Risk+Effort Now in order to convert a 5 pointer to a 3 pointer these three characteristics of a user story must reduce in value. Let me ask you now, and think in terms of the entire team and not a particular individual. Does COMPLEXITY change with experience? Does RISK reduce with experience? Does EFFORT change with experience? If you look closely you'll find that none of these factors change with EXPERIENCE. Even the EFFORT remains the same. The experienced person applies the same EFFORT but is a little QUICKER than a novice. EFFORT is not the same as time. Hence the reasoning why the Reference stories shouldn't change. Having said that you can change reference stories story points when 1) There is a change in the team's composition. Either people joined the team or left the team 2) Actual RISK and COMPLEXITY associated have changed due to the change in the company's structure, culture, or infrastructure. This is very rare though. 3) The whole team wants to revisit the Reference stories after at least 2 quarters. Hope this helps
Hi Vibhor, your videos are really helpfull, thank you so much. I have a question though. Do you have a workflow of your own to work with the stakeholers, sme's and scrumteam such as lean inception?
Awesome explanation Vibhor. I have a question. Some teams calculating Dev estimate , Test estimate separately and summing those to get final story point instead of following relative estimate technique. E.g. if dev gives 3sp, tester gives 2Sp the overall estimate is given as 5sp where as actually this is a 3SP user story based on the reference story. Also, is calculating individual velocity a right approach or an anti pattern? - Kindly throw some light on these questions.
I have a question about the user story references technique. Why you need first compute the total value (Complexity+Risk+Effort) for each user story selected then sorting, then, assign a Fibonacci value to finally have the final user story size? What happend if assign the Fibonacci values from the beginning to my selected user stories, without the previous classification? Did you explain this in another video? Anyway thanks for this fantastic video about user story estimation
Excellent explanation, so helpful, thank you! A follow up question: how often is this process done? Is this a process repeated each time new stories are added to the product backlog? I’m a bit confused how this element fits into the Agile iterations/sprints. Thank you.
If you're talking about estimating user stories then it's first done before starting sprinting, then during every refinement meeting. Keep collecting keep estimating.
Should we estimate defects, improvement stories and tasks? Again " it all depends" is not what I'm looking for, but in general and in agile world is it a good practice to estimate?
In Agile there is no "in general". Before you estimate something you need to figure out why you want Estimates. Once you understand that you don't have to worry about if you should or shouldn't. For example, your business might need Estimates to decide budget, or they need it to meet a deadline. These are two separate reasons. If estimating defects can help you get them an answer to the question they are looking for then go for it, otherwise don't.
You are awesome as always. Thank you. Isn’t it ideal to mature to a state of small slices of user stories and go with no of user stories to be delivered in a sprint as estimate than going with story points? I know practically it isnt easy to achieve however going with user story count for forecasts sound simple. What do you think?
What if : "The product master hands over the results of sprint 1 to the customer, the customer accepts the results of this sprint. Then , while working on sprint 2 , customer wants to add some functionality related to sprint 1" , how do we handle Estimate User Stories ?
While taking the additional functionality mention how the team will handle that new functionality ie add it to the product backlog, refine it, estimate it. Ask the customer for their expectations, is it urgent, can it wait etc and prioritize accordingly. If it's a fire fighting issue, the PO can make the call to hold the current activities and all hands on the FF issue.
Hi Vibhor, Can we decide reference stories on the basis of stories completed in the previous sprints? Actually, we decide our reference stories every quarter. Thanks your videos are exceptionally well detailed. I will be looking forward hearing from you.
Hi Vibhor! Thanks for you video! Evaluation in SP or hours has its pros and cons, and in principle it is possible to justify the choice of any of them. You said that converting SP to hours is a mistake, ok)) But what do you say to such a question: let's say you chose an estimate in SP; the team evaluated "effort"for this task = 5 SP. we konow, that for billing purposes, all developers track the time in hours. After completing the task, we see 25 hours in this task. How to assess whether the team got into the estimation or not for this particular task? Bottle neck is that we have an estimate in SP, but the time tracking is in hours.
What is the logic behind using fibonacci series . why only fibonacci . i had used personally fibonacci in technical analysis of trading shares in share market .
Hey Vibhor. I really like your videos. I am new to the field of Scrum Master. Your Videos do help me. Please keep on bringing new videos on new concepts. Is this the place to ask you if I need help in my work or can we contact you via mail too.
![Oasis - Oasis Live '25 [Official Trailer]](http://i.ytimg.com/vi/gol_JnuEtKM/mqdefault.jpg)
Thank you so much for a newbee learning from Coursera. You have a disciple because you teach well
Thank you! I have been trying to explain this to my new team and you are very thorough. I will be sharing this with them.
I love the way you break things down, been watching a couple of your videos and it’s very comprehensive sir 👌 thank you 🙏🏽
Great job
Thank you Vibhor, great explanation! 🙏
Great. Thanks for showing a way to find references for different story points for other domains like systems engineering.
Love the way agile being explained
Great video, thanks!
Small mistake at 7:12 :
The definition of done can actually be shared between multiple teams of the same product or even thoughout the whole organization, in some cases.
Very well explained, doing great job
nice and informative video
It was very detail video with practical tips. Thanks.
Thanks Mugdha
Many thanks for your videos. Always well detailed and easy to follow. Differnce between Acceptance Criteria and Definition of Done, well explained. Thumbs up!
Great info Vibhor...thq!!
Excellent
awesome content , will keep watching
Great one! Thanks
very useful videos, thanks Vibhor
😍 Crushing… thank you
very well explained on story map
Thanks Sudhakar
Hi Vibhor, thanks for the awesome explanation! I have been enjoying n leaning a lot from your videos. I have one request, If you could slow down pace of your speech a bit..it would give more time to listeners to absorb and understand the whole thing more easily as there is so much to pick from each video.
Why don't you adjust the playback speed. Check video settings.
this comment's purpose is to support this channel and this magnificent video. Just kidding... or am I?)
Hey Vibhor, great videos. Could you please order your playlists? Thanks.
Feedback- You gained one more subscriber 😊
Thank you Kapil I really appreciate that
Great video!!
I love your videos man!
Feedback - new subscriber
Hi Vibhor...I disagree on one point..the mistake 4...the ref. Baseline for a story will not change
It will change Vibhor. As the team gains experience, a 5 Storypointer could become a 3 Storypointer bcoz. There are now APIs which are reusable, and I have automated testing and my team also improved technically.
Let me know ur thoughts
Hi Srividya,
Your question and concern are obvious and very common.
Let's break your concern into small pieces and see what we find.
Your belief is that with experience a 5 point story becomes a 3 point story
Let's see what made a 5 point story a 5 pointer in the first place.
Story point represent Complexity+Risk+Effort
Now in order to convert a 5 pointer to a 3 pointer these three characteristics of a user story must reduce in value.
Let me ask you now, and think in terms of the entire team and not a particular individual.
Does COMPLEXITY change with experience?
Does RISK reduce with experience?
Does EFFORT change with experience?
If you look closely you'll find that none of these factors change with EXPERIENCE. Even the EFFORT remains the same. The experienced person applies the same EFFORT but is a little QUICKER than a novice. EFFORT is not the same as time.
Hence the reasoning why the Reference stories shouldn't change.
Having said that you can change reference stories story points when
1) There is a change in the team's composition. Either people joined the team or left the team
2) Actual RISK and COMPLEXITY associated have changed due to the change in the company's structure, culture, or infrastructure. This is very rare though.
3) The whole team wants to revisit the Reference stories after at least 2 quarters.
Hope this helps
@@VibhorChandel yes .thank you very much for the detailed explanation Vibhor!!👍👍👍👍
Should we estimate bugs?
Hi Vibhor, your videos are really helpfull, thank you so much. I have a question though. Do you have a workflow of your own to work with the stakeholers, sme's and scrumteam such as lean inception?
Awesome explanation Vibhor. I have a question. Some teams calculating Dev estimate , Test estimate separately and summing those to get final story point instead of following relative estimate technique. E.g. if dev gives 3sp, tester gives 2Sp the overall estimate is given as 5sp where as actually this is a 3SP user story based on the reference story.
Also, is calculating individual velocity a right approach or an anti pattern? - Kindly throw some light on these questions.
Would you have any guidance to implement scrumban?
I have a question about the user story references technique.
Why you need first compute the total value (Complexity+Risk+Effort) for each user story selected then sorting, then, assign a Fibonacci value to finally have the final user story size?
What happend if assign the Fibonacci values from the beginning to my selected user stories, without the previous classification?
Did you explain this in another video?
Anyway thanks for this fantastic video about user story estimation
Excellent explanation, so helpful, thank you! A follow up question: how often is this process done? Is this a process repeated each time new stories are added to the product backlog? I’m a bit confused how this element fits into the Agile iterations/sprints. Thank you.
If you're talking about estimating user stories then it's first done before starting sprinting, then during every refinement meeting. Keep collecting keep estimating.
Should we estimate defects, improvement stories and tasks? Again " it all depends" is not what I'm looking for, but in general and in agile world is it a good practice to estimate?
In Agile there is no "in general". Before you estimate something you need to figure out why you want Estimates. Once you understand that you don't have to worry about if you should or shouldn't. For example, your business might need Estimates to decide budget, or they need it to meet a deadline. These are two separate reasons. If estimating defects can help you get them an answer to the question they are looking for then go for it, otherwise don't.
You are awesome as always. Thank you.
Isn’t it ideal to mature to a state of small slices of user stories and go with no of user stories to be delivered in a sprint as estimate than going with story points?
I know practically it isnt easy to achieve however going with user story count for forecasts sound simple. What do you think?
With no-estimate - how to get the release dates for the project? How to forecast ?
Good content, keep it up ! But how do you think the team will be aligned and pick 5 US from 100 (for example)? for that you should review all the US?
What if : "The product master hands over the results of sprint 1 to the customer, the customer accepts the results of this sprint. Then , while working on sprint 2 , customer wants to add some functionality related to sprint 1" , how do we handle Estimate User Stories ?
While taking the additional functionality mention how the team will handle that new functionality ie add it to the product backlog, refine it, estimate it. Ask the customer for their expectations, is it urgent, can it wait etc and prioritize accordingly. If it's a fire fighting issue, the PO can make the call to hold the current activities and all hands on the FF issue.
Hi Vibhor,
Can we decide reference stories on the basis of stories completed in the previous sprints? Actually, we decide our reference stories every quarter.
Thanks your videos are exceptionally well detailed.
I will be looking forward hearing from you.
What is the difference between efforts and estimate?
Hi Vibhor!
Thanks for you video!
Evaluation in SP or hours has its pros and cons, and in principle it is possible to justify the choice of any of them.
You said that converting SP to hours is a mistake, ok))
But what do you say to such a question: let's say you chose an estimate in SP; the team evaluated "effort"for this task = 5 SP.
we konow, that for billing purposes, all developers track the time in hours. After completing the task, we see 25 hours in this task.
How to assess whether the team got into the estimation or not for this particular task?
Bottle neck is that we have an estimate in SP, but the time tracking is in hours.
If there are no estimates, how do we know when the resources will be available to work on another project?
I didn't know that Jeff Goldblum was from India! ;-)
That's funny. BTW I am from Canada
How could the swimlane technique be done virtually?
Little different to make story map..is any other alternative way to setup storymap
I daily go through your videos please can you explain user stories in detail, with int var char charcters with sql
No idea what that is.
What is the logic behind using fibonacci series . why only fibonacci . i had used personally fibonacci in technical analysis of trading shares in share market .
Because it's the most frequently available sequence in nature.
Tanks handsome .
I didn't like it , 99% of the estimates is defined by managers , developers just follow
... or Am he?
your pronunciation of the word "Agile" is not good, please rectify it.
Hey Vibhor. I really like your videos. I am new to the field of Scrum Master. Your Videos do help me. Please keep on bringing new videos on new concepts. Is this the place to ask you if I need help in my work or can we contact you via mail too.
You can send your questions on LinkedIn
@@VibhorChandel Thanks