You’ve probably heard the words Agile and Scrum a lot in your professional work life, often interchangeably, and sometimes in reference to things that are neither Agile nor Scrum. Confusing, right?
This is a simple introduction so you know what’s what, quickly and easily.
What Is Agile?
Agile is a mindset for doing work in a team environment that improves teamwork, professional performance, and adaptability. The Agile mindset is focused on adapting to changing customer needs while still delivering a high-quality product, and is defined by the values and principles in the Agile Manifesto.
There is no single way to put the Agile mindset into practice, and numerous approaches have been developed. Scrum is currently the world’s most popular approach.
So, Wait, Agile Isn’t Scrum?
As you might guess from the different titles here, Agile and Scrum are not the same things. Scrum is an approach to applying the Agile mindset. Scrum is a way of organizing a team of workers to deliver incremental parts or features of a product over a short, fixed time period. Scrum grew up in the world of software development, but it can be used anywhere that individuals need to collaborate as a team to deliver something of value to a customer.
Why Choose the Scrum Approach?
Whole essays have been written on this. Mark discusses in more detail in his blog, but the simplified answer is because it works. Scrum encourages the team to improve on two levels at the same time. First on the product level, by gaining feedback from stakeholders on what is wanted. Second, collecting feedback about the team’s process and the way they work together. The first level allows us to get iteratively closer to the product the customer needs, while the second helps the team grow their skills and teamwork, and focus on delivering quality. Combined, these are very effective toward core Agile goals.
Scrum has a lot of unique terminology and concepts. Here are the main ones you’ll often hear mentioned.
A fixed period, ranging from one week to one month in length, during which the Scrum Team works to meet specific customer needs. As one Sprint ends, the next Sprint begins. The purpose of defining the work period is that it enables the Team to focus on a limited and prioritized number of features, and it encourages the delivery of at least some completed work to the customer each Sprint.
All of the people needed to get the product built and into the customer’s hands:
- ScrumMaster, who helps the team grow capacity to deliver value
- Product Owner, who manages the vision for what they will be creating
- Developers, who are the cross-functional group of people who will build the Product (e.g. in software development this group usually includes programmers, business analysts, quality assurance, user experience and more).
An ordered list of all the things the Product Owner would like to see the Team work on in the foreseeable future. These items are called Product Backlog Items (PBIs).
A tool used to provoke and summarize a conversation, between the Team and their Product Owner, for a better understanding of an item on the Product Backlog. The User Story provides context regarding who a Product Backlog Item is being developed for and why it is of value. *It’s important to note that this isn’t part of Scrum per se, but is a tool that grew up beside Scrum and is often used in conjunction. User Stories can be helpful but aren’t required as part of the practice of Scrum.
An event at the beginning of a Sprint where the Team plans the items they can complete in the next Sprint. They also craft a goal to act as a focus for their work.
A single objective shared by the Team that describes the purpose of the Sprint and ensures that everyone moves in the same direction. A simply-stated goal makes it easier to prioritize Product Backlog Items, assess whether tests and feedback are relevant to the goal, and summarize the work currently being done when asked by stakeholders.
A session during which the Scrum Team (Developers, Product Owner, ScrumMaster) prepare the Product Backlog for the next few sprints. New Product Backlog Items (PBIs) are added for new needs to be considered. PBIs that are too large to be worked on in a single Sprint are broken down into smaller items. Estimates are made as to how much time each PBI will require to complete. The Product Owner makes prioritization decisions about PBIs, sharing with the Team their reasoning.
The list of Product Backlog Items (PBIs) the Team has committed to for the next Sprint.
The daily meeting where the Scrum Team get ready to collaborate for the day, and check if they’re still on track to complete their goal forecast by the end of the Sprint.
The official checklist that Scrum Teams maintain of the qualities they intend their work to achieve. It helps the team assess whether their work is truly completed and deliverable to the client as having added value. It also helps them in Sprint Planning by reminding them of the quality they have committed to achieving, ensuring they only commit to PBIs they can get to truly “Done.”
An event at the end of the Sprint where the Scrum Team review the completed work with stakeholders. Stakeholders provide feedback on the completed work and ideas for product improvements. The Product Backlog will get updated during future refinement to reflect what everyone learned.
An event at the end of the Sprint where the Scrum Team reflects on all that happened in that period, with the intention to improve how they work in the next Sprint.