I appreciate any feedback i could get on my answers to some free PSM 3 questions i found online

alright so the questions i found were taken from the scrum.org community posts, i found 23 questions, i timed myself while taking them and i realized midway how i was short on time a bit, i mean i had about 23 minutes left but usually, i finish essay exams fast (my wpm is 65, not too bad) but those ones made me sweaty and got me nervous 🤣 and i think u will see that in the way i answer them im like all over the place. alright enough of that lets get to it, i will paste it down below.

1. One of the Scrum events is the Sprint Review. How does the Sprint Review enable empiricism? What would the impact be if some members of the development team were not present?

The sprint review is a chance for the scrum team to inspect the increment and involve the stakeholders and gather feedback as well as adapt the PBL and the increment. The SR enables empiricism by inspecting the done increment. If some members of the development team were not present then the transparency that the team shares of the product diminish and probably those team members would not feel ownership of the increment and the developers would miss the feedback provided by the stakeholders.

2. You are a Scrum Master working with a Scrum Team. The Development Team constantly complain that requirements are not clear enough. The Product Owner claims she is too busy to provide extra clarity. What should you do?

I would talk to the PO to check her availability and then meet with the developers to check theirs to set a meeting. If clarity = increased value, then it is the responsibility of the PO to clarify, or the increment may not be what the customers or what the PO wants. I would also consider helping the PO and possibly clear enough time for her to collaborate with the dev team. But essentially, the PO and the development team must communicate and inspect the PBL to clarify items to provide quality, valuable work.

3. A Development Team, arguing it is self-organising, indicates it no longer needs the Daily Scrum; they collaborate throughout the day and they feel it has become a needless ritual.

The scrum guide says that the developers may collaborate and talk throughout the day, however, the daily scrum provides an official focused opportunity to inspect the sprint backlog and discuss what they are going to do in the next 24 hours and if there are any dependencies all in 15 minutes or less. The developers also share if they have any impediments and if the work they are selecting helps them get closer to the sprint goal. Self-organising doesnt mean that the developers do what they want, but it means they work within boundaries.

4. The Product Owner asks the Development Team to pick up a very urgent item late in Sprint that was not forcasted, nor is it related to the Sprint Goal. The Development Team believes it can pick this up, as it is close to meeting the Sprint Goal, but this would involve not meeting their process improvement goal agreed upon during the last Sprint Retrospective. The Product Owner argues that, as it’s the highest priority to satisfy the customer, the needs of the customer have a higher priority than the process improvement goal for the team.

It is up to the developers to add items to the sprint backlog, and the PO must convince them to add it there. If the sprint goal is not endangered by adding this item, and the perceived benefits outweigh the negatives, then the development team may post pone the process improvement goal for the next sprint. The whole goal of scrum is to provide a valuable done increment to the stakeholders and customers, and leaving out the process improvement this sprint, the developers can discuss why the Po came with this item mid sprint and how they can prevent stuff like that from creeping in and be more focused. -

5. The CEO announces a ‘company event’. The event is scheduled to take place at the same time the Sprint Retrospective is scheduled. As not to ‘limit the impact of this event on the productivity’, the CEO instructs team to cancel, rather than pre- or postpone the Retrospective. She argues: “They have so many anyways, and this new unique event is also somewhat of an informal gathering”.

I would coach the CEO that by canceling the sprint retrospective, the team misses a chance to inspect and adapt the sprint as a whole and the interactions between the scrum team. If the team canceled the sprint retrospective, then they would also miss that opportunity to inspect and adapt and further improve. And then I would pose a question to see which is more important, the scrum team attending this informal gathering or them inspecting and adapting the sprint and improving for future iterations to provide the customers and stakeholders with a valuable increment.

6. HR is requesting the Scrum Master to provide input for a performance review for one of the members on the team (because Scrum Master is assumed to be closest to the day-to-day performance of people on the team).

I would advise HR to look at the value the scrum team is providing as a whole and not at each individual working hours; being 100% busy does not equal valuable or quality work. Instead I will provide them with the increments that the team produced, and ROI and customer and employee satisfaction. If im going to use velocity or show HR the teams capacity for the sprint I would advise them not to compare it between teams or individuals since it is very easy to manipulate and that would most likely impact value and quality negatively as well.

7. During a Sprint, the Development Team realises an item it selected in the forecast is much more complex than estimated. With approval from the Product Owner the Development Team changes it for an item it thinks it can finish.

As long as removing that complex item does not endanger the sprint goal, the team may exchange it with some other work that they think they can accomplish. If the sprint goal is endangered and there is no way of accomplishing it, then the sprint can be cancelled by the PO and start over. The team can also break down the complex work further in a way that enables them to produce a done increment that meet the sprint goal. The scrum team should discuss this issue during the sprint retrospective.

8. A Scrum Team implements a process improvement goal that is not in line with organisational policy and standards. They argue they are self-organising and should be able to break with the ‘old ways’ through small controlled experiments.

Self organising teams does not mean that the scrum team can do whatever they want, they work and function within boundaries and rules even if they might be correct in their approach. One way to approach this issue is by showing the data of the current process, be it cycle time, or product quality concerns or the ability to innovate, show them the way they are working is resulting in issues with the product and unrealized value of the product. Then hopefully with the data you have acquired you can convince management to do a little experiment to improve the data points you collected where improvements can be made e.g., reduce time to market, after you have the data that you got by doing this new process, present it again and compare the old process vs the new.

9. The Product Owner is highly conservative over who gets access to the Product Backlog which is maintained in a personal spreadsheet. He argues that if anyone wants to have access to information about the Product Backlog they can talk to him directly or join in on scheduled Product Backlog refinement sessions.

I would coach the PO about transparency specifically and how it can impact inspection and adaptation. Transparency means that not only the scrum artefacts must be visible, but also well understood so that the scrum team can inspect and adapt frequently. Also by limiting access to the PBL, people outside the team such as management or stakeholders will not be able to view the work; the scrum guide implies that the work must be visible to those performing the work as well as those impacted by the work.

10. A Development Team discusses that due to the absence of a Development Team member it no longer has all the skills required to deliver a working “Done” increment according to the definitions of “Done”. It wants to adjust the definitions of “Done”.

The developers should be cross functional, meaning they have all the skills needed to provide a done increment by the end of the sprint or earlier. If an individual with a key skill is absent, then you can leave time for developers who are interested in that specific domain to learn the missing skill to keep the quality of the increment up. Also, it may be a good idea to hire someone to teach the developer/s the missing skill, nevertheless, they should keep quality up to reduce chances of technical debt piling.

11. Just prior to the Sprint Review a Development Team member determines some aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable.

An increment is born when it meets the DoD. if it is not done, then you should not present it in the sprint review. You should attend the sprint review and talk with the stakeholders about the PBL to inspect and adapt. This issue should also be discussed in the sprint retrospective to learn from it and not let it happen again.

12. During a Sprint Review, when the Development Team is answering questions about the increment, there is a discussion related to work on a specific Product Backlog Item that is not considered “Done” by some. The Development Team members that worked on the item are in disagreement. Some argue it is “Done”, others argue it is not.

It seems like there are two DoD which is why there is disagreement. The scrum team should follow the DoD provided by the organization as a minimum and add more to it as needed to improve the increment’s quality and limit bugs. If the increment needs work or is prone to quality issues later on, then the DoD should be adjusted. The team should discuss this disagreement in the sprint retrospective too and how they need one DoD they can all agree on.

13.The Product Owner doesn’t understand the estimate given by the Development Team regarding a Product Backlog item. The Product Owner is surprised to learn that the items is deemed very complex. The Product Owner refers to an earlier ‘similar’ Product Backlog item, which was not complex at all.

I would coach the PO that since the developers are the ones doing the work and understand the technical aspect of the work, they probably have a good understanding of the PBI. perhaps the similar PBI was estimated incorrectly, but after doing the work they realized it was more complex than anticipated and tried to give it a more accurate estimate. The developers are inspecting and adapting their estimates as more is learned and that is normal. At the end of the day, an estimate is only an estimate and nothing more, that is why scrum is based on empiricism.

14. Decisions to optimise value and control risk are made based on the perceived state of the artefacts. What events and practises can improve transparency over the artefacts? Explain why.

Although backlog refinement is not an official event, it is important to use it to clarify PBIs that will be selected for future sprints and size them appropriately. There are three artefacts in scrum, the PBL, SBL, and the increment. If they are not transparent, it means those artifacts are either not well understood or not visible/accessable, or both. You can use the sprint refinement to clarify the artifacts, and use the sprint planning event too, where the scrum team and key individuals meet to select work for the sprint. However, as soon as the team finds a chance to adapt they should use it ASAP.

15. What risk is introduced if not all Development Team members are present for the Daily Scrum?

Lack of alignment between the developer's work and the sprint goal. The daily scrum is a chance for the development team to discuss dependencies if there are any (by asking what they will do in the next 24hrs), how their work supports the sprint goal, and if they are facing any impediments. If not all the development team is present then they are losing the chance to inspect and adapt the work they will do.

16. The Product Owner insists on participating in the Daily Scrum so as to keep informed of the status and progress of development.

I would remind the PO on the purpose of the daily scrum, and it is not a status meeting. It is for the development team to inspect and adapt their work to align themselves with the sprint goal commitment. The PO and the SM should merely observe the event and not interfere with their way of doing the daily scrum as long as they understand the purpose of the event. If the PO wants to know the progress of development, they can check the burndown chart (this is not necessary to have) or any chart that the team uses to monitor progress, it can be a scrum board or any tool the team chooses to use.

17. The Product Owner suggests to postpone the Sprint Planning as she hasn’t yet been able to process all the feedback from the Sprint Review into the Product Backlog. She argues it makes no sense to plan the Sprint if the Product Backlog isn’t in a transparent state.

As a scrum master I would teach the PO about the purpose of the sprint planning event, the goal of the sprint planning is to plan the work for the sprint as well as make the PBL understood and visible. usually the feedback generated from the sprint review should be added to the PBL right there. However, since the feedback and adaptations are not in the PBL then the scrum team sits in the sprint planning and adds the feedback and adapts the PBIs in such a way that makes the PBIL well understood and transparent.

18. A member of the organisation comes to you, the Scrum Master, asking for advice on how to organise the Scrum Teams for an upcoming project. He has the budget for approximately 15 developers and thinks this is too large for one team. What advice would you give him? What advice does Scrum have about Scrum Team size?

The scrum guide suggest 10 people or fewer on a scrum team is good however this is not a rule, though I would inform that person that adding more than 10 people on a team will increase the complexity of the communication between each member of the team and perhaps I would suggest breaking it into 2 scrum teams. The scrum guide also says that the scrum team should remain small enough to remain nimble and large enough to get valuable work done. When scaling, i would suggest for the two teams to meet regularly and discuss dependencies and produce a done integrated increment at least by the end of the sprint, in the sprint review. They should have one PO, one PBL, 2 scrum masters, and 7 developers on each team.

19.The Product Owner on your Scrum Team says that he trusts the Developers completely. He empowers them to take ownership of stakeholder management, product backlog management and identifying a sprint goal. How do you, the Scrum Master, proceed?

The scrum guide says that the PO may delegate work to other individuals though the PO is responsible for the decisions they make. Although it is a positive thing that the PO trusts the developers completely, the PO should take some load off from the developers to let them get work done. Things such as idenditying a sprint goal is a team activity and the PO should be involved in that decision-making since they are the CEO of the product, the PO is the closest one to the customers and developers so they should be involved with the PO team as well. Not doing so will probably result in a misalignment of what the customers and stakeholders want.

20. The Developers are regularly over-running the time-box for the Daily Scrum. Some of them appear actively bored. You notice that it is often one team member taking the majority of the time. How would you proceed?

I would remind the developers of the scrum values that should guide the scrum team’s interactions. In this case, focus seems to be the issue here and also the team seems to have transparency issues. If they understood the purpose of the daily scrum, that its for ALL the developers to discuss the work theyr going to be doing in the next 24 hours, and how it relates to the sprint goal and if theyr facing any impediments, then everyone should get the chance to talk. After the daily scrum, i would coach the person who takes the majority of the time and see their point of view, and ask if they would rather talk all the time and not really collaborate with others (which leaves room for misunderstanding about the work) or let the daily scrum be that collaborative effort where everyone participates.

21.The Scrum Team you work with have missed their Sprint Goal for the last four Sprints. The Developers say this is because the Product Owner isn’t providing enough information on the Product Backlog Items. The Product Owner has heard about something called ‘Product Backlog Refinement’. How would you explain to him what Product Backlog Refinement is? What benefits are there if the Scrum Team start doing regular Product Backlog Refinement?

The scrum guide says that in product refinement or grooming, the scrum team meets to clarify items in the product backlog and size them appropriately, and put them in the ready state so during the sprint planning event selecting PBIs would be a little easier and faster for the scrum team to put in the sprint backlog and come with a sprint goal

. Although this is not an official event, it is advisable that every scrum team should do them, and the backlog refinement should take no more than 10% of the time of the scrum team each week.

22. One of the three pillars of Scrum is Transparency. One technique that improves the transparency is using a Definition of Done. What is a Definition of Done? How does it support transparency?

The DoD is a set of requirements for the increment, such that if an item met those requirements, then that means the product is shippable and useable. The DoD consists of quality standards. If the organization has a DoD, it is used as a minimum requirement for the developers, usually its better to add more items to the DoD as you progress through the work and learn more things. The DoD supports transparency by providing a clear understanding of when an increment is releasable for the customer, and the DoD should also be visible so that everyone is on the same page.

23. The Scrum framework identifies three artifacts. What are they? When are they inspected?

The three atrefacts are the product backlog, the commitment of the PBL is the product goal. The sprint backlog is the backlog for the sprint that contains the sprint goal, and the increment is the output of the scrum team that has to mee the DoD. all of these three artifacts should be transparent, inspected and adapted during the scrum events or as soon as needed, but the scrum events provide an official opportunity for the scrum team to inspect them.

I am thankful for anyone who took the time to read the mess above with the intention of providing some feedback (i will use it to inspect and adapt )