Thank you very much for your amazing and engaging videos; i am learning a lot. On the historical bit, isn't velocity a historical data suitable for planning, and do you mean teams that use capacity and understands what it means are wrong? And also, during the sprint planning, are we not supposed to consider work from the previous sprint if we are unable to finish up?
Thanks for watching emmanuel. I mentioned the problem with velocity here th-cam.com/video/WVEHWxEnilc/w-d-xo.html The Scrum team do not automatically do the Sprint Backlog that was not finish. Any Sprint Backlog that was not finished goes back to the Product Backlog. And I think in 8:47 I mentioned that Product Backlog is one aspect that the Scrum team need to consider during Sprint Planning.
@@scrummasterinblack thanks for your reply, can you do a video on how best to estimate in scrum and what estimates are or mean in hours. And what are are the best metrics to report to senior management as a scrum master. Also what are your best books recommendations for scrum masters. You can also talk about retros and how to do them. Welldone boss .
Hi Jashou, thank you very much for your idea and great video. I have a question for outsourcing scrum team, for the normal thing the backlog of outsourcing team just only the feature that you the customer want to deliver as their roadmap and the team just follow that plan. So it still FF for whole team, so how SM can help the team or discuss with customer that is FF because they think the value the team bring to them is delivery as much as features....
It is tough working with people who perceive the developers as feature factories. Maybe as the first step send the customer this video first th-cam.com/video/jJZaIE0Hw4Y/w-d-xo.html then ask them for their opinion: have we treat the outsourced developers as feature factories? Should we start measuring value and impact from the product?
Hi Joshua, Can you please clarify this? What I understand from this video is we shouldn't be using capacity (number of hours available for each developer) for Sprint Planning, then we also shouldn't be using Velocity(average number of story points completed by team in previous sprints), we should be using Team's historical performance. What is this Teams historical performance then? Can you please explain that in detail with real life examples? I am confused. Thanks a lot for reading my comment :)
@@scrummasterinblack Thanks for replying Joshua. We cannot use Kanbanize, so are you telling me to plan like a professional Scrum team I have to use Kanbanize tool, there's no other way to get this data?
Sadly, there are many practices of labeling Scrum Masters to new recruits and even fresh graduates. It's not meant to belittle fresh graduates, but most of them don't have the power to transform the organization and (sometimes) don't even have knowledge of Scrum or Agile. This causes a lot of Scrum practices deviation out there.
This has happened due to greed. Specially greed of the training bodies. They sold the idea if no one can get anything in IT industry, scrum master can be an option. Certification industry has killed this role a long time ago
I am still unclear about the sprint goal. You said its neither the scope nor the list of activities that define success. Is that mean even if team doesn't complete all the user stories that they have committed but can still able to achieve sprint goal?
Absolutely worth watching, all the way to the end. Rich and full of awesomeness. Thanks🌟
Thank you very much for your amazing and engaging videos; i am learning a lot. On the historical bit, isn't velocity a historical data suitable for planning, and do you mean teams that use capacity and understands what it means are wrong? And also, during the sprint planning, are we not supposed to consider work from the previous sprint if we are unable to finish up?
Thanks for watching emmanuel. I mentioned the problem with velocity here th-cam.com/video/WVEHWxEnilc/w-d-xo.html
The Scrum team do not automatically do the Sprint Backlog that was not finish. Any Sprint Backlog that was not finished goes back to the Product Backlog. And I think in 8:47 I mentioned that Product Backlog is one aspect that the Scrum team need to consider during Sprint Planning.
@@scrummasterinblack thanks for your reply, can you do a video on how best to estimate in scrum and what estimates are or mean in hours. And what are are the best metrics to report to senior management as a scrum master. Also what are your best books recommendations for scrum masters. You can also talk about retros and how to do them. Welldone boss .
Hi. I think I have already made a video about estimates in hours th-cam.com/video/WVEHWxEnilc/w-d-xo.html
"Mastering Professional Scrum" and "Zombie Scrum Survival Guide" would be my recommended book for Scrum Masters. Both are available at Amazon.
Awesome coach
Very nice! thanks for sharing your knowledge!
You are welcome. Thanks for watching 🙏
Thanks again Joshua, insightful 🥰🥰🤗
Hi Jashou, thank you very much for your idea and great video.
I have a question for outsourcing scrum team, for the normal thing the backlog of outsourcing team just only the feature that you the customer want to deliver as their roadmap and the team just follow that plan. So it still FF for whole team, so how SM can help the team or discuss with customer that is FF because they think the value the team bring to them is delivery as much as features....
It is tough working with people who perceive the developers as feature factories. Maybe as the first step send the customer this video first th-cam.com/video/jJZaIE0Hw4Y/w-d-xo.html then ask them for their opinion: have we treat the outsourced developers as feature factories? Should we start measuring value and impact from the product?
Very informative video! Thanks 🎩
Good luck 👍
Feature Factory - Team members blame each other for any failure.
True. Hahahaha.
Hi Joshua,
Can you please clarify this? What I understand from this video is we shouldn't be using capacity (number of hours available for each developer) for Sprint Planning, then we also shouldn't be using Velocity(average number of story points completed by team in previous sprints), we should be using Team's historical performance. What is this Teams historical performance then? Can you please explain that in detail with real life examples? I am confused. Thanks a lot for reading my comment :)
If you use Kanbanize the data is there.
@@scrummasterinblack Thanks for replying Joshua. We cannot use Kanbanize, so are you telling me to plan like a professional Scrum team I have to use Kanbanize tool, there's no other way to get this data?
@@rxmaysa I haven't explored other Kanban tools. I will make a video on how to use team historical performance from Kanbanize in the future.
Hi. I made a video to answer your question regarding team historical performance. HTH th-cam.com/video/WVEHWxEnilc/w-d-xo.html
Sadly, there are many practices of labeling Scrum Masters to new recruits and even fresh graduates. It's not meant to belittle fresh graduates, but most of them don't have the power to transform the organization and (sometimes) don't even have knowledge of Scrum or Agile. This causes a lot of Scrum practices deviation out there.
This has happened due to greed. Specially greed of the training bodies. They sold the idea if no one can get anything in IT industry, scrum master can be an option. Certification industry has killed this role a long time ago
I am still unclear about the sprint goal. You said its neither the scope nor the list of activities that define success. Is that mean even if team doesn't complete all the user stories that they have committed but can still able to achieve sprint goal?
Yes. You can still achieve the Sprint goal even if the scope is not all complete when your Sprint goal is an outcome.
Note that in Scrum Guide it is written that the team is committed to the Sprint goal not scope.
And the selected PBI is not only user stories 😊
So you moved from Perth? No wonder different video background *Salah fokus*
LoL. There is no video background of Brisbane in this video unlike the other past videos. XD