Scrum explained.
A quick and simple summary of Scrum.
What is Scrum?
Scrum is officially defined as “a framework within which people can address complex adaptive problems”. It is often associated with agile methodologies and is popular with software development teams.
Scrum does not set processes, tools, or techniques. Rather, it is a general framework that can be used to structure the way a team develops a product, using whatever processes or procedures they choose.
The core idea behind Scrum (and agile in general) is that problems should be solved in small parts (incrementally) as quickly as possible, rather than trying to complete everything in one big lump.
For example, a client hires a team to create a new web app. A traditional (“waterfall”) approach saw the developers trying to build 100% of the functionality on the customer wishlist and releasing nothing until it is 100% done — an all or nothing approach. This often led to delays, problems with budgeting, and products that were obsolete before they were even finished. In an agile system, the developers release the product gradually (in increments), starting with the basic functionality and progressively adding more and more (iteratively). The advantage of this approach is that the product can be adapted more quickly and something usable (and money-making!) is available much more quickly.
In a Scrum project, each addition to the product is called an “iteration”, and it should be a working add-on to the product in some way. Each “iteration” is completed in a single “sprint”, which is a period of work. More on this later!
Weird Words Defined
- iterative: doing something again and again to improve it.
- incremental: in a series of amounts (often small!)
- develop: in the context of Scrum, this refers to doing complex work. It doesn’t just apply to software development, but let’s be honest — it usually does!
- empiricism: belief in using empirical methods. “Empirical methods” are based on what is seen or experienced rather than on theory.
Key Things to Know About Scrum
Although how Scrum is used can vary a lot, some key things will stay the same. So if you are joining a company that uses Scrum, you’ll need to know these three categories: artefacts, people, and events.
Artefacts (or Things that Scrum Uses to Organise Information)
“Artefacts” are essentially ways to organise essential information so that everyone in the Scrum knows what’s going on. These are sometimes seen in the form of walls of sticky notes or a list of cards. I like to think of “artefacts” as the physical or digital tools that are used in Scrum — actual thingamajigs!
There are three key artefacts:
Product Backlog
The Product Backlog is like a master wishlist for the product. It contains all the things that are needed for the product, both short-term and long-term, such as features, repairs, changes, and enhancements. It is also ordered in some way to prioritise or categorise the items.
More than one Scrum team can share a Product Backlog, especially if it is a large one.
Product Backlogs are never finished, as at the beginning of a project not so much will be known about the product, and over time the requirements will become more precise — and more details added to the Product Backlog items. The idea behind this is to prevent getting “stuck” with the requirements set by an initial quote and being unable to adapt to changes in the business or user feedback. Instead, the Product Backlog is continuously updated and adjusted by the Product Owner — more about them later!
The Product Backlog, being an artefact, is often found in physical form — perhaps a wall of sticky notes or a whiteboard. The idea is that anyone looking at it can get a clear overview of the product in a very short amount of time. Some companies use “Kanban” (visual card systems — Japanese 看板 for signboard), and there are digital tools available such as Trello and Taiga.
Sprint Backlog
This is a smaller version of the Product Backlog which is a detailed list of items to complete in the Sprint (a period of work, usually a month or less). Once the sprint backlog is finished, the team will have a whole “increment” or an update to the product.
The Sprint Backlog also includes a plan for delivering the product increment. As with the Product Backlog, the items can be modified by throughout the Sprint, and they will become more detailed as the Sprint progresses — but only by the Development Team.
Increment
This is the result of all the Product Backlog items completed during a Sprint. At the end of a Sprint, the new Increment must be “Done,” which means it must be useable and could be released as an update to the Product.
The Team
Scrum has unique names for particular roles in the team. These can sound a bit strange at first! The structure of a scrum team is meant to allow the team to manage itself without being told what to do by someone outside the team.
The Product Owner
The exact role of the Product Owner can vary quite a lot, but one thing is always true: they are the sole person responsible for managing the Product Backlog.
As part of this, they may choose the order of the Product Backlog, add details to the items, help optimise the value produced by the Development Team, and ensure that the Product Backlog is clear and visible.
A Product Owner can ask a member of the Development Team to do some of these things for them, but they are accountable for what is done.
A Product Owner MUST be just one person, not a committee.
The Development Team
These are the professionals who do the work making the product increments. These might be the programmers in a software development team, for example.
Under Scrum guidelines, the Development Team is authorised by the organisation to organise and manage their work. No one can tell them how to turn the Product Backlog items into Increments — not even the Scrum Master or Product Owner.
Scrum has no titles or sub-teams for Development Team members, as they are supposed to be cross-departmental. Individuals in the team may have specialised skills and areas of expertise, but they share accountability.
The Scrum Master
The Scrum Master is one individual who is responsible for promoting and supporting Scrum practices. It’s their job to help the whole team understand all of this stuff and more!
The Scrum Master is a “servant-leader” for the team, which means (although they are technically the manager) their role is to help and support. They are also there to manage interactions with people outside of the team — a sort of protective role to make sure that outsiders don’t try to direct or override the scrum process.
They also work together with other Scrum Masters in the organisation to help implement scrum properly throughout the company.
The Events (aka How Meetings & Work are Scheduled)
The Sprint
This is arguably the absolute central concept of Scrum. As mentioned earlier, a sprint is a time period of one month or less in which a “done” or usable product increment is completed by the Development Team.
For example, during a sprint, a software development team might complete a new function for an existing website.
Each Sprint needs to have a goal of what is to be built, a flexible plan that will guide building it, the work, and the finished product increment.
Sprints contain the development work and all of the other events: the Sprint Planning, Daily Scrums, the Sprint Review, and the Sprint Retrospective.
A new Sprint begins as soon as one ends.
Sprint Planning
The entire Scrum team works together to do this event — they come together to answer the following two questions:
- What can be made during this Sprint?
- How will this work be done?
As part of the Sprint Planning, the team also develops the Sprint Goal — this goal guides the team on why the increment is being built and what functionality they are aiming for.
Daily Scrum
This is a 15-minute event for the Development Team. As the name implies, the Daily Scrum is a meeting that is held every day of a Sprint. At the Daily Scrum, the Development Team plans work for the next 24 hours of the Sprint.
The Development Team uses the Daily Scrum to look at how much progress they’ve made toward the Sprint Goal, and if the team is on target to complete the work in the Sprint Backlog. They discuss the methods and technologies they are going to use and organise themselves.
Sprint Review
This is a meeting held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders (people who are not part of the Scrum Team but has a specific interest in and knowledge of the product) collaborate about what was done in the Sprint. This is an informal meeting, and the presentation of the Increment is to get feedback.
The result of the Sprint Review meeting is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.
Sprint Retrospective
After the Spring Review, the Scrum Team has another meeting — the Sprint Retrospective. In this meeting, the team inspects itself and creates a plan for improvements for the next Sprint.
The Scrum Master is responsible for this event and makes sure that the meeting is positive and productive.
The team will discuss how things went in the Sprint regarding people, relationships, processes, and tools.
I hope you find this simplified guide helpful! Happy sprinting!
