PSM III sample questions - review and feedback

Last post 10:43 pm August 22, 2020
by Joshua Wiechman
10 replies
12:36 pm December 7, 2019

Hi everyone.

I am currently preparing for the PSM III exam. While reading various books and blog post in order to cement my understanding of Scrum, I came across some question samples.

To be clear, these are not questions from the exam, but should be in the spirit of what one can expect to encounter in the exam. Even though it is written in the Term of Use "Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers" my understanding is that it shouldn't be an issue to discuss sample questions (as indicated in this forum post), since it is a way of learning and shearing experience?

In case I am mistaken, and even sample questions are not allowed, I apologize in advance and ask for the post to be deleted.

I've tried to answer the questions as best as I could, so I am interested in getting feedback from fellow PSM-III Scrum Masters (or anyone else interested in the topic):

1. Are the questions indeed in the spirit of PSM III questions, or are the questions on the exam are simpler/harder?

2. Would you consider my answers to be correct (I think this would be most helpful for everyone preparing for the PSM III)?

3. I am afraid that the time limit on the exam perhaps wouldn't allow for elaborate answers, so I am interested in any suggestions/advice on how to provide more concise answers (since English is not my native language).


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? 

Sprint Review enables empiricism by increasing transparency (honestly demonstrating the increment, providing all relevant information), inspection (feedback from the stakeholders) and adaption (potential changes to the priorities, product backlog or approach for the next sprint based on the feedback provided by the stakeholders).

If a member of a Scrum team is not present he or she could miss a key information provided by the stakeholders or potentially help clarifying questions stakeholders might have about the increment that would directly impact the future development of the product. If members of the development team are not present in the sprint review it directly impacts the transparency and lowers the opportunities for inspection and adaption.

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?

First I would try to coach the Product Owner to understand the importance doing the product backlog refinement together with the development team, and how development’s team understanding of the PBIs directly impacts their work and the delivered value.

I would also facilitate a discussion with the development team with the goal of finding out what they can do in the meantime to minimize the impact of Product Owner’s unavailability (perhaps changing how PBIs are defined so that even if PO’s time is limited, the information he/she provides is more valuable to the team).

 If, for whatever reason I am not able to convince the Product Owner to free up some time and get them to work together with the development team I will try to quantify the impact and do a breakdown of the cost of the Product Owner being unavailable during the sprint. I would present the costs in terms of wasted effort, unnecessary re-work, time spent waiting for decisions to be made, and so on. By totalling the number of hours or days and multiplying by the daily cost of the development team, we can have a pretty viable business argument for freeing up Product Owner’s time.

 If nothing changes, and the product development is still suffering due to Project Owner’s unavailability last two option would be to either assign a proxy (which I would very much like to avoid since I don’t believe it to be an appropriate solution in most situations) or escalate the issue to the management and see if it is possible to assign the development to another Product Owner who can dedicate more time to the team.

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.

I would point out the value Daily Scrum brings, backing it up with several examples of when the team themselves found it useful in the past, and present unwanted scenarios that might happen in the future if the daily scrum is abandoned. Daily scrum is a key event for transparency, inspection and adaption, so not having it would seriously impact the three pillars of empiricism.

I would listen and try to understand why the development feels that way about the daily scrum and together with them come up with the ways to refresh it and make it more meaningful. Even though Daily Scrum is mandatory, I would not option for “It’s part of Scrum so you HAVE to do it”. If there is no way for the development team to come to the conclusion that they still want it, I would look at abandonment of the Daily Scrum as a learning opportunity for the team. Sometimes the only way for the team to grow is Scrum Master stepping out of the way and letting the team make the mistakes and learn from them.

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.

Adding new requests late in the Sprint, and on top of that requests that are not picked by the development team, but imposed by the Product Owner and have nothing to do with the Sprint Goal goes against everything in Scrum. That being said, Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value – emphasis on the HIGHEST POSSIBLE value. Scrum is not used for its own sake but to deliver value, and in this case the urgent request will bring the most value to the customer.

If this request is to be met, it could be only under two conditions:

1. To use this incident for inspection and adaption together with the customer in order to understand why this happened and what can be done to avoid it in the future

2. Explain the customer the impact this kind of requests have to make sure they understand this is not to become a standard practice

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”.

It should be fairly easy to explain to the CEO the importance Sprint Retrospective has for the team and how it improves transparency, inspection and adaptation. There really is no reason whatsoever not to have it, since simply rescheduling it won’t impact the company event in any way.

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).

This is a very touchy topic since trying to measure individual performance generally goes against Scrum, and on the other hand it is still needed (or even mandatory) in most organisations. Development Teams are self-organizing and Scrum recognizes no titles or sub-teams within the Development Team.   Accountability belongs solely to the entire Development Team and not individuals.

If such input needs to be provided to the HR I would recommend at least using the  360 reviews within a Development Team who can provide valuable feedback to management.

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.

If the selected item is in line with the Sprint Goal (SG), there’s nothing wrong with that. Team members expressing concerns about not being able to meet the SG and renegotiating scope—what can be removed from the Sprint Backlog or what can be broken down to smaller items in order be more focused on the SG is perfectly fine.

If item is not in line with the SG, I would try to help the team understand the importance of SG and having all the items in line with the SG. It would also be good to inspect in order to understand why was a too complex item selected and adapt in order to avoid it in the future.

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.

Even though organisational policies and standards have to be respected, sometimes in order to facilitate change it is better to ask for forgiveness rather than permission. Stepping over the line is a very delicate and risky process, so the Scrum Master position in this situation should be based on understanding which policies and standards are not being followed, how serious could the repercussions be, how deep is his knowledge and experience when it comes to the organisation’s culture as well as his previous experience of similar situations.

This questions leaves too much to interpretation and assumptions so I cannot explicitly say what would be the most suitable answer. Scrum masters, as well as the whole Scrum Team should base their decisions on empiricism and what is known, not on guesswork.

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.

The value of the product backlog lies not in completeness, precision, detail or perfection, nor in capturing every possible requirement in every possible details. The value of the product backlog lies in transparency, in making clear what work needs to be done in order to create a minimally viable and valuable product, or product increment, therefore it is key for Product Backlog to be visible and accessible to the Scrum Team in order to maintain (or increase) transparency.

I would try understand the reason behind the Product Owner’s point of view and see if we can work together to address his concerns. Furthermore, it would be important to coach the Product Owner in order for him to understand the importance and value of the transparent and accessible Product Backlog, as well as the potential risks and issues that might follow if access to Product Backlog is restricted.

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”.

A “Done” Increment provides the ultimate transparency into progress and value delivery. If the team already knows that they cannot deliver an increment according to the current DoD, proceeding without changing the DoD actually decreases the transparency. When a team does not deliver a “Done” Product Increment in a Sprint, it is a sign that the team lacks important knowledge or capabilities – which is here obviously the case since they depend on a single team member, rather than being able to comply to the DoD as a team.

This failure represents an opportunity for the Scrum Team to examine and improve their processes, tools, how they work together and ultimately to adapt the DoD as they grow and mature as a team.

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.

Scrum team should be honest and transparent during the Sprint Review and explain the situation to the stakeholders – the fact that they did not produce a working increment. They should use the opportunity to inspect and discuss why this happened and follow up in the Retrospective in order to avoid this in the future.

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.

If the team has a clear DoD it should not be hard to determine if the item is Done or not. However, more important than determining if the item is in line with the DoD is to understand why this discussion is happening at the Sprint Review rather than making sure there is an agreement about all the items in the increment before the event. This situation indicates that there is room for improvement in team processes and should be discussed in the Retrospective.

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.

The team should work the with Product Owner on Product Backlog refinement during the sprint in order to have a clear and common understanding about the Product Backlog items. Development team is the one estimating the items and selecting the number of items they consider achievable for the Sprint. Product Owner should respect that, however nothing is preventing the Development team to discuss the item with the Product Owner and explain their estimation.

Furthermore if the item is indeed complex and the estimation is quite high, it would be prudent to decompose the item to smaller components and work on then. As smaller items are finished, the team learns more, reduces the complexity and is able to provide more accurate estimation for the remaining items.

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.

The value of Scrum artefacts lies not in completness, precision, detail or perfection, nor in capturing every possible requirement in every possible details (for example in Product Backlog or Sprint backlog), but the value of the artefacts lies in transparency.

Scrum events improve transparency of the artefacts. Transparency of the Sprint Backlog is impacted by Sprint Planning and Daily Scrum, transparency of the Product backlog is impacted by Sprint planning and product backlog refinement (not an event in Scrum, but it is in Nexus), and transparency of the increment is technically impacted by all events, but mostly by Sprint Review.

Making sure that the artefacts are at all time visible, accessible and most importantly commonly understood by the whole Scrum team is a key to increasing the transparency and making sure that the best possible decisions are made. Having regular product backlog refinement, making sure all members participate in the sprint planning and daily sprints, as well as having the team collocated in the same room with information radiators helps to increase transparency of the artefacts.

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

Daily scrum is a key inspect and adapt event. By not having all the development team members present, key information could be missed, which decreases the transparency and leads to misunderstandings,  issues, conflicts, potential time loss and overall lower value delivered and the end of the Sprint.

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

Only Development team participates in the Daily Scrum, but anyone else can attend and observe as long as it is ok for the Development team and if they are not interrupting the Daily Scrum. I stress the difference between participating and attending – they are not the same.

Furthermore product owner can:

- Speak at the request of the team

- Provide clarifications on the forecasted sprint goal

- Bring to the notice any new developments that might impact the sprint goal

- Cancel the sprint

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.

The only criteria for the item from the P. backlog to be added to the S. backlog is that it is clear enough for the dev team and that it fits into one sprint. If there are enough clear items for the Development Team to plan out just the first few days and start working on the Sprint, there is no reason to postpone the Sprint Planning. Product backlog is a living artefact and it is never finished and fully refined, but it grows and develops all the time, so therefore it is never needed for all the items to be clear in order to start with the Sprint Planning.


Thank you,


04:08 pm December 9, 2019


I do not know where these questions originated from, but they are very good "scenario"-type questions that challenge a Scrum Master's understanding and ability.

I won't comment on every question, but I did want to offer a few observations on some of the questions that may help you think about the scenarios in different terms.


  • #3 - How is the Development Team currently inspecting progress towards their Sprint Goal, and determining their plan for the day?


  • #4 - Under what conditions (if any) can the PO and Development Team negotiate during the sprint?  What is the Development Team using to determine whether this new item can be completed before the end of the sprint?


  • #6 - What might the consequence be for a Scrum Master providing their own performance evaluation on individuals within the Development Team?


  • #10 - How does an adjustable DoD, based on Development Team capacity or capability, affect an organization or a product?


  • #11 - How should the opinions of a single Development Team member affect Scrum?


  • #16 - What role do you think trust (or mistrust) is playing in this scenario?
10:13 am December 10, 2019

Hi Timothy,

thank you for your input, you've raised a lot of valid points. This is basically what worries me about the PSM III exam. There is a lot of nuance when it comes to complex situations and issues, you can approach them from different perspectives and you need to account for a lot of assumptions since the details are not provided in the questions.

I feel I would do much better if the PSM III was an oral one on one exam, where I would get the chance to ask follow up questions, have a conversation and properly explain my stance/opinion  and prove I understand the things a Scrum Master needs to keep in mind. I don't think all of that is possible in such a limited time during the written exam, and often answers need to be "black" or "white" which can lead to wrong conclusions since most questions are about "gray" situations.

I mean, the whole point is empiricism, on which Scrum is based, is to act on what you know and what you've experienced, so acting and answering questions on very limited information and without having the full picture and really understanding the situation is basically going against empiricism.

In short, I'm really not liking the PSM III exam format (mostly due to a very limited time and me not being a English native speaker), so I'm looking for any pointers I could get on how to make sure I get the right message across in my answers.


03:09 pm December 10, 2019


2) I my opinion everything you wrote is incorrect. PO seem to be busy, maybe he is running out there in the field, understanding the market and new opportunities. Or managing politics. Great! Hi job is not to specify PBI in greatest detail. 

In most extreme case, PO can theoretically just come to Sprint Planning, express Sprint Goal and leave. 

So, why Dev Team can't this "extra clarity" obtain directly by talking to customers? (Or to whomever has needed information). 

03:30 pm December 10, 2019

Alen, you mentioned approaching the questions from different perspectives, and I believe that is a sound strategy.

My thought is that, for each scenario, you may want to at least consider the following:

  • Does it promote or detract from Empiricism?
  • Does it support or hinder:
    • Any of the 5 Scrum values (Focus, Openness, Respect, Courage, Commitment)?
    • The roles or responsibilities mentioned in the Scrum Guide?
    • The events (and related rules) as mentioned in the Scrum Guide?
    • The use and purpose of any specified artifacts in the Scrum Guide?

I also want to thank you for this thread, as I also hope to pursue PSM3 certification soon, and this discussion has helped my thinking around these types of scenarios.

03:43 pm December 10, 2019

#1. Good answer, but be explicit about what is being inspected and adapted by means of a Sprint Review.

#2. Good answer, but far too wordy. You won't stand a chance of typing all of that in PSM III. What do you consider to be the salient points?

#3. The team should indeed collaborate throughout the working day. However, the purpose of the Daily Scrum is not to provide contingency should teamwork be lacking. The argument that the Daily Scrum can be disposed of due to ongoing collaboration is therefore spurious. The purpose of this event is to ensure the team has a plan and forecast of work, sufficient for the next 24 hours, which will take them further to the Sprint Goal.

#4. I suggest highlighting commitment and the risk of technical debt. The Development Team own their forecast of work for the Sprint along with any commitments they have made. If a process improvement if deferred, technical debt may be incurred as a result. No-one can force technical debt onto a Development Team or otherwise cause them to decrease any quality goals. If the team have committed to a process improvement, then their commitment must be respected.

#5. Be very careful here. Do not assume that it will be "fairly easy to explain to the CEO the importance Sprint Retrospective has". You may not have access to the CEO, and even if you do, the CEO may not care. A better course of action would be to understand where sponsorship for Scrum is coming from in the organization, such as a Product Owner who is accountable for value. You could then work with or through that sponsor so the CEO understands which behaviors are helpful and which are not.

#6. This is a fair answer, but I suggest referring to the Scrum value of "respect". It could be that the team member has invested greatly in certain performance-related actions, knowing and expecting to be assessed on that basis. That's the critical point. What are team members' expectations on this matter?

#7. Good answer, but it would be better to say that the exchange should not put the Sprint Goal at risk or cause quality goals to decrease. Strictly speaking, the exchange does not need to "be in line" with (i.e. relate to) the Sprint Goal at all.

#8. You haven't mentioned the organization's understanding of what "Done" ought to mean. Why not? The Scrum Guide indicates that "Done" may well be a convention of the Development Organization.

#9. The PO can be as conservative or as liberal as he or she wants regarding who has access to the Product Backlog. Transparency must be afforded to members of the Scrum Team; the degree of transparency permitted outside of the team is situation dependent.

#10. Fair answer, but pay more attention to the risk presented by technical debt, which can easily compound and lead to product failure.

#11. Good answer, but make it clear that it is the Development Team and Product Owner who determine whether or not the increment is acceptable. An individual Development Team member should raise any concerns, but would not individually and arbitrarily make this decision.

#12. Good answer, but the focus should be on whether the increment as a whole is "Done".

#13. Good answer. Bear in mind that the situation being described does not necessarily indicate a problem.

#14. Good answer. However, the Sprint Review also impacts Product Backlog transparency, and the Definition of Done impacts transparency over the Increment. Note: I'm not convinced this question is representative of PSMIII because it demands an unreasonable amount of elaboration to do it justice.

#15. Fair answer, but you should highlight the risk presented to the Sprint Goal.

#16. What might this imply about the ability or willingness of the PO to collaborate with the team during the working day?

#17. The Sprint will start regardless of the state of the Product Backlog, and ought to be planned accordingly. The Product Owner should help the team to plan enough work for the first one or two days, and to frame an achievable Sprint Goal.

06:38 pm December 10, 2019

Hi Alen, it's nice to see you're collecting feedback on these questions here in your road to PSMIII. TImothy, they originate from one of my articles:

08:17 pm December 10, 2019


I'm not very confortable with #2.

"First I would try to coach the Product Owner to understand the importance doing the product backlog refinement together with the development team, and how development’s team understanding of the PBIs directly impacts their work and the delivered value."

This is not coaching, this is convincing or at least teaching. My suggestion is, if you answer "I will coach", append 1 or 2 coaching question you will actually use, like "I'll coach the PO + DT will questions like : How can the PBL be 'ready' enough for you ? / What are some options to get enough details without working overtime ?"

Agree with Richard, you assume a lot of "bad" behaviors from the PO without knowing the full context (and we never get the full context)

Agree with Ian, you will not have enough time for such long answers. Try and be more accurate in order to spare time. Standard abbrevations are welcome

09:01 pm December 10, 2019

You may want to check out the scrum guide reordered by Stefan Wolpers to help you study. It provides a different way to look at the Scum guide

12:01 pm December 12, 2019

I would like to focus on 4th question and your answer. Why do you think it is against everything in Scrum? Does truly forecast made by Developement Team on Sprint Planning closes the door to Sprint? In my understanding, Scrum despite setting a couple of boundaries / constraints in Sprint, it also leaves a lot of room to adapt things on the go.

For me what is alarming in those question / situation is the treatment of this agreed process improvement. If there is a willingness to cross this boundary / constrain, it may be the symptom of not truly understanding the purpose of it and it even may be not really the highest priority improvement after all.

On the other hand, the Development Teams' desire to pick this request and do it within the Sprint timebox, when Sprint Goal is not endangered by this change, is something rather good and welcoming.

10:43 pm August 22, 2020

The answer to question #3 is constructive and the effort to facilitate is great.*

Others have correctly called out the purpose is to formulate the strategy / coordination to get closer to delivering the sprint goal over the next 24 hours.

I am uneasy with the teams experimenting response. The premise appears to be the team will skip Daily Scrum as an experiment and see problems that result in recognition of the event’s value. If the team does not understand the value, how will they correlate problems back to not holding Daily Scrum up? What prevent the team from thinking something else is the causation of problems originating from not holding Daily Scrum?

Stepping back, my personal observation over my scrum career is, when prescribed element from the scrum guide are skipped, problems occur. The practitioners, instead of then following the guide, experiment more to address the symptoms, often deviating more from the guide. Since Scrum is a framework, other elements will be affected. The team will not understand the causation and create more experiments. The trend is heading into more process over people while increasing the number of not followed key prescribed scrum elements. Again, my opinion, most posts on forums and articles denouncing scrum seem to have a root cause in which the framework was not followed.

Jumping back to the question. I see value in the team learning from failure, yet these pieces of scrum are prescribed for a reason.

As a thought exercise, what happens if the team perceived the results of not holding Daily Scrum are positive from their point of view? As a scrum master, you have just put yourself into a difficult position. The team is required to have Daily Scrum and the Scrum Master is required to enforce Daily Scrum occurs for a reason. Soft skills and diplomacy are critical for a scrum master, but it does not abdicate the explicit responsibility of the scrum master to make sure the scrum guide is followed. This takes courage, commitment, and focus.