Another cracking video Stephen. It made me laugh quite a bit because it really does look like you’ve experienced all of these scrumbut issues personally. Keep up the great content, 🎉
Very informative, thanks Steve. Vision Statement -> Product Goal(s) -> Sprint Goal(s); that is, everything is ultimately derived from the vision statement?
Yep exactly, the Product Owner has to have the vision of where they want to take the product or service and from that you need to derive the Product Goal(s), work on one Product Goal at a time which allows you to create meaningful Sprint Goals. And thank you, most appreciated 🙏👍
@@TheAgileLeanGardener Agree; that's exactly what I try to "implement" with my teams. Regarding product vs service, what would you class a "data migration" or a "cloud migration" project as though?
Hmm I wouldn’t class it as either really, it’s a migration but at a push it’s more service oriented. If you’re doing a migration I feel for you, they can be quite soul destroying to work on even though they are necessary at times 👍
Do we need to estimate Spikes..My understanding is No as it's an exploration work ..Also we never know how long it takes so how spikes can ne timeboxed to no of days?
No don’t bother estimating. Set the objective of the spike to something specific, nothing too big, and set aside a few days, 2 or 3 usually. At the end collectively understand what you’ve learned and decide if what you’ve learned has moved you forward. If not try to understand why and repeat.
What if a team does not have a sprint goal in one or two sprints (after so many sprints when the product is in maintenance or in matured phase)? Like there are many defects , Technical debts and each developer picked each item and no common sprint goal ? Still do they need to collaborate for defect and tech debt fixes ? And in this case what do we need to show in the Sprint review ? Kindly clarify
Scrum is designed around having a product goal and a sprint goal derived from this. If you don’t have this because there simply isn’t one I would argue that Scrum is not the right framework for you. Better off with Kanban. The Sprint Review is not intended for a ‘demo’. It is to show progress towards the product goal and to collect feedback against the completed sprint goal that may go into the backlog. I guess in your situation you could update stakeholders on the number of support tickets closed and fixes made. I’m unsure of why you wouldn’t be working on a sprint goal in each sprint though.
@@TheAgileLeanGardener Not always we work without sprint goal. sometimes there will not be features and team will pick up defects,tech debts..Have seen this in between sprints sometimes..
Hi Stephen, Wat if multiple PBI are in sprint backlog -In this case,does the Sprint Goal need to include only the highest priority one as Sprint Goal ? Multiple items is a mix of new feature,Bug fixing Stories/tasks, Tech Debts or refactoring etc
So your product backlog should be a collection of things that will achieve the ‘product goal’ which is normally created by the Product Owner. The Sprint Goal is a small subset of the Product Goal that the team believe is achievable in a Sprint. So, you pick those items from the Product Backlog that fit with the Sprint Goal. But the objective of the Sprint is to achieve the single Sprint Goal so it doesn’t matter if you complete all the items picked from the Product Backlog as long as you achieve the Sprint Goal. You may also find that as you’re working on the Sprint Goal there are other things that you need to do to achieve it that weren’t on the Product Backlog and that is also completely fine. If everything you needed to do was already on the Product Backlog that would virtually be waterfall.
Yep mini waterfall. Because if you create all the stories upfront that’s exactly what happens in waterfall, requirements definition phase. So many teams / organisations use Scrum but are actually doing mini waterfall, not just because they create all the stories upfront but because they don’t have releasable value at the end of each sprint. The idea of user stories comes from XP and the point was all about card, conversation and confirmation. So it’s basically a note to remind you have that conversation in sprint and work with stakeholders, customers etc to understand what they need and do this continually throughout the sprint, not at the end e.g. sprint review. Without this you lose creativity, innovation and adaptability.
Too right Steve and well said, teams not using a sprint goal are just deluding themselves 👍
Thanks John 🙏👍 and yes I agree 💯
John, I'm a little confused; I thought you were The Chelsea captain?!!!
@@rebe5272 haha no unfortunately not, I could do with his cash though 🤣
@@johnterry7397 hmmm who wouldn't?!!! it's just that you have BM logo 🤣... though JT was sometimes a bit of a scrum master himself (as in Rugby) 😁
Another cracking video Stephen. It made me laugh quite a bit because it really does look like you’ve experienced all of these scrumbut issues personally. Keep up the great content, 🎉
Haha thanks Shaun 🤣 yes I’ve experienced my fair share I’d say 🙏👍
Agree 💯
Very informative, thanks Steve. Vision Statement -> Product Goal(s) -> Sprint Goal(s); that is, everything is ultimately derived from the vision statement?
Yep exactly, the Product Owner has to have the vision of where they want to take the product or service and from that you need to derive the Product Goal(s), work on one Product Goal at a time which allows you to create meaningful Sprint Goals. And thank you, most appreciated 🙏👍
@@TheAgileLeanGardener Agree; that's exactly what I try to "implement" with my teams. Regarding product vs service, what would you class a "data migration" or a "cloud migration" project as though?
Hmm I wouldn’t class it as either really, it’s a migration but at a push it’s more service oriented. If you’re doing a migration I feel for you, they can be quite soul destroying to work on even though they are necessary at times 👍
Do we need to estimate Spikes..My understanding is No as it's an exploration work ..Also we never know how long it takes so how
spikes can ne timeboxed to no of days?
No don’t bother estimating. Set the objective of the spike to something specific, nothing too big, and set aside a few days, 2 or 3 usually. At the end collectively understand what you’ve learned and decide if what you’ve learned has moved you forward. If not try to understand why and repeat.
What if a team does not have a sprint goal in one or two sprints (after so many sprints when the product is in maintenance or in matured phase)? Like there are many defects , Technical debts and each developer picked each item and no common sprint goal ? Still do they need to collaborate for defect and tech debt fixes ? And in this case what do we need to show in the Sprint review ? Kindly clarify
Scrum is designed around having a product goal and a sprint goal derived from this. If you don’t have this because there simply isn’t one I would argue that Scrum is not the right framework for you. Better off with Kanban. The Sprint Review is not intended for a ‘demo’. It is to show progress towards the product goal and to collect feedback against the completed sprint goal that may go into the backlog. I guess in your situation you could update stakeholders on the number of support tickets closed and fixes made. I’m unsure of why you wouldn’t be working on a sprint goal in each sprint though.
@@TheAgileLeanGardener Not always we work without sprint goal. sometimes there will not be features and team will pick up defects,tech debts..Have seen this in between sprints sometimes..
Hi Stephen, Wat if multiple PBI are in sprint backlog -In this case,does the Sprint Goal need to include only the highest priority one as Sprint Goal ? Multiple items is a mix of new feature,Bug fixing Stories/tasks, Tech Debts or refactoring etc
So your product backlog should be a collection of things that will achieve the ‘product goal’ which is normally created by the Product Owner. The Sprint Goal is a small subset of the Product Goal that the team believe is achievable in a Sprint. So, you pick those items from the Product Backlog that fit with the Sprint Goal. But the objective of the Sprint is to achieve the single Sprint Goal so it doesn’t matter if you complete all the items picked from the Product Backlog as long as you achieve the Sprint Goal. You may also find that as you’re working on the Sprint Goal there are other things that you need to do to achieve it that weren’t on the Product Backlog and that is also completely fine. If everything you needed to do was already on the Product Backlog that would virtually be waterfall.
@@TheAgileLeanGardener Thankyou I did not understand last line.Yes all items will be in product backlog,how this is mini waterfall
Yep mini waterfall. Because if you create all the stories upfront that’s exactly what happens in waterfall, requirements definition phase. So many teams / organisations use Scrum but are actually doing mini waterfall, not just because they create all the stories upfront but because they don’t have releasable value at the end of each sprint. The idea of user stories comes from XP and the point was all about card, conversation and confirmation. So it’s basically a note to remind you have that conversation in sprint and work with stakeholders, customers etc to understand what they need and do this continually throughout the sprint, not at the end e.g. sprint review. Without this you lose creativity, innovation and adaptability.
@@TheAgileLeanGardener In waterfall the requirements are fixed.But in scrum the backlog keeps evolving/refined ..