PSM1 Assessment on scrummaster.co.uk

1. During Sprint Planning, every task must be estimated so the Development Team is sure it has the capacity to complete them in the Sprint

Must Sprint Planning involve tasks being identified at all?

2. The Development Team must be no smaller than 3 and no larger than 9 members

What does the Scrum Guide actually say about Development Team size? Does it express any range as a rule, or does it provide advice to consider?

The Definition of Done is a mandatory part of Scrum

The Guide says that "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum". Might the Definition of Done constitute one such rule?

1. During Sprint Planning, every task must be estimated so the Development Team is sure it has the capacity to complete them in the Sprint

The Scrum Guide has 9 occurrences of the word "estimate(s/d)".  Three of the statements that help my interpretation can be found in the section that discusses the Product Backlog.  

Product Backlog items have the attributes of a description, order, estimate, and value.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. 

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. 

I view any items that are well understood will have estimates associated. Lesser understood items may not and if they do they will change as more is discovered. I actually advocate that the lower ordered have no estimates as there is usually not enough information to estimate. I see no reason to estimate tasks unless tasks are included as Product Backlog Items.  If they are basically sub-tasks for a PBI that has been included in the Sprint Backlog, estimating them is entirely up to the Development Team since they own the Sprint Backlog. 

2. The Development Team must be no smaller than 3 and no larger than 9 members

•  False
•  True -- I choose this

Key word to me in this question is must.  The Scrum Guide provides suggested size but there is no requirement to satisfy the "must" interpretation.

The Definition of Done is a mandatory part of Scrum

•  True
•  False -- I choose this

@Ian gave the same answer I was going to give.  All artifacts, events, roles and rules provided in the Scrum Guide are considered mandatory or you aren't following the Scrum framework without them. 

1. During Sprint Planning, every task must be estimated so the Development Team is sure it has the capacity to complete them in the Sprint

•  False
•  True -- I chose this

All PBIs (not tasks) have DOVE attributes:  description, order, value and estimate. The Dev Team will create a plan for accomplishing the work they selected from off the Product Backlog, but it may not — probably shouldn’t — have ALL their tasks identified since their work, inside a complex domain, will emerge over time. The team doesn’t have to be sure they’ll get all the work done — there should be some healthy tension they won’t get it all done. That adds a healthy amount of stress and creates joy when the team succeeds in all they aspired to. If it looks like they can’t get it all done as originally envisioned, they should renegotiate with the PO on how they’ll achieve the flexibly-stated Sprint Goal.

2. The Development Team must be no smaller than 3 and no larger than 9 members

•  False
•  True -- I choose this

The 3-to-9 Dev Team is an ideal size that balances diversity within the team against the necessary communication channels between team members. You could have a Dev Team of 2; you may suffer from a lack of diversity, a lack of creativity, a lack of innovation. But you could form such a team and still use Scrum. You could have a Dev Team of 10, but you may find it too difficult to effectively plan and coordinate each day inside the 15-min Daily Scrum timebox.

The Definition of Done is a mandatory part of Scrum

•  True
•  False -- I choose this

The DoD isn’t one of the three Scrum artifacts (which are: the Product Backlog, Sprint Backlog, and the Product Increment). But the Dev Team must agree what “Done” means with such clarity and transparency that the PO (and SM) understands what the Dev Team means when they say they are “Done” with a PBI they selected from off the Product Backlog. As the team matures, the expectation is that the Dev Team will strengthen this definition to improve their quality. Note that an organization may stipulate (via standards, policies, procedures, and/or other forms of governance) a definition of “Done” items which can be a starting point for what the DoD means.

The Definition of Done is a mandatory part of Scrum

•  True
•  False -- I choose this

With a Great Development Team

Don't need a Definition of Done. Great Development Teams deeply understand what 'done' means for them. For the team members, writing down the Definition of Done isn't necessary anymore. They know. The only reason to use it is to make the 'done state' transparent for their stakeholders.

That goes against being transparent, having others like the Product Owner understand and sets you up for failure in communication.  That would be like just showing a picture without a description. Many people say "a picture tells a thousand words" which is very true. The problem is that everyone who looks at the picture sees a different thousand words and often are not on the same page.  By documenting the DoD, you communicate it, make it visible to all and enable everyone to understand it or ask questions.  By not documenting it, how do you improve it, prevent misinterpretation or communicate it?  What happens when a new team member joins?  What happens when you change the DoD and someone is on vacation that day, how do they know for when they return?

With a Great Development Team

Don't need a Definition of Done. Great Development Teams deeply understand what 'done' means for them. For the team members, writing down the Definition of Done isn't necessary anymore. They know. The only reason to use it is to make the 'done state' transparent for their stakeholders.

How will they continue to inspect and adapt what "done" means, if they lack a definition for it? Bear in mind that Scrum is meant for complex products and that a Scrum Team operates under conditions of high uncertainty, where much remains to be learned and will be emergent.

I'm preparing for the PSM exam as well. 

The Scrum Guide states "Optimal Development Team size is not "The Development Team size must be". 

Thanks for the clarifications.

@Nguyen. I agree with the other comments, It is imperative to have a DoD, otherwise there's nothing to compare against.The absence of a DoD goes against the rules and values... You need to compare A( DoD) to B( the delivered increment), the absence of one party makes the comparison invalid.