Chase Seibert

Director of Engineering at Dropbox

Scrum is a fundamentally adaptable process. One of the core pieces is the retrospective, where the team can collaboratively change the process itself. Team members learn from their mistakes and from each other about how to get better at delivering software. But before the iterative improvement can begin, there is a necessary bootstrapping. When introducing Scrum to a team for the first time, you can try to explain all of the nuances and edge cases up front. Or, like teaching people a new card game, sometimes it’s better to just jump in and play a few hands.

If you’re jumping in to Scrum, what are the bare basics you need to know? At its core, Scrum is about roles (Product Owner, Team Members and a Scrum Master), regular collaboration meetings (Sprint Planning, Daily Stand Up, Demo and Retrospective) and the organizational artifacts (the Backlog, User Stories and the Sprint itself).

Scrum Artifacts

What you are delivering is the same thing that it always has been; working software. These artifacts are just ideas and tools that the team uses for their own aid.

  • The Backlog is an absolutely ordered list of all the features that the team has ever considered delivering.
  • User Stories are individual features that could be delivered, defined at variable levels of clarity and granularity, from small already broken down and well specified stories at the top of the list (the next to be worked on), to large amorphous stories at the bottom that won’t get worked on for a long time, if ever.
  • The Sprint is a set interval (typically two weeks) during which the team commits to completely finish a small set of the user stories.

Scrum Roles

Likewise, the Scrum roles are just more well defined descriptions of people that are probably already on your team.

  • The Product Owner sets the order of the backlog according to the business value of each story. This person is the designated representative of both the company at large and the customer.
  • Team Members are your existing engineers, designers, QA, etc. Usually more than 3 and less than 10 people comprise the team. Ideal scrum teams are composed of generalists who are also technically deep in disparate specialties.
  • The Scrum Master is just a team member that the team itself elects to off-load any of the process drudgery onto. That team member needs to schedule the Scrum team meetings, do any prep needed for the meetings, and keep the team on track and following their own rules during the meetings. Critically, they also are tasked with removing obstacles to success, which most often means getting the team resources they need, and personally owning ad hoc work that would otherwise interrupt a team member (mostly bugs).

Scrum Meetings

No one likes meetings, which is why Scrum promotes the bare minimum of meetings needed to consistently and reliably produce working software on schedule, get feedback from the business and continually improve themselves. A scrum team can plan on spending up to 10% of their time in one of these meetings.

  • Sprint Planning is where the team breaks down the highest priority user stories into tasks and estimates how much work they are going to be. This is also where the team commits to which stories they are confident they can finish in the next Sprint. Ideally, features are defined in detail and mocked up going into this meeting.
  • The Daily Stand Up occurs at a set time every day, and consists of each team member briefly answering the questions: What did you do yesterday, what are you planning to do today, and are there any obstacles in your way? This should take less than 15 minutes, and usually occurs standing up to promote brevity.
  • The Demo is where the team demonstrates the functionality they have produced at the end of the sprint. The audience should be the product owner, plus any interested stakeholders. Ideally everyone on the team gets a chance to regularly demo what they have done.
  • The Retrospective is the team’s chance to make better mistakes tomorrow. Team members talk about what went well, what didn’t go well, and what they can do differently going forward. The team commits to an small number of achievable improvements and assigns owners to them.

Learning More

That’s all the context you need to get started, assuming at least one person on the team has done Scrum before. In any case, you may want to do some more learning on your own. To that end, I would recommend Essential Scrum or the classic Agile Software Development with Scrum.

For visual learners, I would recommend the three part video introduction by Collabnet. Parts: 1, 2 and 3.