Smiling headshot of Nate, wearing a blue suit jacket, in front of some shrubberies

What is Scrum?

In the ever-changing world of project management, Scrum stands out as a popular agile methodology known for fostering quick adaptation and heightened productivity in software development teams. Having managed teams myself, I can attest to the practical utility of scrum, a framework that encourages continual feedback and iterative progress. However, it's important to note that scrum is not a universally rigid approach. Different organizations tend to adapt scrum principles to meet their specific needs, meaning the actual implementation can vary significantly across different teams and projects. While every instance encountered may differ, there are three core components that comprise most SCRUM processes you will come across: People, Ceremonies, Artifacts, and Communication Norms.

People

People are the most critical component to a Scrum process, as without people there is no team and no amount of methodology matters. The first defining aspect of Scrum is the roles identified and held by people in the team. Typically you will find at minimum the following participants:

  1. Product Owner or Stakeholder - creator and protector of the "product vision" responsible for prioritizing work according to business value and customer needs
  2. Scrummaster - facilitator responsible for fostering the environment of Scrum and empowering communication amongst all participants
  3. Development team - independent contributors and experts committed to building high-quality increments of the product in progressive iterations

Ceremonies

Ceremonies, or events, are the most encountered component in a Scrum process for most participants. Most work time during the week that isn't focused on development will likely be spent in these consistent meetings. The principal unit of any Scrum process which serves as the foundation for all ceremonies is the "Sprint." Whether a sprint is one, two, four, or eight weeks, it represents one cycle of iteration on the product. Work is prioritized and divided into sprints, and the conclusion of each sprint should result in a functioning product with some new value added. Commonly observed ceremonies include:

  1. Sprint Planning - Meeting to determine the scope of work for an upcoming sprint
  2. Sprint Review - Meeting at the end of a sprint to present the increment of work completed during the sprint
  3. Sprint Retrospective - Meeting after a sprint for the development team to reflect and iterate on the process itself
  4. Daily Scrum / Daily Stand Up - Brief meeting (ideally < 15mins) for the development team and Scrummaster to sync and plan for the next day of work

Artifacts

  1. Product Backlog - A prioritized list of tasks. Whether called "tickets", "issues", or "user stories", tasks include user definitions and technical requirements that define a feature or improvement.
  2. Sprint Backlog - Consisting of "tickets", "issues", or "user stories", the sprint backlog represents all tasks from the product backlog to be completed during a specific sprint
  3. Increment ("Release") - The sum of product backlog items completed during a sprint, along with the value of all previous increments. Generally each sprint ends with a "release" of some sort, including different technical environments the code/product may be deployed to and a consistent versioning scheme for tracking the progress of work alongside sprints.

Communication Norms

Communication norms are arguably the most critical component of a Scrum process, and clarity and consistency around these norms greatly impacts the experience of teams within the Scrum process. One of the principal responsibilities of a Scrummaster is ensuring communication continues to flow according to these norms. When these norms are misunderstood or ignored, the consequences can be catastrophic. Here are several norms most Scrum teams will define and hold as central to the process:

  1. Transparency - Artifacts should be transparent so stakeholders and product owners have a clear idea of what is being developed, and business priorities and leadership decisions should be transparent to development teams so adaptations can be made in real time.
  2. Definition of Done - Teams should maintain a shared understanding of what it means for work to be complete, used to assess when work is finished on a specific product increment.
  3. Handling Blockers & Dependencies - Lines of communication should be primed particularly for when things do not go according to plan. Whether it's technical blockers or external dependencies, every participant in the process should know who to connect and communicate with in all situations, and be empowered to do so independently when possible.

When present, well defined, and optimally combined, these components of a Scrum process should promote collaboration, adaptability, and iteration across software development teams. How much time is spent in meetings, what specific form artifacts take, and the actual participants of specific teams will lead to Scrum looking unique for each organization, but intentional consideration, definition, and proliferation of these pieces can lead to increased clarity and productivity for any organization looking for a project management methodology for iterative product development.