Sprint is called an event in the Scrum framework that has a fixed duration and the Development team, Scrum Master, and Product Owner roles work together to achieve the Sprint Goal.
In the article, we discuss real possible scenarios and events that the Scrum Master role may encounter during the work of the team. The scenarios and reactions are provided in terms of the responsibilities of the Scrum Master role. All possible scenarios are based on the good practices provided by BVOP in their BVOP Agile Guide, section What is a Scrum Sprint? BVOP.org, 2019
The Development Team is very eager to go on vacation and ask you to postpone the retrospective of your sprint to the beginning or end of the other sprint.
In general, the retrospective is done after each sprint, in order to discuss what difficulties they experienced during the sprint, as well as to discuss suggestions for improvement in the next sprint. This meeting must be done before the start of the new Scrum Sprint, that is, I would not agree with the idea of retrospectively after the end of the next sprint. If the whole team has already planned the rest product backlog items, I would eventually agree to postpone the retrospective 1 day after the start of the new Sprint, but in my opinion, this would lose the focus of the team. See more about the Sprint in Scrum on Scrum.org
The client informs you that he is initiating repairs in his office and asks you to send him a summary by email from your meeting with the team and your opinions about the Sprint Review meeting. He trusts you completely for your analyzes.
The sprint review event was very successful. Since you could not attend it, I would like to send you photos and videos with the ready-made functionalities. These videos will contain material from the functionality we were able to create during the sprint. Please review them, and give us feedback if anything needs to be improved in the next sprint. But the team was very pleased with the work done during the last sprint.
Your director has heard that your Sprint is over, but there is unfinished business. He is angry and asks you to remove a few large User Stories from the planned ones by the end of the sprint and replace them with smaller ones that you can find in the general list.
I would discuss this with the Product owner so that he can possibly authorize the tasks in the user story-to until the end of the sprint. This will result in the team having several fully completed deals. The rest of the stories, at the discretion of the Product owner, will have to be added to the user story-to for the next sprint. In his opinion, the unfinished tasks will be completed with priority in 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. While you are at the Sprint Review meeting, they will attend an interesting company training, but promise to take revenge by asking the HR department to give you an extra day off this year.
I don’t think that’s a good idea at all. Only the Product owner role can terminate the current sprint. And this can only happen in very rare cases. One of the reasons would be a major change on the part of the client to the requirements of the project itself. But the reason why the team wants to finish the sprint earlier is not adequate and must be discussed with the Product owner. In his opinion, he can assess how to act in the situation, and discuss the possibilities for the company’s training to be moved to a further period.
The development 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.
This is not a good idea. The exact time (which is again determined by the scrum team) must be the same duration in each sprint until the product is completed. This allows the team to get used to working at the same pace, as well as to adequately assess how much effort you have to give for a task to be completed on time. When there is a fixed time for each sprint, the team can more easily assess their speed of work, the duration does not change. In this way, the team is also much less likely to be distracted by external factors when it knows that there is a deadline for achieving the current task. Concentration increases, and the team becomes more productive.
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.
In this situation, I will arrange a meeting with the development team to discuss the sprint goals set by the Product Owner. As we will discuss all user stories so that they can assess the sequence in which they could do them, so that the sprint can be completed according to the expectations of the Product owner and the customer. In case of any questions from the team, we will hold an online meeting with the Product owner to clear up any ambiguities.
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 continuously with the client so that he can describe as many details as possible about the work for a long time to come.
Here I would gather information from each member of the team with his approach to work. Also, what useful habits they have developed during the work process, and what they would change to be able to work even more productively. I would like to know from them what difficulties they have experienced since the beginning of their work on the current project, so that this can also be provided as information to the Product Owner. I will also describe what a working day consists of, ie what is its structure in relation to the team, so that the client can get a clear idea of how we work.
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.
In my opinion, even if there are enough User Stories in the Product Backlog, the Product Owner must determine exactly which of them will be worked on in order to have some structure during the sprint. I can’t tell the team which ones are more important than others or less important. In my opinion, there should always be planning before the sprint itself.
The Product Owner role has told your team that some functionality is expected in a few months. Your team plans to do technology research from now on to save yourself any problems and lack of competencies over time.
I don’t think that’s a good idea. This will lead to distraction during the current sprint because colleagues will spend extra time exploring future features. However, the customer may decide that he will no longer need the mentioned functionalities and if work has already been done on this, it will have been in vain. That’s why it’s not good for the team to deal with side activities that have nothing to do with the current sprint.
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.
In this situation, I will seek a conversation with a colleague so that he can explain to me the reasons why he did so. If the colleague is going on leave soon, it means that he has not gone out yet. That is, he will be able to help his team successfully complete the tasks in the current sprint, instead of dealing with unnecessary things such as work that is already planned for the next one.
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.
Scrum cannot exist without the so-called transparency between team members. I will talk to him so that I can explain to him why the team works this way, and what are the benefits of having the work shared and constantly discussed between each member of the scrum team. Frequent communication between team members gives rise to new ideas. These ideas often lead to the work of another team member becoming more productive because he has learned new techniques from his colleagues.
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 team can offer a duration for their sprint. He asks you to recommend time for their sprint.
Here I will have to talk to a professional Scrum Master about the product they are developing. I can’t offer him a sprint length for a product I don’t know. The length of their sprint is determined by the team working on the product, depending on their known pace of work. The length of the sprint also depends on the customer, not just the product. When the client expects more frequent results, the sprint itself should be shorter. This allows for frequent feedback from the customer. The colleague must find out for himself what length will be most suitable for his team, also in relation to the product and the client they work for.
The Product Owner role of your team wants to change the duration of the sprint to 6 weeks as you start integrating very complex systems and does not want to discredit yourself, your team and the organization in front of the client with sprints where you risk not being able to deliver real work done.
In Scrum practices, a sprint does not last more than 2 to 4 weeks. The length of the sprint depends a lot on the technology the team is working on. When the sprint is too long, and is more than 4 weeks, this can lead to a lack of concentration on the goals for the sprint itself. And in general, it is up to the team to determine the length of the sprint, because they are clear about what they can achieve in a sprint, and accordingly to assess its length in relation to the product they are currently developing. It is best to determine the length of the sprint at the beginning of the project before starting its development. Thus, the team can discuss how long it will take them to develop the product.
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.
I will discuss this with the Scrum team. According to Scrum practices, a sprint is between one and 4 weeks. Here we have to take into account the Scrum team, and with that, they really need how much time they will need to provide a fully finished increment of the product. But in general, the sprint should not be less than a week, and this is also a fairly short period of time. Especially when it comes not only to assembling hardware but to writing code and developing a product from scratch. I would discuss this with the team hard to see what they think about it.
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.
I will discuss this request again with the Scrum team. They are the people who have to determine the length of the sprint, according to their speed of work. The idea of shorter sprints allows for more frequent feedback from the customer. If the team is relatively new, this will not be bad at all, because in this way we will receive more frequent feedback and it will be possible to eliminate any errors from the current product earlier.