Reactions of the Scrum Master role for the Sprint Review event

The Sprint Review event is one of the main events in the Scrum framework. Unlike other project management methodologies, Scrum requires a regular review of the work achieved. Reference: https://bvop.org/learnagile/sprint-review/

In this article, we describe exemplary reactions to the Scrum Master role associated with this formal meeting.

Your team is very eager to go on vacation and asks you to postpone the retrospective of your sprint to the beginning or end of the other sprint.

The reaction of the Scrum Master. A retrospective is an event that takes place immediately after the Sprint Review. It doesn't take that long (a whole day or two) and is a mandatory part of the Sprint. It should not be delayed and done in the next sprint, because time will have passed and important things that would help the process of the next sprint or solve a problem can be missed, forgotten. I will remind the team of these important things about retrospection and I will appeal to their patients to go on leave after retrospection. Reference: https://bpedia.org/daily-scrum-meeting-problems-questions-and-answers/

The client informs you that he is initiating repairs in his office and asks you to send him a summary by e-mail from your meeting with the team and your opinions about the Sprint Review meeting. He trusts you completely for your analyzes.

 The reaction of the Scrum Master: I will thank the client for the trust, but I will emphasize the fact that he is the leading party in the project and the team (Scrum) does what he wants. That's why it's important to have a representative at the Sprint Review meeting. Reference: https://www.mmrls.org/scrum-study-real-situations-related-to-the-sprint-review-meeting/ My role and judgment are important insofar as I am part of Scrum, I follow its principles and way of working. However, the client has a role in the Sprint Review meeting and it is especially important for the team. It is very important for the client to be involved in order to accept the increment or, if necessary, change something. And only the guarantor can say that.

Your director has heard that your Sprint is over, but there is unfinished business.

He is angry and asks you to remove some large User Stories from the planned ones until the end of the sprint and replace them with smaller ones that you can find in the general list.

The reaction of the Scrum Master: I will talk to him and explain that only the Product Owner is the one who can change the story, change, and rearrange the priority of the product backlog. The team is the one that decides how much work it will take for the respective sprint and, if it decides, it (the team) can break a big story into several smaller ones. I will inform the Product Owner about the preference of the team. The Product Owner role can decide whether to put the unfinished things at the top of the to-do list, which means that they become the highest priority and should be taken on the next sprint. However, the Product Owner role may choose to move them further down the list if it deems that it is possible to work on something other than the Director for the next sprint.

The team informs you this morning that they are ready with all their work two days before the end of the sprint and asks you to arrange a meeting with the client to hold the Sprint Review meeting with him and to start the new sprint tomorrow.

The reaction of the Scrum Master: While you are at the Sprint Review meeting, they will attend an interesting company training, but promise to make up for it by asking the HR department to give you an extra day off this year. Reference: https://www.policymatters.net/scrum-sprint-review-meeting-questions-and-answers/

Scrum has a fixed time (sprint). No matter how much time it is (seven, two, three, four, a month at most), the development team decides. The decision is made at the very beginning when the project starts. I don't think it's right in one of the sprints if the tasks are done earlier than the expected end of the sprint, to shorten the sprint. On the other hand, it is not right for the team to be inactive for a whole day. Therefore, I would agree to the team to visit company training (because it is also useful and important to improve the quality of their work and knowledge), but with the following caveat - in sprint retrospect to specify to better specify the tasks for each sprint. Reference: https://ossalumni.org/scrum-problems-explanations-from-scrum-master/ To emphasize the more precise assessment of the volume of the undertaken tasks and thus in the next sprints to achieve a complete balance between tasks and time (sprint). That is, in the next sprints, the team will take more tasks to complete, which will exactly fill the sprint. I don't think the accidental faster completion of the sprint should be retaliated against.

The team informs you that they prefer not to work with a fixed time for sprints, but prefer each sprint to have a duration according to their work and judgment.

They have already discussed this proposal with the Product Owner role and he said he has no claims.

The reaction of the Scrum Master: I will remind both the team and the Product Owner that the same length of each sprint from the beginning to the end of the project is of particular importance and has its own logic and purpose. It is no coincidence that Scrum's technique has chosen this principle. And this is because:

The team easily compares the results of the sprints (speed of work, forecast of time needed for development);

The team gets used to their own performance and productivity and can make planning easier and easier over time;

Work habits and rhythm are built.

I will talk to the team about choosing the right amount of tasks to always fill the sprints, and in this regard, I will appeal to the team to decide how long the sprint should be (by the end of the project each sprint should be as long as the team decided, but this should apply to every single sprint).

I will also talk to the Product Owner - he should know the basic principles of working under Scrum and should not tolerate the free will of the team. Rather, I expect him in similar situations to recall the principles of working in a humble way.

Your assigned Product Owner on the project goes on a business trip to the client and sent you this morning Sprint Goal for the next sprint.

He has also made a collection with all the user stories that the team will work on.

The reaction of the Scrum Master: I will write the goal and the story on the Sprint product board. This way the team will know what is a priority for the next sprint. He will see the goal and choose what tasks to complete for the sprint. If I need any clarification or more information or the team decides to get something more, I will communicate by email or phone with the Product Owner. Reference: https://scrumtime.org/what-makes-a-good-product-owner-and-what-do-they-do/

The Product Owner of the project has sent you an email stating that he will collect detailed information on many details and plans to communicate with the client on an ongoing basis so that he can describe as many details as possible about the work for a long time to come.

The reaction of the Scrum Master: Rather, the case described in this way is aimed at the customer and the Product Owner's communication with him. At the end of each sprint, a retrospective meeting is made about the sprint itself. The whole team is present, absolutely all the roles. Thus, the Product Owner is always up to date with the processes, the work, the problems that are discussed in the scrum (he knows what and how to work during each sprint). The forthcoming tasks and details of the project for a long period of time should communicate them with the client, stakeholders.

You are returning from vacation. The team and the Product Owner of the project tell you that there is no time and the sprint should start without planning, as the team will work independently and will choose User Stories, ranked at the top of the Product Backlog collection.

The reaction of the Scrum Master: The sprint cannot start without planning. It is the first and very important part of the sprint. Planning determines not only the number of tasks but also the time required for each. The team must be aware of what each of them is doing, be informed about what is being worked on, what is the purpose of the sprint, and what is expected at the end of the sprint. In this way, we achieve clarity of exactly what and how much to take, so that at the end of each sprint we can give the customer a ready and working part of the product. So planning in Scrum is a must-have. Reference: https://phron.org/scrum-problems/

The Product Owner role has told your team that some functionality is expected in a few months.

Your team plans to do a technology study from now on to save yourself any problems and lack of competencies over time.

 The reaction of the Scrum Master: I will talk to the team and the Product Owner that this is a long period of time in which many things about the project can change - the client can think and this functionality can be dropped or replaced with another. It is important for the project and the team to concentrate their strength and energy now - to finish each sprint on time and with an absolutely fit increment. Avoid distracting the team and wasting time and effort on something that may not exist on the project agenda in a few months at all.

A member of your team who is planning to go on vacation soon has just started working on User Story, which is expected to be planned for the next sprint.

The reaction of the Scrum Master: I will talk to him and try to persuade him to give up. And to concentrate on tasks in the current sprint. Each sprint defines its tasks at the very beginning. Our expectations for something are the same, and the reality after that is completely different. There is no point in wasting time, energy, and work on something now that may happen in the future, but may fall away or undergo adjustments. Reference: https://www.nebraskasocialstudies.org/problems-of-the-scrum-master-role-with-the-sprint-review-and-scrum-sprint-retrospective-meetings/ Although he is planning a vacation, he must be reassured that during his absence the team will plan well and take on just as many tasks to complete. And in the future, the tasks we see on the backlog product now may have a changed priority, even if we die there.

A member of the team expresses dissatisfaction with the idea that everyone knows what the other is doing.

He is used to solitude. He prefers to work without explaining exactly what or his work to be seen in software systems. It guarantees that it will deliver very good results and just in time.

The reaction of the Scrum Master: I will talk to him and remind him of the principles of working in Scrum. Transparency in the implementation of tasks and everyone to know everything about the work of others is not a sign of any control but allows us to monitor the development of the project as a whole. If a problem arises, help everyone solve it. Looking at things from the side, you may come up with an idea for something more useful, faster, more acceptable. Knowing the tasks of others, working on them can be interchangeable. I will reassure him that no one doubts the quality and speed of his work, but the transparency of what everyone does, what he works on, and what he teaches is important because of the things listed above.

A colleague of yours, Scrum Master from your organization, meets you in the hallway and asks for advice on the length of his team's sprint.

None of the teams can offer a duration for their sprint. He asks you to recommend a time for their sprint.

The reaction of the Scrum Master: Every project is different. The tasks on it are different. The product to be produced at the end of the project is different. This determines the specifics of each project and respectively of each Scrum - what it will choose and for how long a part of the product will be completed. I don't think advice from anyone outside can help. It is the team that has to decide and choose the duration of the sprint. I would rather advise you to sit down and spend more time with the whole team analyzing the stories, concentrating on the tasks, and making your decision.

The Product Owner role of your team wants to change the duration of the sprint to 6 weeks.

You start integrating very complex systems and do not want to discredit yourself, your team, and the organization in front of the client with sprints where there is a risk that you may not be able to deliver a job that is actually done.

The reaction of the Scrum Master: I will convince him that the sprint is a specific amount of time decided by the project development team. And from the very beginning. The complexity of the upcoming tasks can be solved not by extending the duration of the sprint, but by breaking each of the more complex tasks into several subtasks. This will increase the number of sprints while meeting deadlines, and at the same time will increase the quality of the product. Reference: https://www.vbprojects.org/product-owner-role-in-scrum-and-real-problem-situations/ Longer sprints carry the risk of later noticing defects and errors that take away business value. And one more thing - disrupting the duration of the sprint disrupts the sense of the rhythm of the team. 

You receive an email from your client's Project Manager.

He asks you if there is a problem if your sprint is 6 working days. He expects a quick response so he knows what to pass on to his superiors.

The reaction of the Scrum Master: The client's project manager should communicate with the Product Owner. I will forward the email to him.

If under any circumstances, I combine the two roles, I will kindly answer that the sprint is as long as the development team decides. It is not the modest master who chooses this. It is also customary for the sprint to be measured in calendar weeks. This achieves better cyclicality and clarity. The length of the sprint in a project also depends on the complexity of the project. If the project has already started and I receive such an email from the Client's Project Manager, I will add the information that if a project has already started and the duration of the sprint is determined at the beginning, even the Scrum team is not desirable to make a change. If the project is just starting, I will write to him that I will notify him of the duration of the sprint as soon as the development team decides. Reference: https://wikipedia-lab.org/every-scrum-master-must-know-the-kaizen-principles/ 

Your director tells you that he has read a lot of information on the Internet about Scrum and asks you to set a time for your sprints to be one working week to reduce any risk.

The reaction of the Scrum Master: I will hold a meeting with the Director and I will explain what determines the length of the sprint. And who determines the length of the sprint. I will inform him about all the peculiarities of Scrum and emphasize the significant differences between popular management and Agile methodologies. Reference: https://www.libraryofmu.org/kanban-methodology-vs-scrum-framework/ In this case - the team of developers decides how long the sprint is, the complexity of the project also determines the length of the sprint. The Development team is a self-organizing team and as such, it is responsible for the quality of the product it releases, for the production of its business value, and for the customer's satisfaction with what Scrum does for it.