Scrum, in Short

Scrum is a style of process management. Scrum is most applicable to software development teams building products, however it can be used in nearly any walk of life and works for personal to-do management as well.

Jump to:

The People Involved

Scrum is a team process. Here are the people that scrum defines:

Stakeholders: people not directly involved in building the project, but the people who are invested in its success. This could be your company's CEO and Sales Team, or it could be a team of people at a client's.

Product Owner: this person is directly involved with the project and can make executive about its direction. This may be a stakeholder who can dedicate a lot of time to the project. The product owner must be available to the team during the sprints.

Scrum Master: this is typically one of the team members on the project, but with the additional responsibilities of facilitating the various scrum meetings and processes.

Scrum Team: the team that's actually building the project. They work with the product owner to deliver usable results each sprint.

The Parts of a Scrum

Scrum is divided into one or two-week sprints. At the end of each sprint, the team gives a demo of new, usable features to the stakeholders and receive feedback.

This cycle ensures that the team never wastes more than a short amount of time pursuing something the stakeholders don't actually need or want. The team can pivot directions at the start of each new sprint in order to keep up with rapidly changing market forces.

In brief, each Sprint has the following parts:

Sprint planning meeting: this occurs at the beginning of the sprint, on Monday morning. The Product Owner and Scrum team decide what they want to focus on for the sprint, and add items to the sprint's backlog as a group exercise.

Daily standups: a short, daily meeting of no longer than 15 minutes, involving the Scrum Master and team. Each team member stands up and discusses their progress, to-do list, and blockers.

Stakeholder demo: at the end of the sprint, the team demos the progress they made to the stakeholders and receive feedback.

Sprint retrospective: after the demo, the Scrum Master facilitates a discussion about process improvements to focus on for the next sprint.

The Sprint Planning Meeting

The sprint planning meeting is typically led by the Product Owner or Scrum Master. In this meeting, the team decides on the priorities for the next sprint and starts fleshing out the backlog.

Story Points are typically decided by vote, by the people who will be implementing the feature. The Product Owner will decide on the product stories to add to the backlog, while the Scrum Master may reserve some space for process improvements coming out of the previous sprint's retro.

The Daily Standup Meeting

The purpose of this meeting is to get the team members in the same room together, discussing the project. The Scrum Master asks each team member three questions: "What did you do yesterday?", "What will you do today?", "What blockers do you have"?

Responses should be given in such a way that prompts follow-up action from team members. Make sure to tell coworkers about that new widget you designed yesterday, the API updates you need to make today, and be sure to discuss blockers with the product owner or whoever can help.

Team members should not try to resolve issues in this meeting, but rather go one-on-one afterwards to address issues.

The Sprint Retrospective

The purpose of the sprint retrospective is to reflect upon what went well and what went poorly in the previous sprint, looking for areas of improvement to focus on next time.

For example, if several developers had trouble keeping their development environments in-sync, perhaps the team can figure out a process improvement that will make their work more efficient.

The sprint retrospective helps identify these potential process improvements, and prompts the team to take action by adding these improvements to the next sprint.