Thanks for the quality content! I'm having difficulty making decisions in a new project, could you help me? Some developers have completed all tasks during the sprint and they are asking to add new ones from the product backlog. Should they be allowed to do this? For example, the frontend developers have completed their part, leaving only work for the backend. Frontend developers want to take on a few items from the top of the backlog to start preparing for the next sprint. Intuitively, I think that taking additional work from the product backlog is not the best decision)
As a former software developer and now in a Scrum Master role, I've encountered this situation myself! Consulting with the team's Definition of Done would alleviate some of the pain points you're witnessing. This approach helps the team understand how they can collaborate as a unit. Previously, the team I was on ended up working in "mini-waterfalls" because it would go Developer -> QA Tester -> PO Review, causing numerous silos within the scrum team.
I'm happy to help, Andrey. I completely agree with you that you do not want them pulling new items into a sprint. This type of thinking comes from thinking about efficiency. So it's well intentioned. They would be more efficient if they could get a jump on the next work. But if the backend devs are always a little behind then the work will just pile up more and more each sprint. The thing to focus on is instead of efficiency. Look at the number of items being completed each sprint. If the frontend devs could help on the backend work, the overall team would get more done. That is true even if the frontend devs are a fraction as productive at backend work as the backend devs. (And they'd slowly get better.) I know, I know: the frontend devs will say they can't do backend. Or the backend devs won't want their help. But in many cases there are ways to design or code a part of a system that make it easier for the other side. The frontend devs could do that--this would slow them down a tiny bit (be "less efficient"!) but that doesn't matter because they have excess capacity (free time at the end) anyway. And it would make things a tiny bit faster for the backend. Eli Goldratt (of "Theory of Constraints") has a great example in his book . He writes about "the fat Boy Scout." (Not a very politically correct analogy these days...) He imagines a group of Boy Scouts hiking on a trail. The "fat one" gets behind and then more behind and then more behind. (See the connection to the backend here?) The faster hikers eventually decide to stop while the slow hiker catches up. They then all start and it happens all over again. His solution is to visualize tying a rope around the waist of each hiker with say 2 meters between each on the rope. No hiker can then get more than 2 meters ahead of any other hiker. What then can the hikers do to go faster? Lighten the load of the slowest hiker. Take things out of his pack. They slow down a little from the extra weight, the slow hiker speeds up. Good luck!
Hello Mountain Goat. A contact of my showed me your UA-cam video and i compliment you for the way you explain. I have a question that not covers your video. However it is a very interesting one. The context. The Developers and Scrum Masters are located in a line Department. The 0:06 Devs are doing development and maintenance (DevOps) The Product Owner is located in a staff Department. These three Scrum roles are working together and meet each other regularly. However, there are plans to move the Product Owner to the line department together with the Developers and the Scrum Master. Questions: 1:Can you please give a breakdown why a Product Owner should or should not stay in a staff department with the advantages and disadvantages? 2: Can you advise me a good book where the position of the Product Owner in the organisation should be positioned? Line or Staff? A book that contains incontrovertible evidence with strong arguments where a Product Owner should be positioned? Based on what i have read about the Product Owner, i expect that role in a staff department. I am very curious at your perspective and if this question is interesting enough for you to do a video about it. Because I will definitely show it to my colleagues. . Regards, Lucien
Thanks for the questions, Lucien. Since they aren't related to this video I won't answer here, but I'll try to make a new video on some of these topics. (I can say I'm not aware of a book with "incontrovertible evidence" about where the PO should be positioned. I"m not I've seen a book with "incontrovertible evidence" about anything related to software process management, agile or not.)
@@MountainGoatSoftware Thank you very much for your answer. I will wait for the video. Is good to read that you have not seen any book about the position of the PO. So i know for sure that i have done enough research.
What if all devs completed and have capacity and why picking smaller PBI's is not a good idea .This had happened on last two days of the sprint sometimes.. Anyways sprint goal is met and sprint backlog can be changed!?
A team has authority to change its own sprint backlog. Team members should consider running things by their product owner. But I wouldn't want to spend an hour tracking my PO down and then 30 minutes seeking permission for the 2 hour thing I want to work on. Team members should use their judgment.
Thanks for the quality content!
I'm having difficulty making decisions in a new project, could you help me?
Some developers have completed all tasks during the sprint and they are asking to add new ones from the product backlog. Should they be allowed to do this?
For example, the frontend developers have completed their part, leaving only work for the backend. Frontend developers want to take on a few items from the top of the backlog to start preparing for the next sprint.
Intuitively, I think that taking additional work from the product backlog is not the best decision)
As a former software developer and now in a Scrum Master role, I've encountered this situation myself!
Consulting with the team's Definition of Done would alleviate some of the pain points you're witnessing. This approach helps the team understand how they can collaborate as a unit. Previously, the team I was on ended up working in "mini-waterfalls" because it would go Developer -> QA Tester -> PO Review, causing numerous silos within the scrum team.
I'm happy to help, Andrey. I completely agree with you that you do not want them pulling new items into a sprint.
This type of thinking comes from thinking about efficiency. So it's well intentioned. They would be more efficient if they could get a jump on the next work. But if the backend devs are always a little behind then the work will just pile up more and more each sprint.
The thing to focus on is instead of efficiency. Look at the number of items being completed each sprint. If the frontend devs could help on the backend work, the overall team would get more done. That is true even if the frontend devs are a fraction as productive at backend work as the backend devs. (And they'd slowly get better.)
I know, I know: the frontend devs will say they can't do backend. Or the backend devs won't want their help. But in many cases there are ways to design or code a part of a system that make it easier for the other side. The frontend devs could do that--this would slow them down a tiny bit (be "less efficient"!) but that doesn't matter because they have excess capacity (free time at the end) anyway. And it would make things a tiny bit faster for the backend.
Eli Goldratt (of "Theory of Constraints") has a great example in his book . He writes about "the fat Boy Scout." (Not a very politically correct analogy these days...) He imagines a group of Boy Scouts hiking on a trail. The "fat one" gets behind and then more behind and then more behind. (See the connection to the backend here?)
The faster hikers eventually decide to stop while the slow hiker catches up. They then all start and it happens all over again.
His solution is to visualize tying a rope around the waist of each hiker with say 2 meters between each on the rope. No hiker can then get more than 2 meters ahead of any other hiker.
What then can the hikers do to go faster? Lighten the load of the slowest hiker. Take things out of his pack. They slow down a little from the extra weight, the slow hiker speeds up.
Good luck!
Hello Mountain Goat.
A contact of my showed me your UA-cam video and i compliment you for the way you explain.
I have a question that not covers your video. However it is a very interesting one.
The context.
The Developers and Scrum Masters are located in a line Department. The 0:06 Devs are doing development and maintenance (DevOps)
The Product Owner is located in a staff Department. These three Scrum roles are working together and meet each other regularly.
However, there are plans to move the Product Owner to the line department together with the Developers and the Scrum Master.
Questions:
1:Can you please give a breakdown why a Product Owner should or should not stay in a staff department with the advantages and disadvantages?
2: Can you advise me a good book where the position of the Product Owner in the organisation should be positioned? Line or Staff?
A book that contains incontrovertible evidence with strong arguments where a Product Owner should be positioned?
Based on what i have read about the Product Owner, i expect that role in a staff department.
I am very curious at your perspective and if this question is interesting enough for you to do a video about it.
Because I will definitely show it to my colleagues.
.
Regards,
Lucien
Thanks for the questions, Lucien. Since they aren't related to this video I won't answer here, but I'll try to make a new video on some of these topics. (I can say I'm not aware of a book with "incontrovertible evidence" about where the PO should be positioned. I"m not I've seen a book with "incontrovertible evidence" about anything related to software process management, agile or not.)
@@MountainGoatSoftware
Thank you very much for your answer. I will wait for the video. Is good to read that you have not seen any book about the position of the PO.
So i know for sure that i have done enough research.
What if all devs completed and have capacity and why picking smaller PBI's is not a good idea .This had happened on last two days of the sprint sometimes.. Anyways sprint goal is met and sprint backlog can be changed!?
A team has authority to change its own sprint backlog. Team members should consider running things by their product owner. But I wouldn't want to spend an hour tracking my PO down and then 30 minutes seeking permission for the 2 hour thing I want to work on. Team members should use their judgment.