Last Updated on October 22, 2018 by Brad Cypert
Scrum is designed to be simple. It is a series of lightweight components that, when followed, have been show to improve team workflow. Scrum’s approach focuses on respect for people and self-organization to adapt to unpredictability and the difficulties that come with solving complex problems.
The Values of Scrum
Scrum focuses on a set of core values that should be used when working with your team. The core values are as follows:
The ideas behind these should be obvious, but the implications of them may not be readily apparent if you’re coming from a waterfall background.
Courage is the ability to focus on the right solution despite how tough of a challenge it may be. This means doing the right thing, communicating challenges, and not cutting corners.
Focus mandates that everyone focuses on the iteration and the goals of the scrum team.
Commitment requires that the team focuses on the team’s commitment at hand. This often means helping others out regardless of role.
Respect requires that team members respect one another and trust that they are capable, independent individuals.
Openness is the one that is often difficult to grasp. Openness is simply being transparent about the work that you and your team are focused on, if you’re on track to meet your commitment, and communicating any challenges that you may face.
Roles on a Scrum Team
The roles on a scrum team are broken up into three separate groups. The Product Owner is the sole person responsible for managing the Product Backlog. The Scrum Master is responsible for promoting and supporting Scrum. Often times, but not necessarily, you’ll find the Scrum Master leading ceremonies and helping the team take a scrum-focused perspective on the challenges they face. Lastly, we have the Development Team. The Development team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.
You may find that your current job title doesn’t really fit one of those categories. Perhaps you’re design or you’re QA. In these cases, you’re likely to be considered a member of the Development Team.
The Sprint is another name for The Iteration. It is a set interval of time (often 2 weeks) that a team plan for, commit to, and work throughout. The important thing to note is that a sprint contains many ceremonies and work is committed to on a single Sprint basis. This allows the team to maintain flexibility while focusing on openness and commitment.
Scrum consists of several different ceremonies or events.
The main events are as follows:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Sprint Planning is an event that gives the team an avenue to inspect their upcoming sprint and plan what work can be completed during that timeframe. Work is selected from the backlog and pulled into the sprint during this time.
Once per day, the entire team gets together for the Daily Scrum. The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The use of the daily scrum helps promote focus, commitment and openness.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Retrospective is an event that takes place at the end of the sprint. It provides the team with a time to introspectively look at their sprint and determine what went well, what could be improve, and any action items they may have. Often times a retrospective is done using sticky notes or third-party tools like Ideaboardz.
Artifacts of Scrum
I’ve mentioned the Project Backlog and the Sprint Backlog at this point. These are two of the Artifacts of Scrum. The Project Backlog is managed by the Product Owner and is used when creating the Sprint Backlog. the Project Backlog holds all the stories that will eventually be consumed in a Sprint.
The Sprint Backlog is all of the work that hasn’t been started by the development team yet and is created during the Sprint Planning event.
Want to learn more about leadership? Find more of my Leadership related posts here.