The Sprint Review event is one of the main meetings in the Scrum framework, which requires the presence of the entire Scrum team. Instead of sharing theory and academic information, this report presents possible real and practical situations concerning the Sprint Review event. Reference: Scrum Study: Real situations related to the Sprint Review meeting
Your colleague, a beginner Scrum Master, asks you a question. He asks you if, for their 3-week sprints, they can accept the Sprint Review event lasting 2 and a half hours.
The first thing I would make sure of is that the scrum master does not think that he should organize this meeting, but that he simply asks for information. In general, the Product Owner is the person who organizes the meeting, knows exactly which people should be present, informs and invites them, etc.
Of course, in real life, there may be situations in which the Product Owner has delegated – for the specific sprint review systematically, for all reviews, this role of Scrum Master. However, this should not be taken as a practice, as it shifts the focus and responsibility to the Scrum Master – those for which he is generally not responsible. Reference: Professional Scrum Master vs Professional Scrum Developer
For a one-week sprint, the sprint review lasts 1 hour. Respectively for a 3-week sprint, the review should be 3 hours. Of course, this is only in theory – there are many exceptions to this. Maybe the sprint did not contain items that will take so much time in the demo and subsequent discussions. Maybe just the opposite. Perhaps experience shows that customers and businesses tend to discuss in great depth (for many reasons) or to express uncertainty. Maybe the opposite is true – they are concise in their discussions. Reference: Duration of the Sprint Review event (meeting), BVOP.org
The fact that the scrum bag says it should be 3 hours (and not 2 and a half, as Scrum suggests), does not mean that in reality, given the above, it can not fit in 2.5 hours. In reality, it would not be wise to spend too much time on things that can be done in less time – especially in Scrum, where all the meetings and ceremonies are so many and where the team has so many other things to do. Reference: Scrum and Kanban methodologies
I would explain this to him, and I would recommend him to ask his Product Owner if he (given that he knows customers and business people better and their way of thinking) if 2.5 hours would be enough for them – for the specific review and the specific increment work. Reference: Scrum problems, causes of failure and mistakes
You gather at the usual place for your Sprint Review event. Attendees are You as the Scrum Master, the Development Team without a new budding colleague, the Project Manager from the client, their Product Manager, Business Analyst, and a hired external usability consultant.
The Product Owner is missing. The novice developer is also good to be present, but let’s assume that he is hindered. However, the rest of the development team is there. All other representatives of the client and the external consultant are welcome.
However, I think it will be quite difficult for me to argue in front of them (since I am only a Scrum Master) why things are as they are. It is no coincidence that Product Owner invites people to the meeting, Product Owner leads the meeting (and possibly demonstrates the completion), and Scrum Master only monitors compliance with Scrum principles and tries to ‘protect’ the development team from possible conflict situations – and there are very likely to be, so I think the lack of Product Owner is problematic. Reference: What makes a good Product Owner and what do they do?
The Product Owner knows the product and knows why specific decisions were made during development. He can argue about this in front of customers. He can decide, in case customers disagree, how to proceed – whether any improvements should be prioritized, how high to rank them in the Product Backlog. The Product Owner will decide at the end of the meeting and based on the feedback received from the discussions, which things will be proposed to be developed in the next sprint and which to wait. Reference: Product Owner role in Scrum and real problem situations
The Product Owner role is of great importance for this meeting – everything described is not something that the development team, Scrum Master, and customers can handle on their own and decide unequivocally. Product Owner is the ‘intermediate’ layer in protecting both the interests of both customers and team capacity (Scrum Master takes care of this, but Product Owner is ultimately part of the organization’s insiders and has an interest in keeping the interests of the organization itself).
A project manager from your organization came to your Sprint Review event. He listens carefully and watches. He is pleased that the work is going well. Finally, he turns to you and asks you when you expect as a guide to releasing the latest finished developments to a real product in a living environment.
In the lecture on the role of Product Owner, we explained that release management is something that the Product Owner does. The question is to the Product Owner, not to the Scrum Master. Reference: Real Scrum problems of the Scrum Master role during the Daily Scrum meeting
The Sprint Review event begins. Shortly after greeting each other, the customer’s product manager opens a topic about the project budget. He is not sure if his organization’s resources will be enough to continue working on the product for another 6 months. Ask your Product Owner for comment and advice on their Roadmap.
There are no rules and restrictions on when exactly what should be discussed at the sprint review meeting. If the Product Owner, at the moment he sent the invitation to all participants, has written an agenda for the meeting, then, of course, it is a good idea to keep it.
But if it is not, then the discussions and the course of the meeting are held in the most logical order according to the specific circumstances and reactions. The question is indeed directed to the Product Owner – he is responsible for the budget.
At the Sprint Review event, business people and all representatives outside your Scrum team review what has been achieved and tell you that they have no questions or any other comments or suggestions, and prepare to leave the meeting.
I would ask them, before they leave, to focus on the remaining sub-tasks for the meeting. The meeting does not stop after the increment from the previous sprint is presented – it is necessary to discuss what will be developed in the next sprint (quite tentatively), which things are important, which are not so much. Reference: Problems of the Scrum Master role with the Sprint Review and Scrum Sprint Retrospective meetings
This is something that clients can take a stand on, and it’s a good idea to do it right now because the next meeting is planning the next sprint (or the retrospective is the next one, but the sooner the better. for the team). It can also be discussed when the development will be released into production – this is something on which they are directly dependent (of course, if not already discussed,).
Your client’s Account Manager will contact you and ask if you can demonstrate your product one day before the end of your sprint because they need to prepare presentations.
It should be borne in mind that the sprint show involves many people who are often not part of the organization in question. My experience shows that it is quite difficult to change plans like this with just one day’s notice. But let’s say it’s possible. Regarding the remaining Scrum events for the Scrum team – time for retrospect should be reserved as well. Reference: Scrum Sprint Review meeting Questions and Answers, by Marta Cooper Posted on June 15, 2020
In fact, in one of the previous lectures, I think it was written that Scrum Master can demonstrate, or someone from the development team – if everyone agrees, ok.
But in general, it is a good idea to have someone who has both knowledge of the business value and requirements and expectations of the product, as well as its technical features. Still, let’s repeat – this question should be to Product Owner, not to Scrum Master. The Product Owner is the one who will organize the meeting (unless explicitly agreed otherwise).
Your customer’s product manager disapproves of the Definitions of Done for one of your User Stories and refuses to accept work on it. Everyone is staring at you, including your product owner.
An interesting reaction from the product manager. In principle, DoD is not something that Scrum Master is responsible for, but something in which the whole team has participated together and recorded by consensus.
Ultimately, the person responsible for the user story and their execution is the Product Owner. Product Owner, when writing US / PBI and other various tasks, also takes care of the writing of DoD and possible acceptance criteria. Reference: Kanban methodology vs Scrum framework
The result may not be the full DoD and acceptance criteria (many of which are further developed during sprint planning), but for starters, it is the one who has to make sure something is recorded. The end product of these two things is also the responsibility of the Product Owner, he is the one who is responsible to the business whether the developer meets them, and if they are not complete, then he is responsible for their absence.
Of course, I emphasize again – this is teamwork, everyone contributes, but the responsibility for the absences is purely practical only to the Product Owner.
One day before your Sprint Review event, your client’s Account Manager contacted you and explained that they were working with the Marketing Department to prepare new plans. He asks you to send him items that your team will complete during the sprint.
The question is a little unclear to me. Which items will end during the current sprint (they are quite a lot of them already completed, given that we are the day before the sprint review)? If I understand correctly, I can send him the item list, yes. Eventually, there will be small shortcomings, as we are not 100% ready yet, but we are expected to be very close to the end if everything went according to plan.
This with the new plans I hope will be new plans for the upcoming sprint (not the current one). I would highly recommend him to orient the Product Owner as soon as possible because he may have already planned some items for development in the next one (and maybe for a few sprints ahead) and these new plans will have to be included there. Reference: Every Scrum Master must know the Kaizen principles
You have already presented your increment at the Sprint Review meeting. Product Backlog items have been officially announced as completed. There is no work left unfinished. Everyone looks happy. Business people offer, as everything is fine, to discuss possible promotions of team members who have performed well, and then want to take you for a drink.
Promotions are something that the organization will discuss with designated employees when and if it deems it appropriate. This is its authoritarian right and does not depend directly on outsiders. If this is to happen, we will hopefully share the Product Owner for the success of senior management, who will decide whether to increase employees or not. Reference: Scrum Development Team Questions and Answers https://projectmanagers.joomla.com/10-scrum-development-team-faq.html
Regarding drinks – this should not sound and look like ‘bribery’ of employees (in-state organizations, for example, there are quite strict rules about who exactly should accept ‘gifts’ – in a direct and indirect sense, as well as what is considered for ‘gift’ – here I do not mean the veiled meaning of a gift as a bribe, but any benefits), but in the end, it depends a lot on the type and culture of the organization, whether to accept this proposal or not.
In general, the situation should be as little as possible related to business relations (at least in my opinion!). Work is work, here we are not talking about who will drink cocktails with ‘the one who gives the money’ after that – these are personal (personal) and not business relations. Reference: Scrum Team questions and answers (FAQ) https://projectmanagement.bravejournal.net/pages/Scrum-Team-questions-and-answers-%28FAQ%29
Shortly before the Sprint Review event, a team member told you that User Story covers all definitions of completeness, but the finished work visually differs from the sketches included in the Product Backlog item.
Let us provide an opportunity for this to be presented to the customer and let the Product Owner (together with the customer) decide whether the user story in question can be marked as closed or not. The lecture mentions that a Product Manager may consider a task incomplete if it deviates from the DoD and the completion criteria.
But let’s not mention that things depend a lot – maybe the 1: 1 visual product with the sketches is not a criterion in this case (yes, it sounds strange, but maybe there are such examples). If the product works and meets the customer’s needs in this form, it can be accepted, but this is something that the Certified Scrum Master must consider based on the reactions and subsequent discussion. Reference: http://projectmanagers.wikidot.com/bvop-scrum-master-certification-bvosm
While browsing the Product Backlog items, the customer project manager interrupts the conversation and asks a question to your Product Owner. He asks him why two very similar items are rated with Story Points 3 and 13. Your product is looking at you.
I think the described flow of information is quite logical. As a Scrum Master, of course, I would defend the estimate, as there is a reason why there is such a big difference in ratings. Maybe to the client (and even to the Product Owner), their tasks look similar, but eventually, there is talk of a difference in the way they are developed nonetheless.
Something of a technical nature that they may not be aware of. Something of a pure process-level (any kind of work process). Maybe just one was developed by a senior specialist and the other by a junior. Things are not always as illogical as they seem. I would take the side of the team, as I would eventually be aware and understand by this time why things are assessed that way. The development team can join the discussion if necessary and give details about why there is such a difference.