Scrum Master Alliance MCQ PDF

Preview

Summary

Scrum Master Alliance Multi Choice Questionnaire practice...

Description

1.

What is the time-box for the Sprint Planning meeting?

a. 4 hours for each of the two topics in a 1 month Sprint and proportionally less for shorter Sprints b.

1 hour

c. 4 hours in a 1 month Sprint and usually proportionally less for shorter Sprints d. 8 hours in a 1 month Sprint and usually proportionally less for shorter Sprints Explanation: See The Scrum Guide (2017) section Sprint Planning paragraph 2: "Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter." 2.

Which roles are required at the Daily Scrum?

a.

The Developers plus the Scrum Master as facilitator

b.

Only the Developers

c. The Scrum Team plus others who are to coordinate with the Scrum Team d.

The whole Scrum Team

Explanation: The Scrum Guide (2017) states: "The Daily Scrum is a 15-minute timeboxed event for the Development Team." Note that it does not say "for The Scrum Team" or mention any participants other than the Developers. Further on it says specifically that: "The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum." Note that it does not say that the Scrum Master is responsible for conducting the Daily Scrum. It also states: "The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting." Whilst this indicates that other may be present, the question is about which roles are *required*. Developers is the only role *required* at Daily Scrum events.

3.

Which is not an authority granted to the Product Owner?

a.

Authority to decide what the Developers can work on

b.

Authority to decide when to release the Product for use

c. Authority to decide how many Product Backlog Items are allocated to a Sprint d.

Authority to decide what the money allocated to Sprints is spent on

Explanation: The Scrum Guide (2017) states at the start of Sprint Planning subsection Topic One that: "The Development Team works to forecast the functionality that will be developed during the Sprint." Also, more specifically: "The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint." Therefore, the Product Owner does not have the authority to decide how many Product Backlog Items are allocated to a Sprint. The PO does decide what the budget allocated to Sprint is spent on by deciding the content of the Product Backlog that is pulled into Sprints resulting in time and money spent on it. This also covers the authority to decide what the Developers can work on. The PO has the authority to decide when to release the Product for use. Evidence of this in The Scrum Guide is in the Definition of "Done" section which reads: "This Increment is useable, so a Product Owner may choose to immediately release it." Also in the Increment section: "The increment must be in useable condition regardless of whether the Product Owner decides to release it."

4. The most appropriate person and timing to present likely the delivery dates is: a. the Scrum Master during Sprint Review b. the Product Owner to stakeholders at steering committee meetings c. the Product Owner during Sprint Review d. a team member at the Daily Scrum Explanation: The Scrum Guide (2017) states that "The Sprint Review includes the following elements: ... Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product." These timing of release can be seen as within the scope of the Product Owner role given that this timing decision has a substantial impact on the

realisation of value from the product for which the Product Owner is responsible for maximising. Elsewhere The Scrum Guide says that the Product Owner decides when to release the product Increment. There is no separate "steering committee meeting" in Scrum. The Sprint Review is Scrum's replacement as it covers many of the progress, stakeholder satisfaction, timeline, budget etc. matters typical covered in steering committee meetings.

5. Which is not the desirable characteristic for a Scrum Master to exhibit? a. Big picture thinker b. Skilled communicator and influencer c. Ability to identify which work practices are and are not aligned with Scrum d. Being the direct controller of the process between Sprint Planning and Sprint Review Explanation: The Scrum Guide (2017) states that "Development Teams have the following characteristics: • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality". This means that it is undesirable for a Scrum Master to be "the direct controller of the process between Sprint Planning and Sprint Review". The Development Team is the direct controller of their own process. When this is enacted, it is called self-organisation. A Scrum Master is expected to be able "to identify which work practices are and are not aligned with Scrum" as is evident in many of the points in the Scrum Master section of The Scrum Guide (2017) that depend on such identification ability. "Skilled communicator and influence" as well as "big picture thinker" are qualities explicitly associated with Servant Leadership in literature on this including Frick and Sipe's "Seven Pillars of Servant Leadership". As the Scrum Guide says: "The Scrum Master is a servant-leader for the Scrum Team."

6. What is meant by “cross-functional” in Scrum? a. Each team member has all of the skills necessary to produce the Increment b. Each Developer has competencies covering more than one function c. The Scrum Team's Developers have all of the competencies to produce the Increment without depending on others outside of the team d. Scrum Team's Developers have T-shaped skills profiles with secondary and tertiary skills Explanation: The Scrum Guide (2017) states: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment". Note that it says "all the skills" and not skills covering more than one function. 7. Which is not considered an appropriate activity for a Scrum Master to engage in? a. Facilitating interactions between Product Owner and stakeholder b. Asking questions of the Product Owner that come from the Developers c. Working with other Scrum Masters to improve the effectiveness of Scrum in the organisation d. Teaching stakeholders about Scrum Explanation: If the Scrum Master were to ask questions of the Product Owner that come from the Development Team, they would be operating as an intermediary (aka "pipe") rather than a facilitator (aka "connector"). Facilitating is mentioned in The Scrum Guide and is widely regarded in the Scrum community as being more effective than operating as an intermediary as the latter involves delay, lower bandwidth and information loss through handoff, risk of misunderstandings etc. Operating as an intermediary is widely referred to as "the Telephone Game". The Scrum Guide (2017) states that the Product Owner is responsible for Product Backlog management which includes: "Ensuring the Development Team understands items in the Product Backlog to the level needed". This does not mention the Scrum Master role and suggests direct interaction with the Development Team. It also states that "The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't." This indicates that the Scrum Master is to teach stakeholders about Scrum. The Scrum Guide also states that the Scrum Master services the organisation by: "Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization."

8. e. Sprint f. g. h. Sprint

The Artefacts in the Scrum framework are: Product Backlog, Sprint Backlog, Increment, Release Burndown, Burndown Increment, Sprint Backlog, Product Backlog Product Backlog, Sprint Backlog, Increment, Definition of Done Product Backlog, Sprint Backlog, Increment, Release Burndown, Burndown, Definition of Done

Explanation: In The Scrum Guide (2017), the three subheadings directly under the "Artifacts" heading are: Product Backlog, Sprint Backlog and Increment. The 'Definition of "Done" ' sub-heading appears under the "Artifact Transparency" heading and the DoD is considered an agreement applied to the Increment artefact to uphold transparency. 9. The Product Backlog is: a. Grouped into P1 through to P5 representing priority b. Arranged by relative size with large items at the top c. Prioritised into Must have, Should have, Could have, Won’t have sections d. An ordered list Explanation: The first words under the section "The Product Backlog" in The Scrum Guide (2017) are "The Product Backlog is an ordered list..." The "Must have", "Should have" etc. technique ("MoSCoW") involves grouping items into sections where there are multiple in each section. This is insufficient for a Product Backlog as it does not define which is first, second, third etc. of the many in "Must have" and other sections. This also applies to grouping "into P1 thorough to P5". A widely used metaphor for how best to shape a Product Backlog is that of an Iceberg where the items at the top are small with more detail and those lower down are large and with less detail. This is the opposite of one of the answer options here.

10. Which best describe a Sprint Backlog? a. The Product Backlog items selected for a Sprint plus the Sprint Tasks identified to deliver these to Done, irrespective of their status in the Sprint b. A backlog of tasks that have not yet been completed in the current Sprint c. The Product Backlog Items selected for the Sprint that are not yet Done d. The Sprint Goal, the set of Product Backlog items selected for the Sprint, as well as an actionable plan for delivering the Increment Explanation: The Scrum Guide (2020) states that: "The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)." The "plan" here is typically expressed using tasks that have "enough detail that they can inspect their progress in the Daily Scrum" as is stated as a requirement in The Scrum Guide. 11. a. b. c. d.

When can new tasks be added to a Sprint Backlog? Whenever agreed by the Product Owner At Sprint Planning time only At any time during the Sprint Only during a Daily Scrum when agreed by the Developers

Explanation: The Scrum Guide (2017) states that: "The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learns more about the work needed to achieve the Sprint Goal." This indicates that whilst the Sprint Goal remains stable, the Sprint Backlog to achieve this goal can change dynamically throughout the Sprint as more is learned. This dynamic change generally occurs more frequently to the "how level" Sprint tasks more than the "what level" Product Backlog items. As such, tasks can be added or otherwise modified at any time during the Sprint. The limit to such change during the Sprint are the rules that: "No changes are made that would endanger the Sprint Goal" and "Quality goals do not decrease".

12. How often should Scrum Team accept a change in goal? a. At the start of each Sprint b. Every day c. Every release cycle d. Whenever priorities change in such a way that a different goal is optimal Explanation: As Scrum and Agile thought leader Henrik Kniberg says, Sprints strike a balance between agility and productivity by providing stability of goal for the period of a Sprint. Sprint Goal stability maximises the probability of the team achieving the Sprint goal compared the alternative of changing goal part way through a Sprint. The most frequently revised goal described in The Scrum Guide (2017) is the Sprint Goal. There is no concept of a daily goal in Scrum. The Scrum Guide rule: "No changes are made that would endanger the Sprint Goal" indicates that the Sprint Goal does not to change during a Sprint. The direction may change - even radically - from the start of the next Sprint at which time a new Sprint Goal is agreed. If a Sprint Goal becomes obsolete during a Sprint then that Sprint may be cancelled by the Product Owner. 13.

How is it decided whether a change to number or

composition of Product Backlog Items in the current Sprint can be accepted? a. The Scrum Master and Product Owner collaborate to decide b. The Product Owner decides based on whether it will improve the value derived from the Sprint c. The Developers decide, ensuring that such a change would not endanger the Sprint Goal or result in reduced quality d. The Scrum Master calculates whether the change can be accommodated within the team's allocated capacity Explanation: Sprints offer flexibility within boundaries. These boundaries are defined by the rules in The Scrum Guide (2017): "No changes are made that would endanger the Sprint Goal" and “Quality goals do not decrease". It is the Developers that defines a forecast during the Sprint Planning event and it is the Developer who assesses whether a change would endanger the Sprint Goal. This aligns with the rule that: "Only the

Development Team can assess what it can accomplish over the upcoming Sprint" [2017 Scrum Guide]. 14. Which is not a Scrum compatible way of tracking progress toward a multi-Sprint release? a.

A release burn-up graph

b.

A release burn-down

c.

A cumulative flow diagram

d. Percent complete status report relative to the total Product Backlog items prior to the first Sprint Explanation: As The Scrum Guide (2020) states: "Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful..." This indicates that these three techniques are Scrum compatible ways of tracking progress. A "Percent complete status report relative to the total Product Backlog items prior to the first Sprint" is reflective of a Defined Process Control approach whereby progress is assessing relative to a baseline plan (the defined process). Scrum is based on Empirical Process Control in pursuit of maximum value, not Defined Process Control in pursuit of execution relative to plan. 15.

How much of the Developers' time is allocated to Product

Backlog Refinement? a. As much as is required to keep 1.5 to 3 Sprints worth of the Product Backlog in a "Ready" state b. Usually no more than 10% of the capacity of the individual that the team elects to do the analysis c.

Usually no more than 10%

d. None as refinement is the Product Owner's job and the team should live the value of Focus on the current Sprint to maximise efficiency Explanation: As the Scrum Guide (2017) states: "Refinement usually consumes no more than 10% of the capacity of the Development Team." Note that is a capacity allocation for the team as a whole and not for an individual.

16.

We stage a very minimal but working product in an

inspectable environment. We subsequently add to it again and again, keeping it working every step of the way. Which of the following are we doing? a.

Iterative development

b.

Continuous Deployment

c.

Build Sprints

d.

Incremental development

Explanation: Incremental means adding to. Incremental development is a staging strategy whereby a subset of the eventual product content is added to at each Incremental step. For a new system, this would start with very minimal scope being included in the first Increment yet making that Increment a coherent working system. This differs from Iteration which is repeating. Iterative development is a deliberate rework strategy involving taking multiple passes at features or qualities of the product to enhance them progressively. Continuous Deployment is deploying every change for use that passes a series of automated checks without human intervention. This is an optional practice not prescribed by Scrum. 17. We deliberately produce a very simple and restricted version of a workflow in one cycle, and then return to it in later cycles to make it more sophisticated and flexible based on what we learn from earlier cycles. Which of the following are we doing? a.

Design Sprints

b.

Incremental development

c.

Minimum Viable Products (MVPs)

d.

Iterative development

Explanation: Iteration mean repeating. Iterative development is a deliberate rework strategy involving taking multiple passes at features or qualities of the product to enhance them progressively. For a new workflow implementation, this would start with a very simple and restricted version in the first iterative pass before making is more sophisticated and flexible based on learning in subsequent cycles.

The Minimum Viable Product (MVP) is not part of the Scrum framework. By the Lean Startup definition of MVP, it is a discover technique for hypothesis testing, not a delivery technique as this describes. 18.

What kind of Sprints does Scrum have?

a.

Design Sprints and Build Sprints

b.

None. Sprints are not to be differentiated by scope of activities

c.

Sprint 0 plus regular Sprints

d.

Regular Sprints and Release Readiness Sprints

Explanation: As The Scrum Guide (2017) states, a Sprint is 'a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created'. This means that all activities necessary to create such a complete product Increment are to be included in the Sprint. Scrum does not define different types of Sprint differentiated by activity such as Design Sprints and Build Sprints. To do so is activity restrictive (e.g. not permissive of doing "build" in in "design sprints"). As such socalled "Sprints" would not produce a usable and potentially releasable Increment, they should not be called "Sprints". Whilst "Sprint 0" is a widely used term, it has never been part of the Scrum framework and it is a misuse of the term "Sprint" to call preliminary work such as analysis and tool setup without intention to produce a "done" product Increment a "Sprint". Such a practice is considered a "slippery slope" by many as it erodes understanding of what a Sprint is and may lead to requests for more set up "Sprints", thus regressing in the direction of a sequential Waterfall process.

19.

When does a Sprint end?

a.

When the Product Owner accepts the Increment

b. When all selected Product Backlog Items meet their definition of "Done" c.

When all of the Sprint's tasks are completed

d.

When the time-box expires

Explanation: The Scrum Guide (2017) defines a Sprint as "a time-box of one month or less" and says that: "once a Sprint begins, its duration is fixed and cannot be shortened or lengthened". In other words, Sprints finish when the allocated time (the time-box) expires, no sooner and no later, irrespective of whether some, all, or more than the forecast work is "done". Completing all Sprint's tasks is not what defines the end of either the Sprint or the completion of the Increment. Sprint tasks are considered simply a dynamically changing means to achieving Sprint Goal and brining Product Backlog item implementations to "done" i...