Your Scrum events might be slightly less well attended!

Your Scrum events might be slightly less well attended!

The list of identified events in the Scrum framework, like the number of roles, is highly constrained. Scrum walks the line between identifying a set of events that each follow a typical pattern and prescribing specific activities and tasks.  As a framework, Scrum leaves the control of specific behaviors to the team. Therefore each team has a customized approach to how they implement the events based on organizational culture and need. The events identified in the framework include:

  1. The Sprint: which is the time box for developing potentially implementable functionality.  The sprint generally ranges from 2 – 4 weeks, with the 2 week increment being the most common I see in the industry.  Once your team agrees on the sprint duration for a particular project, it generally does not change.  The standard duration of the sprint is called cadency. Developing a consistent cadence helps the team become predictable.
  2. Sprint Planning: a meeting for the team to plan the work they will commit to during the sprint.  Sprint planning is a two-step process beginning when the product owner identifies the units of work they want included in the sprint using the prioritized backlog and input from the team for guidance.  After the product owner identifies the work he or she wants in the sprint, the development team (I recommend that the whole team participates) estimates the work based on their velocity (how much work they typically get done in a sprint) and the activities needed to complete the work (completion must meet the teams overall definition of done). The team will either increase or decrease the number of work items based on what they can complete.  What the team WILL NEVER do is to change the definition of what done. The planning activity is complete when the team can commit to completing the work they can do during the sprint.
  3. The Daily Scrum: the daily planning session that generally begins the team’s day.  The daily meeting provides the team with a mechanism to plan the day and to ensure that issues blocking work do not fester. Try to keep the scrum meeting at or near the beginning of the day so that team can use it as tool jump start their day.  Team composition and time zone constraints will dictate when the meeting happens.
  4. The Sprint Review: the meeting at the end of a sprint for the product owner and stakeholders to interact with the functionality and provide feedback and acceptance.  The sprint review provides a platform to gather feedback from a broader constituency than the team itself. The whole core team should be interacting on a daily basis; therefore the review should be leveraged to include a wider range of stakeholders.  The product owner should drive the guest list with advice from the entire team.
  5. The Sprint Retrospective: a meeting for the team to review their performance and identify opportunities for improvement. The team should find at least one process improvement that they can make and then commit to making that change.  The change the team commits to should be captured as a unit of work and be incorporated into the next sprint backlog so that it gets done.  Process improvement is the obligation of the WHOLE team, not just the development team.

The five events identified in Scrum are sometimes explained as four meetings and the sprint, which is an intrinsic part of Agile techniques.  All five are important features that interact providing self-reinforcing discipline and feedback.  I usually worry less about how a team is accomplishing the events, rather I make sure they doing something that meets the intent of the events and are in line with the Agile values and principles.

Advertisements