Thanks a lot for all the sessions. I have benefitted much through your sessions

Thank you, this helps with the nuances in how SP relates to hours.

Thanks .beautifully explained🎉

Hi Sir, Thanks for explaining abt Estimation in detail. Clear and easy-to-understand explanation. Thanks again.

Thanks, one of the best explanations !

Excellent presentation and clarification on the subject, thank you.

Thank a lot Sir for clear explanation awesome 👏👏

Thanks, it was helpful

Hello Sir, In my new scrum team they are not using task estimation/hours at all. They are doing only SP estimation at story level. My question in such a scenario how can we now if the team is under committed or over committed based on SP alone as the capacity planning happens at hours. How do i coach the team on benefits of tasks estimation? Do you have any videos on this topic. Could you please share your thoughts, thank you

Excellent

Thankyou for ur video

👌

Clear explanation, May I know how to calculate story points

Thank you very much for the video. I have a question, please. If the estimation during sprint planning can be done in actual hours because technical design discussion is taking place, then why do we need to do story point estimation so early on, as you say, 2 or 3 sprints in advance, for the entire backlog. One may say that because it helps to identify big stories that need to be broken down. But my doubt is then if the team is already aware about that without story point estimation to help them, then what is the purpose of doing early story pointing? Thank you in advance.

Hello Saket, thank you for your informative video. I have always known that we using story pointing estimation during Sprint Planning but I am getting the sense from your video that story pointing should normally be done during Sprint Refinement? If this is the case then how should a team estimate stories during the Sprint planning sessions? OR is there no verification of the previously estimated stories during the planning session? 2. My Second question to you is DOD and Acceptance Criteria Synonymous? I am seeing that Acceptance criteria may be more relevant at the Epic & Feature level & Definition of done more effective at the Story level. Your thoughts please?

Excellent presentation, although the final step in which you tried to explain the relative value of 1 or 2 story points was a bit too fast and thus not as clear, at least for a new non IT person to the space. Thanks, though, for the breakdown. Generally speaking, I understand the thinking better.

Hi Saket, I have a question- What if the reference story itself is estimated incorrectly, that sets wrong benchmark for the team which could lead to overall estimation error at the sprint level. How do we rule of this possibility of error n ensure that ref story is well understood n estimated correctly

how do you allocate points to user stories, how to determine points given to user stories and who does the allocation of point to user stories

I am a bit confused about the technical sequence, don't we do the User story estimation during sprint planning and at that stage we are aware of the sequence of work? Is estimation done during Backlog refinement/grooming or just broad T-Shirt sizing?

What if there is no past data or reference to do relative estimate to correlate SP to efforts?

Sir, Suppose I estimate my PBI during PBR thrice before SprintPlanning and if the first round of estimation is called ROE [Rough order of estimate], what do we call the next rounds of story point estimations?

In my last interview interviewer asked me... And i guess due to this only he did not select me...

10 years of experience guy working in the company for 20 years 🤣🤣🤣 Joke apart, very informative video

Only 1 member will work on 1 user story, right?

Hi Saket, in story estimation, we estimate based on complexity, external dependencies, and risk. And we want to separate complexity from work effort. But what does complexity really mean here? Can you give some examples? Thank you very much.

long story short, story point is a kind of time unit for a particular team in a particular project settings.