Just discovered your videos. You're the best man. Clear, strait to the point, well presented, clearly backed by a long experience. Happily learning from you. This is my #1 go to channel for everything SCRUM/JIRA. I hope you'll continue.
Thank you. We don't use story points because of the time estimating. Then turn around and use sprints but question why we can't plan accordingly. I'm now a product owner and am going to be readdressing this topic again using your t-shirt size example.
Hi Alex, Lets say we have a 21 point story, would you break the story and assign to different people or the same person? secondly would you combine development and testing hours in the overall story point even if it needs to be performed by two different individuals?
Apologies if I missed this on the video, but in the case where you have the process Develop -> Review -> QA, should the story point estimate represent completing all these stages, or just the Develop stage?
Do you have any somewhat real world examples of breaking down the 8/13/21 SP tasks into smaller tasks? It would be great to see some good and bad examples. Also, when you coach teams, do you even allow 8 SP or higher tasks to make it into the sprint? or do you tackle this in the Product Backlog refinement and break down the tasks with the team there into 5 SP or less tasks?
Hi sir，I am newbie scrum master and really struggling on how to coach my team to provide storypoint，your videos are always very helpful to me，can you help me with this question：usually who will be the one estimate storypoint for a story？ how about to have developer to create subtasks and provide storypoint accordingly after grooming session？so I can see sum story point on parent story，please advice， thanks a lot
The developer should ALWAYS estimate the Story. The Developer can create subtasks, estimate those, and then roll them up to the Story. Problem is that you don't see the subtasks in the backlog . . so, it makes it a little harder to use.
If you are going to use man days, I recommend you change your settings to use Original Estimate instead of story points. This will help you track hours/days easier.
To get more resources and get in contact with me check out this link linktr.ee/apetech
You indeed knew your kraft. Full respect to you. Unique👏
Yes yes yes! Everything Ahmed said. Please keep them coming😁
Thanks for the positive feedback!!!! I'll keep them coming.
it is great! it helped me as a Scrum master a lot. thank you for this video!
Just discovered your videos. You're the best man. Clear, strait to the point, well presented, clearly backed by a long experience. Happily learning from you. This is my #1 go to channel for everything SCRUM/JIRA. I hope you'll continue.
Thanks!! Means so much that it's helping you out!!
Wow, It's fantastic bro I am so confused about this story's points now my confusion is gone thanks Man you are such an excellent teacher.🤗🤗🤗
Thank you so much!! Comments like this give me the energy and motivation to keep on going!
Thank you. We don't use story points because of the time estimating. Then turn around and use sprints but question why we can't plan accordingly. I'm now a product owner and am going to be readdressing this topic again using your t-shirt size example.
Glad I was able to inspire!
That back wall is inspiring.
Thank you,really helps grasp story point estimates
Great job 👍 THANK YOU!
Thank you for watching! Hope it was beneficial to you!
Hi Alex, Lets say we have a 21 point story, would you break the story and assign to different people or the same person? secondly would you combine development and testing hours in the overall story point even if it needs to be performed by two different individuals?
Apologies if I missed this on the video, but in the case where you have the process Develop -> Review -> QA, should the story point estimate represent completing all these stages, or just the Develop stage?
My philosophy is that the story points should reflect the work of the person providing the estimate. That to me means only the development work.
Is the approximate story points specified for a two week sprint? or is it irrespective of the duration of the sprint?
Murphy's law 😉
Totally agree... upwards of 10 points means break it down.
Do you have any somewhat real world examples of breaking down the 8/13/21 SP tasks into smaller tasks? It would be great to see some good and bad examples. Also, when you coach teams, do you even allow 8 SP or higher tasks to make it into the sprint? or do you tackle this in the Product Backlog refinement and break down the tasks with the team there into 5 SP or less tasks?
Excellent feedback! I'll make a video on this!
Hi sir，I am newbie scrum master and really struggling on how to coach my team to provide storypoint，your videos are always very helpful to me，can you help me with this question：usually who will be the one estimate storypoint for a story？ how about to have developer to create subtasks and provide storypoint accordingly after grooming session？so I can see sum story point on parent story，please advice， thanks a lot
The developer should ALWAYS estimate the Story. The Developer can create subtasks, estimate those, and then roll them up to the Story. Problem is that you don't see the subtasks in the backlog . . so, it makes it a little harder to use.
Hey, video looks cool and simple. One quick query: duration is in man days and not scrum team days. Plz clarify
If you are going to use man days, I recommend you change your settings to use Original Estimate instead of story points. This will help you track hours/days easier.
Ideal Gas Law. I think that's the law you're referring to. :)
I'm not sure. . .I looked it up on Wikipedia and it looks very complex. . . I'm not that smart hehe.
bro this has got to be the worst business name / youtube channel name ever.. you should look into changing it.