Smooth Sailing: Checkpoint 1

You’ve made it to our first checkpoint, well done!

At this point our sailors:

• Formulated the purpose and definition of a Sprint;
• Listed the rules of the Sprint;
• Assessed their understanding of Sprint rules;
• Co-Created a Scrum Event table;
• Reviewed scenarios when to or when not to change the Sprint Duration;
• Reviewed scenarios when to or when not to cancel a Sprint.

Check for Understanding

5 minutes: Smooth sailing requires smooth feedback. Let’s see how much has really caught on. Aks for thumbs up 👍 or down 👎 for the following statements:

• During the Sprint... no changes may be made. (👎)
• During the Sprint... quality does not decrease. (👍)
• During the Sprint... scope may be clarified and renegotiated with the Product Owner. (👍)
• Sprints have flexible lengths, which enhances agility. (👎)
• Sprints are where User Stories are turned into Features. (👎)
• The Sprint is an Event. (👍)
• Shorter Sprints can be employed to generate more learning cycles. (👍)
• Longer Sprints should be employed when complexity is high to limit risk. (👎)
• A Sprint should be canceled when the Sprint Goal can no longer be achieved before the end of the Sprint. (👎)
• Only a Product Owner may cancel a Sprint. (👍)

Follow me