PO adding extra requirements in an already-overloaded sprint
Hi All,
I am new to this website and new to the Master position. I have no formal training or remotely similar background in scrum or management. I was looking for a place I can reach out to professionals and seasoned SMs for advise.
I was oddly placed into this position, which is kind of part "SM" and part requests coordinator for the company. I've been trying to self learn for the past year...some video training and some initial guidance from my PO.
So my question is: what do I do if a prominent member of the team is complaining (and rightly so) about the PO adding extra requirements mid sprint when we already are overloaded with a quickly approaching deadline? I did bring up this to the PO, but he basically said that the work is simple and doable and the reason it appears the team can't handle is because I am not properly managing the team, the proceeding to tell me I need to be assigning work since one of the developers is no working to his potential. I don't think agile supports the idea of assigning work, so I said I will more closely monitor. I took it as a learning moment, given I am a year into this without proper training, background or certification. But he is continuing to add extra work, and, from my perspective and the team's, we truly have too much to do in a short time. I'm afraid we will not meet the sprint goals.
Please offer me some advise.
Thank you!
Melissa
Better defining your role may be a good first step. I'm not sure what a "requests coordinator" is, but the definition of the Scrum Master role can be found in the Scrum Guide. How closely does your role align with the definition of a Scrum Master? Is anything in the role definition missing from your current role? Does your current role include anything beyond the definition of a Scrum Master? I'd be hesitant to taking too much advice from someone in a Product Owner role about how to best function as a Scrum Master since there's some natural tension between the different roles in Scrum.
If the Product Owner is changing the definition of work, that strikes me as rather problematic. The Product Owner often begins the process of capturing the needs of stakeholders in whatever format the team uses for Product Backlog Items. These Product Backlog Items go through refinement, perhaps in multiple stages, before they are considered for Sprint Planning. This refinement is an opportunity for the Product Owner and Developers to understand and split the work in small chunks, with the goal of making each chunk capable of independently delivering value. At Sprint Planning, the whole team collaborates on a Sprint Goal and can align Product Backlog Items and the Sprint Backlog with that goal. Although the Sprint Backlog can and frequently does change at the discretion of the Developers, changing the definition of any Product Backlog Items can have a negative impact on the team's ability to plan and execute on that plan to move toward the Sprint Goal.
If the Product Owner is consistently feeling the desire to change the work, I'd want to understand why these things are not known going into refinement to make sure that the team is accurately able to look at the work and make the determination about their ability to complete it within the Sprint timebox. This ability to make short-term plans and continually inspect and adapt the plans is one of the cornerstones of iterative and incremental methods like Scrum.
The thinking that the Scrum Master is managing the team is also a mistake. There are examples of pull systems throughout Scrum. The Scrum Team collaborates and negotiates on a Sprint Goal and selecting Sprint Backlog Items. The Developers collaborate on creating the Sprint Backlog. The Developers use the Daily Scrum to plan and adjust their plans to make progress to the Sprint Goal. There's nothing that explicitly prohibits someone from pushing work, it's well known that pull systems are more effective than push systems and work quotas. Scrum is designed to support collaboration, and pull systems tend to foster collaboration and teamwork more than a push system.
I'm not sure what the root cause of the problems are. It could be that the Product Owner is unable to get enough information out from key stakeholders on time. It could also be key stakeholders are putting pressure on the development organization to commit to delivering certain functionality. It could be a lack of skill or savvy on the part of the Product Owner to work through the requirements in advance of the Sprint Planning, leading to important holes. Perhaps the Developers don't have enough information about the situation and context to ask good questions, leading to the discovered necessary work during the Sprint.
One of my first objectives would be to figure out why these requirements must be added in the middle of the Sprint and why these changes cannot be expressed as Product Backlog Items and appropriately ordered, refined, and selected through the normal development process. Another early objective would be to figure out why the team is under so much pressure and make sure that the team is not overturned. Reducing the pressure would improve quality and, over time, improve the team's performance in the long run.
he basically said that the work is simple
If the work was simple you wouldn't need Scrum; the framework is intended to address complex problems.
Sometimes agility is misunderstood as a means of getting people to saw through a pile of work faster and cheaper, when it is really about learning to build the right thing at the right time. My advice is to look to the Scrum Guide as your friend and to pay close attention to the values of Commitment, Focus, Respect, Openness, and Courage.
There isn't much more to be said, except that I recommend you going through this sites free Scrum Master Learning Path, as I am sure that it will help you fill in your missing knowledge gaps.