Skip to content

Agile Scrum Note 04

Details of the Scrum ceremonies

Time-boxing

  • Time-boxing is setting a fixed time limit to any activity and letting other characteristics such as scope vary.
  • Scrum relies heavily on the principle of time-boxing. All meetings, ceremonies and project time windows are time-boxed. The sanctity of the time-box MUST be respected. This is a non- negotiable attribute of Scrum.
  • Time-box can be any length of time [1 year, 1 month, 1 day, 1 hour]
  • Control is achieved at the lowest level of time-boxing
  • If you are running behind the schedule, postpone it to the next time-box
  • Fixes the length of the iteration and the team determines how much functionality can be delivered in that fixed length of time
  • Advantages
    • Focus
      • Helps one to focus his attention on the job at hand for the specified period of time
    • Increased productivity
      • Defining a fixed time period and working diligently in a focused manner on the identified task, helps one to work smarter and harder and get more done. It helps to get away with "Parkinson's Law" and "Student Syndrome"
    • Realization of time spent
      • Defining a fixed time period helps you identify how much work is done in the specific time and avoids the idling time
    • Time available
      • Helps one to be consciously aware of the time available to perform the task at hand

Release

The concept of a Release has been removed from the latest Scrum Guide. The idea being that each Sprint should be considered a mini-release.

  • The customer would like to know what they can expect over a period of time
  • The process of release planning helps the Product Owner to convey the plan giving logical milestones
  • However, there is no particular sanctity with the release plan – the team must be in a position to release as and when the customer(s) demand it

Sprints

  • Sprint is a time-box within which the team needs to complete an agreed upon set of deliverables
  • The goal of each Sprint should be to produce "working software" having "near releasable" quality
  • The duration of a Sprint is typically 1-4 weeks
  • Once agreed, the Sprint deadline can NOT be extended
  • Sprint duration can change over a period of time or during the duration of the project

Factors in selecting a Sprint duration

  • The length of the release being worked on
  • The amount of uncertainty
  • The ease of getting feedback
  • How long priorities can remain unchanged
  • Willingness to go without feedback
  • The overhead of iterating
  • A feeling of urgency is maintained

No changes in a Sprint

  • Once the Sprint plan is agreed upon, there can be no more additions to the Sprint backlog
  • Changes to the committed stories are not allowed
  • There can be no extension to the Sprint deadline
  • The Product owner can:
    • Make changes to the product backlog (add, remove or change stories that are not in the Sprint)
    • Terminate a Sprint and re-plan (under extreme circumstances)

Daily Scrum

  • Each participant answers 3 questions:
    1. What did you do yesterday?
    2. What will you do today?
    3. What’s in your way?
  • These are not status sessions for the manager
  • They are team member commitments in front of the team
  • They are important because
    • G: It Gets the team together
    • I: Information is shared
    • F: It helps them Focus
    • T: It builds the Team
  • Best practices:
    • 15 minutes or less
    • The whole team stands (so that the meeting ends soon!)
    • Even remote participants are required and they stand too!
    • No side conversation until the end of the meeting

Sprint Review

  • Attended by: Team, Product Owner, Scrum Master, and optionally other stakeholders
  • The team provides a demo of the working system with new features
  • Feedback from participants is taken and recorded
    • Product Owner should consider it as potential backlog items
  • Purpose of a Sprint Review:
    • Validate understanding of requirements
    • Get feedback
    • Check that the team is on track (or find out if it is not)
  • Also check
    • Items which were on the Sprint backlog but not completed (partially or totally) are added to the Product backlog
    • Product owner triages feedback and adds those to the backlog
    • If a customer (or stakeholder) wants to start using the product (or a feature in the product), the Product Owner takes a call about releasing it (alpha or beta)
    • Optionally record the demo and make it available to others who could not attend
    • The team formally closes the Sprint after doing the retrospective

Sprint Retrospectives

  • A 1-2 hour meeting at the end of each Sprint
    • To review what is working and what is not
    • To come up with actions to improve
  • Attended by the Team, Scrum Master and optionally a neutral facilitator
  • What it is NOT
    • A meeting to assign blame
    • A performance review for senior management
  • Why are retrospectives important?
    • Provides the team visibility
    • Enables them to take control of actions
  • Making retrospectives effective
    • Create lists
      • What is working (Keep these)
      • What is not working
      • What could we try in the next Sprint
    • Get input from everybody
    • Prioritize the list and agree upon few things to try
    • Assign actions and follow up
    • Agree on token penalty of actions are incomplete
    • Find a way to make the meeting fun