Everything you wanted know about scrum
If someone says the word “scrum”, you may think they’re talking about rugby players crashing into each other. However, it is unlikely that to mean this if someone in the workplace brings up scrum, they probably refer to Scrum (as a proper noun). What is Scrum and why would you use it?
What’s Scrum about?
Scrum is a commonly used agile methodology for product development — a set of principles, team roles and routines (defined below) used in conjunction to produce iterative products for work. Scrum started in the software industry, spreading to universities, the military, the automotive industry, and beyond.
Why are you using Scrum?
According to Eric Naiburg, Scrum.org’s Vice President of Marketing, Scrum is best understood as an overall problem-solving approach that avoids strict detail and formal, step-by-step instruction sets.
Since groups, processes, and initiatives change and evolve over time, “finding only one way to do something doesn’t make development possible, says Naiburg. Simply put: Scrum is the opposite of a to-do list — instead, it is a dynamic way to approach group projects.
While Scrum provides a strong framework to organize product teams and scheduling work, it is a framework that can be moulded to accommodate a team’s needs as opposed to dictating exactly how a team should proceed.
What is the difference between the methods of Scrum and Agile?
You may have noted that the word “agile” was included in my Scrum description. You may also have heard of something called agile methodology (perhaps even in the same breath as Scrum). So two ways to explain the same thing are Scrum and agile methodology? Not quite.
The 1990s saw a general movement in the software industry away from highly planned and supervised methods of production. Software developers began to adopt lighter weight, more flexible methods, processes, and frameworks (such as Scrum), and in 2001 a group of 17 developers converged and published a document called the Manifesto for Agile Software Development.
The agile concept originated from this manifesto. While it does contain the Scrum framework, not all agile development is Scrum — that is, agile methodology is a blanket word, and the Scrum framework falls under that agile blanket.
What are the principles of Scrum?
Scrum is defined by a set of principles (or values) to be understood as simple guidelines for working as a team together.
- Courage — especially when it comes to solving difficult problems
- Commitment to shared group goals
- Respect for your team members
- Openness to work and any difficulties that may arise
By embodying the ideals of Scrum, responsibility is shared by a team for progress and that prevents possible pitfalls. All Scrum Team members must adhere to these principles, or else the structure that makes it successful will not be available to a team. And — whether the group is following the Scrum system or not — these are good principles for any organization.
How does Scrum function?
The architecture of Scrum consists of three distinct categories: functions, activities, and objects. Let’s break these down.
Three main roles are established in the Scrum framework: the Development Team, the Scrum Master and the Product Owner.
The Development Team is just what it sounds like — the people who work to produce goods together. Despite the title of “creation” and the history of Scrum technology, keep in mind that these products can be anything. Project teams are given the ability to coordinate and conduct their own work in order to optimize the efficiency and effectiveness of the project.
The Scrum Master is the resident facilitator of the team, responsible for helping all members of the team obey the principles, laws, and procedures of Scrum. We ensure that the Scrum Team has everything they need to complete their work, such as eliminating roadblocks that hold back progress.
The Product Owner is responsible for the tasks to be done by the team, whether they do much of that work themselves or assign it to other members of the team. The Product Owner is always a single person and not a committee; whereas when it comes to their decisions they will take feedback from others, the final decisions ultimately come down to the Product Owner.
Five events mark the Scrum framework. These are the Sprint retrospective, Sprint Planning, Daily Scrum, Sprint Analysis, and Sprint.
A Sprint is a specified time span during which a Scrum team produces a product (this can include a large project, multiple smaller ones, a series of documents, an app edition, etc.).
Sprint Planning is a meeting that maps the work that needs to be done during a sprint. The entire team identifies deliverables for the Sprint clearly during this meeting and assigns the work needed to achieve that aim.
The Daily Scrum (sometimes referred to as a Stand-Up or Daily) is a daily 15-minute meeting where the team has the opportunity to get on the same page and put together a strategy for the next 24 hours. Research from the previous day will be evaluated, and updates will be exchanged that day for research.
After a Sprint finishes, the Sprint Analysis takes place. The Product Owner discusses during the evaluation what work scheduled during the Sprint was or was not done. Then the team discusses the finished work and speaks about what went well and how problems were solved.
Also after a Sprint, the Sprint Retrospective takes place. During the previous Sprint, Retros provide a dedicated forum for the team to analyze their process and make adaptations as needed.
Artifacts are only tangible documents containing details of the project. Product backlog, sprint backlog, and product increments are included in Scrum artifacts.
The Product Backlog is a complete, ordered list of all product requirements and serves as the sole reference for any required product modifications. The owner/leader of the company manages the inventory of the product, including how it is made available to the group, the content, and how it is ordered.
The Product Owner and the rest of the team work together to update the Product Backlog and, if necessary, make adjustments as brand specifications evolve and change.
The Sprint Backlog is a list of all things to be worked on during a Sprint from the Service Backlog. The list is collected by prioritizing the Product Backlog items until the team feels they have exceeded their Sprint ability. Through the self-organizing Scrum framework, if you are a team member you can sign up in the Sprint Backlog for tasks based on priorities and skills.
A Material Increment is nothing but the amount of the work done during a Sprint, combined with all the work done during previous Sprints. A Sprint’s goal is to create a Finished Product Increment.
It is up to the Scrum team to agree on what defines the “Done” status of an Increment, but the definition must be agreed and understood by all team members.
Do you have a headache from all these terms? Don’t be afraid. The essence is this: Scrum is a method used by teams to work together. The jargon quickly becomes second nature once you use it, and whenever you get confused, you can refer back to this cheat sheet or get in touch to learn more.