PSM III sample questions - review and feedback

Alen,

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?

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.

Hi,

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

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.

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

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: https://medium.com/serious-scrum/road-to-mastery-619a73f84944

Hello

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

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

https://www.scrum.org/resources/blog/scrum-guide-reordered

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.

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.

Hi Everyone.

I'm just preparing for the PSM III Assessment and I'm trying to reply to the same question. Someone can give me feedback on the correctness of my answer? Plus, there is some suggested material that I can study to prepare for the exam? 

Thanks.

Here is my answer:

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 fosters Empiricism by giving transparency on the output of the work, the increment. With transparency, the sprint review allows the stakeholder to inspect the increment and suggest adaptation for the future sprint adjourning the backlog.

If some developers were not present at the Sprint Review, they lost the possibility of inspecting and adapting the increment. This can bring to a considerable deviation from what the stakeholders really expected which can bring to a considerable loss of value.

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

You need to explain to the Developers that the Product Owner focuses more on the desired outcomes than on the features or the implementation detail. In this scenario, you can encourage the team to directly work with the stakeholders keeping in mind the product goal and the sprint goal. In fact, the Product backlog refinement can be delegated to the Developers.

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

The Daily Scrum is a mandatory event that helps the team to make the plan for the next working day for progress toward the sprint goal. So even if the team collaborates throughout the day is also important that they participate at this meeting to improve communication, rapidly identify impediments and track their solutions.

4. The Product Owner asks the Development Team to pick up a very urgent item late in Sprint that was not forecasted, 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.

During the sprint, the Developers are committed to the sprint goals, not to the customer's happiness. So if the activity is not related to the sprint goal the Product Owner has no reason to push for this new activity. 

In addition, avoiding improving their process can bring to gain technical debt that can lower the quality of the product.

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 productivity, the CEO instructs the team to cancel, rather than pre- or postpone the Retrospective. She argues: “They have so many anyway, and this new unique event is also somewhat of an informal gathering”.

The sprint retrospective is a mandatory event because it permits inspection of the scrum team and its way of work and permits adaptation for the next sprint. If you delete one occurrence you lose the opportunity for a fast improvement.

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

The scrum master isn’t the boss of the teams. He doesn’t provide a performance review because in this way he can undermine the trust within the team. Without trust, you lose openness and courage which are important values of the scrum.

7. During a Sprint, the Development Team realizes an item is 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.

In this case, the Developer finds that the work selected for the sprint was different than the initial plan, so the Developer, according to the Product Owner can select a different item from the product backlog to work on. The important thing is that they need to consider what’s the sprint goal in selecting the new work because the new item needs to be useful to the sprint goal without decreasing its quality.

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

The definition of done of the PBI needs to include at least the organizational policy and standards. So the process improvements need to be in line with the DOD and so wi try the organizational policy and standard.

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.

This is wrong because the backlog needs to be visible to all the team and the stakeholders to foster transparency. In addition, the developers can need to access the backlog during the sprint repetitively to add more details about an item so they have to access it directly.

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

Before changing the definition of done the team needs to look at the consequences to change it. For example, removing some tests can lead to the quality of the product. Therefore before changing the definition of done the teams need to look if they can acquire the needed skills in another way, maybe with training.

11. Just before 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.

The Sprint Review is the moment where all the scrum team and the stakeholder inspect the work done and assess if the definition of done is met or not. The team member can share his concern in this event so all the Scrum Team and the stakeholder can decide together where the problem is and what to do next.

12. During a Sprint Review, when the Development Team is answering questions about the increment, there is a discussion related to working 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.

The definition of done is created and owned by the Developers and helps to create transparency on when a Product Backlog Item becomes an increment.

In this scenario, the team needs to look at the definition of done for say if the PBI is considered Done. 

If the definition of done isn’t clear, the developers need to clarify it with the scope to avoid future doubt.

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 are deemed very complex. The Product Owner refers to an earlier ‘similar’ Product Backlog item, which was not complex at all.

The Developers and the Product Owner should collaborate during the sprint for the product backlog refinement. In this activity, the Product Backlog Item is broken down into more detailed items. Only with a detailed PBI, it’s possible to compare the complexity with another item. But it’s important to know that only the Developers who are doing the work are responsible for the sizing. 

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

The Daily Scrum is an event that helps to plan the work for the next day highlighting impediments. It helps to give transparency over the Sprint Backlog.

The sprint review helps to analyze the work done and the work that needs to be done. It helps to give transparency over the Product Backlog.

The definition of done helps to give transparency over the Product Backlog Item because only when the DoD is met, the increment is born.

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

The two main risks are that not all the developers are aligned with the work needed for the next working day, plus fast problem resolution becomes difficult if not all the developers are present maybe because some skill is missing in the events.

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

Even if the daily scrum helps to give transparency to the Sprint Backlog, it’s not a status meeting. In 15 minutes the Developers need to plan the work for the next day and they don’t have time to waste to give a complete status of the development.

If the Product Owner wants to have this kind of status he can directly inspect the sprint backlog.

17. The Product Owner suggests postponing 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 sprint planning starts at the start of each sprint with no waiting. In these events, the product owner and the developers can collaborate to clarify the product backlog item for making the sprint backlog.

The product backlog is never ended, so there is no reason to wait for it.

Question number 4: I have read different answers to this question which show varied perspective of thinking May be related to individuals’ own experience. I think sprint goal does not mean the door is closed for any new PBI to enter the sprint room. Unless the sprint goal is not affected, any PBI not forecasted earlier can still become part of the development work and especially in this scenario it seems the team is willing to work on the urgent customer need. I believe there should be a balance in happening of urgent requests but still it happens in the form of hot fixes unless it doesn’t endanger the sprint goal.