Introduction to Scrum, its Roles, and Ceremonies
‘Scrum’ The Name Background
Scrum takes its name from a play in rugby where the players bind together in teams and try to take back possession of the ball. Injuries are common.
‘Scrum’ as in Software Development
The description above is an apt metaphor for Scrum development. It is a lightweight team-based Agile framework that is focused on getting the ball down the field in the fastest, most efficient way possible. Scrum is used for developing complex products and services with a focus on developing incremental units of business value within short iterations. It requires honesty, communication & adaptability. Just like the Rugby scrum it can be painful, but incredibly effective.
Now, let’s breakdown the components of Scrum. It is comprised of roles, ceremonies, and artifacts.
The Product Owner (PO) is the individual who makes the decisions on anything related to the “product”. The PO’s key responsibility is to make sure the team is developing products and features that deliver business value. The PO represents the voice of the customer and other business stakeholders. They drive the vision of the product and its features; create and prioritize the product backlog; define acceptance criteria and ultimately accepts the output from the development team. The PO is essentially an implant from the business world into the scrum team, as they are considered the product champion with the complete product know-how.
The Scrum Master (SM) is the servant leader for the development team. The SM makes sure that the team is on track to deliver the product in increments and within the time-boxed sprint schedule (more on sprints in a bit). They facilitate through devotion to the scrum process, and by swiftly eliminating scrum team’s impediments. They uphold the structure of scrum, and inculcates the principles of agile within the scrum team. The SM is a facilitator for the scrum team, and makes sure that the development team is aware of what needs to be accomplished and when, and that they have the ability to self-organize to accomplish the development tasks.
Team Members / Development Team
The Team Members / Development Team (DT) are those responsible for the implementation of the product or features. These are the set of people who are actually doing the what that has been proposed and conceived through the product backlog and grooming sessions. The DT is usually a cross-disciplinary group of individuals including engineers, UI developers, Analysts and Quality Assurance. The DT self organizes and decides the best way to accomplish tasks they pick up during planning. They provide estimates on stories within the product backlog as well as provide feedback on the acceptance criteria to the PO to help keep development on the right track.
The Product Backlog is a prioritized list of epics and stories created and managed by the Product Owner (PO). An epic is a large story and there may be smaller stories contained within. The story describes the feature in a way that makes the business value and use for the customer clear to all stakeholders so everyone can understand what is being delivered. A story is an increment of work that can be delivered by the team within the sprint cycle. Priority is set by the Product Owner, and the PO dictates the order in which stories are delivered by the team.
The Sprint Backlog are those stories that have been committed to by the team for the upcoming or current sprint. In order to qualify to be a sprint backlog candidate stories must have enough detail (meeting the Definition of Ready – DoR) that the team is comfortable estimating the size of the story (story points) and stakeholder input/approvals have been included. The number of stories in the Sprint Backlog are determined by teams capacity built over sprint over sprint, what is also known as their velocity.
Burn Down Chart
The Burn Down Chart is the means by which the Scrum Master, team and other stakeholders keep track of progress throughout the sprint. The ideal chart would have the team incrementally completing stories throughout the sprint and thus “burning down” the Sprint Backlog to land at 0 story points left at the end of the sprint.
Sample Burn Down Chart above – Blue line represents ideal progress, red line represents actual progress
Product Backlog Refinement (PBR)
Backlog Grooming is the process by which the Product Owner gets their stories Sprint Ready. It involves setting the vision, proving the business case, meeting with customers and other stakeholders, conferring with the team, working with UX & visual designers. Care should be taken to get enough detail into stories that the team is clear on what needs to be delivered and why, but not so much detail that analysis paralysis occurs. Grooming sessions with the team should be time-boxed to make sure their time is spent optimally and mostly devoted to getting actual work done delivering items for the current sprint. A typical grooming session lasts for about 2-4 hrs depending on the length of the sprint, and the development team has to make sure that each story meets their DoR as an input to the Sprint, and the acceptance criteria and assumptions meet Definition of Done (DoD) for the final approval of the story.
The Sprint is time-boxed cycle that is 1 – 4 weeks in duration. At the end of the Sprint an increment of the product should be completed and ideally delivered to the customer. Sprint Planning is the session run by the Scrum Master where the team decides how many stories they can take into the upcoming sprint. The team selects stories in priority order set by the Product Owner. A team that has been working together for several sprints or more will have a historic record of how many story points they can take into a sprint. This is referred to as their velocity. Ideally their velocity will increase over time as the team builds. The objective of the sprint planning is to commit stories for the upcoming sprint to the PO, and identify all activities required for the development of the story to meet the DoD.
Daily Standup (Scrum)
The Daily Standup or Scrum is facilitated by the Scrum Master on a daily basis at the same time everyday without fail for the development team. It is time-boxed to only 15 minutes. Each member of the development team comes on time, and answers three questions – what did they work on yesterday, what are they focused on working today and if there are any impediments in their way. Impediments are noted by the Scrum Master and taken to be discussed offline, and are addressed following the standup.
The Retrospective is a crucial ceremony in Scrum that invites Development Team Members to give an honest assessment of their team’s performance in recent sprint. It is facilitated by the Scrum Master, and may or may not include the Product Owner. Some teams may need the Retrospective as a place to discuss issues with the Product Owner and in that case may need them to be excluded to allow for open communication. Team Members each provide a list of the following categories: “Start Doing”; “Stop Doing”; & “Continue Doing”. These may be framed in different ways but basically the conversation should be open and constructive in identifying room for improvement; issues; as well as celebrating successes.
These are the basic components of Scrum. The best way to learn is to practice and each team will grow and modify the techniques to meet their unique group dynamics & development environment. Other good sources are –