Scrum made easy: with the online scrum board and our tools, you will make your scrum planning, review, daily and retrospective more fun and faster. The product owner, scrum master and the team will love it!
Scrum: tool for your team
Scrum: What is it and why does it work?
If you're dealing with software and web development activity on a daily basis, you will most likely have heard about Scrum and you might even have been part of a Scrum-based project. Even if you don't work in digital development though, you might have heard terms like Scrum, Scrum master, and Scrum Sprints, simply because Scrum has become so popular over the past decades. And not just in software development, which is the sector in which Scrum has originated, but more and more in other sectors as well, like research work and advanced technologies. In any case, Scrum is basically an agile framework for the management of complex knowledge-based projects. This maybe sounds a bit abstract still, but don't worry, because in this article, we're going to dive a bit deeper into the introduction of Scrum and what it's all exactly about. We'll be taking a look at what Scrum is, why it's called an agile framework, and what a typical Scrum-project consists of.
What is scrum exactly?
Simply said, Scrum is a framework that helps people and teams to work together. The term scrum actually comes from the word scrummage, which is a common term in rugby. In that context, a scrum refers to a method of restarting play in which all of the players of one team huddle together with their heads down in an attempt to gain possession of the ball. It basically refers to the members of one team coming together, taking notice of their current collective situation, and devising the best way to reach their goal (i.e. win the game) together. Scrum methodology in software (and product) development isn't so different from the meaning of the original term.
The Scrum framework consists of several elements that are all aimed at helping teams to structure and manage projects of varying complexities, including tools, roles, and meetings. The ideal representation of Scrum is a team that, with the help of the correct application of the framework, continuously learns and improves through experiences. The framework itself is based on the notion that, at the start of a project, the involved team rarely ever has all the necessary and available information and that the team will evolve from the phase through experience. That's why it also helps teams to adapt to changing circumstances and to re-prioritise constantly. The short release cycles we will discuss later on play an important role in this sense.
Its strong and defined structure do not mean that Scrum is necessarily rigid as a framework. On the contrary, while the approach to a project is often similar, the framework can be adapted to practically any type of project. As for any successful project, communication and transparency amongst the involved team members and parties are key, as is a team-wide dedication to the Scrum-method. In order to optimally benefit from the Scrum framework, it's important that all of the people involved are dedicated to respecting the sometimes strict structure of Scrum.
Is Scrum the same as agile?
If you have ever heard of Scrum, chances are you've heard the term agile as well. That's not because both are kinds of frameworks for optimised project management, but because both terms are linked to the same concept of continuous learning and improvement. The big difference is that Scrum is a framework, a structure in which a project can be placed to optimise its management, while agile is a mindset, a way of approaching work overall, not just a single project.
An agile way of working refers to the way in which a company is or plans to deliver vale to its customers. Simply said, the goal of an agile approach is to deliver value quicker and with less headaches. The concept revolves around the delivery of smaller milestones of a project on a constant basis, instead of making a big splash with a single delivery at launch. In other words, it's about cutting up complex projects into smaller pieces that are easier to oversee and evaluate, while constant re-prioritisation and evaluation should result in a less costly, more adapted project as the end result.
An inevitable element of the agile approach is the involvement of cross-functional teams in which knowledge, skills, and data are shared, instead of an environment in which each of the company's departments contribute to a project one by one. Collaboration, adaptation, open communication, and trust play key roles in the organisation of an agile project. Agile isn't so much a set of specific events or techniques as it is a collection of methodologies that focus on commitment to tight feedback cycles and continuous improvement.
Essential elements of scrum
Essential elements of Scrum: 3 artefacts
One of the basic elements of Scrum is the artefact. As a matter of fact, there are three artefacts that are always present in every Scrum team, namely a Product Backlog, a Sprint Backlog, and a type of backlog that defines a “finished” part for you. An artefact in a Scrum environment is a type of tool that teams can use to solve complex problems together. Teams create them themselves and below we'll be taking a quick look at the role and importance of each artefact.
The Product Backlog
The first artefact we're considering is the Product Backlog, which is basically the master list of tasks that need to be taken care of. In the light of a software project specifically, for example, this list would consist of features, enhancements, requirements, and bug fixes. Simply put, it's the team's “To-do”-list, and it's constantly managed and updated by the team's Product Owner, whose role we will discuss in more detail in “Essential elements of Scrum: roles”. The Product Backlog forms the basis of what's put into the Sprint Backlog, which is the next artefact we'll deal with in a bit.
The Sprint Backlog
In Scrum methodology, a sprint is one of the many short development cycles in which a project gets divided. The Sprint Backlog therefore is the list of items that have been taken off the Product Backlog by the development team and placed into the current sprint cycle, i.e. the development cycle. This can range from the development of new functionalities and the upgrading of the UI to big fixes and testing. What to work on during each sprint cycle is decided in so-called sprint planning meetings, which form a core element of the Scrum method and which we'll go into deeper when talking about events in Scrum. When creating the Sprint Backlog, it's important to know that the cycle itself can be flexible in terms of approach and execution, but that the fundamental sprint goal set by the team before starting the sprint cycle can not be compromised. This would ruin the point of working with the mentioned backlogs and creating sprint cycles.
There is no fixed name for the third artefact in Scrum, so you can call it whatever you want. What it should refer to is parts of the project that have come out of the Sprint Backlog and are ready for use. Naturally, not every team works with the same definitions of “done” or “finished”, so it's very important for all of the involved team members to be on the same page when it comes to qualifying a spring cycle as done or finished. Some teams might consider a sprint done when the result has been shared with the client, while other teams might only share their work with the client every quarter of the year, meaning that a “finished sprint” for them could mean the end of the testing phase for a new functionality or the internal delivery of a small piece of software that will be part of the project that will be delivered to the client in the further future. The important thing here is that the team has a way of marking their progress and keeping the workflow going, from the creation of a task in the Product Backlog to the arrival at the end of the pipeline (the third artefact).
Essential elements to plan scrum
Essential elements of Scrum: events
Previously, we already mentioned the importance of sprints and how they require sprint planning meetings to keep the project advancing. Such meetings are just one of the several important type of events that take place during a Scrum-based project. These events are also called ceremonies or events, and they are the elements where teams can insert the most variation. Some teams will find it harder to adhere to a strict and sometimes repetitive system of events and meetings, while it will help other teams immensely in getting and staying aligned for the duration of the project. What's important to know, is that not every team necessarily needs to hold every meeting or ceremony possible per sprint cycle. What we will do, is write down and explain a few of the most common Scrum events, so as to give you a better idea of what is exactly meant with an event and why they are of such importance to the successful management of a Scrum-based project.
The organisation, maintenance, and management of the backlogs is usually a principal responsibility of the project's Product Owner, the person with the vision for the project who knows where he wants the backlogs to take the team. The Product Backlog forms the backbone of every Scrum project, so it's very important that this list is kept clear and organised. Based on feedback from the involved parties, from developers and team members to investors and customers, the Product Owner makes sure that everyone can work with the Product Backlog and understand it easily. In order to do so, frequent meetings to organise the backlog, which do not necessarily need to be long, are necessary.
Sprint planning meetings
We mentioned sprint planning meetings briefly earlier, when explaining about sprint and sprint cycles. If a sprint represents one of the short development cycles in which a project gets divided, then a sprint planning meeting is the moment when the content and goals for that sprint are determined beforehand. The Scrum master (another role we will explain in more detail later on) leads these meetings and the whole development team usually attends. Together, they set a goal for the upcoming sprint and decide on which items from the Product Backlog should be included. At the end of a sprint planning meeting, which again does not necessarily needs to be very long, each Scrum member should know what the goal for the sprint cycle is and what their role in achieving this goal in time is going to be.
One of the most important types of events in a Scrum project is the sprint itself. A sprint is actually nothing more and nothing less than the time a Scrum team spends together to finish a part of the project in question. If you read about Scrum in other sources and listen to specialists talking about the methodology, you'll quickly notice that two weeks is a typical length for a sprint cycle, but teams are free to determine the duration of a sprint as they prefer. Depending on the project, it might be more convenient to create sprint cycles of a week or a month. Whatever period of time is chosen to define a sprint though, it's crucial that the team sticks to this length for the rest of the project. This way, the team can get used to working in a certain structure, and apply their knowledge and experience to future sprints.
The Daily Scrums
These are generally very short meetings that take place at the same time of the day, every day and usually in the mornings, though this becomes more complex when working with team members in different time zones. A Daily Scrum basically serves to get everyone aligned again with the sprint goal and to go over the planning for the next working day. This gives team members the chance to briefly indicate any potential problems they are having or any worries they might have about achieving the sprint goal within the set period of time. A way to quickly and efficiently conduct a Daily Scrum is to have every team member briefly state what he or she did yesterday, what he or she is doing today, and whether he or she is seeing any obstacles towards reaching the sprint goal.
Sprint reviews are usually quite informal sessions during which the end results of a finalised sprint are demonstrated or showcased. This is when the contents of the third artefact, which we called Finished Sprints, are evaluated and taken off the backlog, so that the Product Owner can rework the Product Backlog accordingly. Ideally, a sprint review already forms the very first step of creating the next upcoming sprint.
A sprint retrospective is similar to a sprint review in that the team looks back on their work, but in the case of a retrospective, the focus is more on efficiency of the last sprint itself. Where a review looks at the end result in terms of the product, a retrospective asks from all parties involved in the sprint to document and discuss the things that went well and those that didn't during the last sprint. This can be about the project itself, but also about internal relationships, the tools that were used, or the way in which the sprint was approached, for example. The goal of sprint retrospectives is for team members to learn from each other and for the project as a whole to improve.