Our way of working is constantly changing. You’ve certainly observed it as well regardless of your profession or sector. Projects are becoming more and more complicated and for the best results, it’s crucial to properly manage the project. Scrum is one of the Agile frameworks and it’s most frequently used by software development teams. Thanks to it, the product development process can have more realistic planning, clear objectives, and reduced costs. In this article, you’ll learn:
- What is Scrum methodology?
- How was the Scrum framework created?
- What does the Scrum development process look like?
What is Scrum?
Scrum is a project management methodology created mostly by Jeff Sutherland and Ken Schwaber. It’s a framework of agile software development methodology. In the beginning, Scrum was mostly popular in the software development industry (where it was created) but with time more companies across many industries started to use it.
It was created to replace the Waterfall method that had the disadvantage of being a slow process and the final effect was usually far from the intended. However, Scrum is based on iterative work, i.e. composed of cycles (sprints), thanks to which through planning and daily meetings you can control if it’s going in the right direction. Thanks to the iterative form and starting over, the team works not only on continuous improvement of the product but also on improving themselves – how they work, communicate or solve problems daily.
Scrum consists of many elements:
- sprint planning,
- scrum poker,
- daily stand up,
- retro meeting.
At this moment these terms might sound strange to you but later in this article, I will explain what they mean and what their role is in project management. Of course, there are more components but these are the basics to start your Scrum adventure with.
How was Scrum created?
Necessity is the mother of invention.
Initially, software was developed using the cascade method, otherwise known as Waterfall. Following Waterfall, a software development project was divided into stages. By closing one stage, the team could move on to the next, and so on until the end of the project. The problem was that carefully prepared Gantt charts looked very nice only on the paper. When the team started to execute it, the actual values were nowhere near those contained in the beautifully drawn bars and written project objectives. Many delays, budget overruns, and a slow process are just some of the reasons why most companies moved away from the cascade method.
The software market needed more adaptive solutions like the Scrum framework that would work better in a highly dynamic environment. After some time, Scrum started to be used in other businesses as well.
What does the Scrum process look like?
The best way to start is to get the Scrum team together and do the intro. Explain to everyone why you decided to make such a change, what Scrum is and how the work will look like from now on.
Break down the workflow into individual stages that correspond to your work cycle. For example, at Applover we work using Jira so the stage is presented as a column, and one of the more typical board’s layouts is:
- TO DO
- IN PROGRESS
- CODE REVIEW
You can create a backlog which is nothing but a collection of all the work that needs to be done. Depending on the project and the stage it is at, there will be all user stories, tasks, and bugs. While being in the backlog, they are waiting to be added to the sprint so the team can start working on them. You could say backlog items are something like a waiting list.
Sprint in Scrum
Once the backlog has grown significantly and is filled to the top, it’s time to launch the first Sprint. A Sprint is a time during which the team delivers – or plans to deliver 😉 – a planned part of the application or feature. Such a part or feature is represented by a user story, i.e. stories that describe what the user can do thanks to the given functionality.
By the book, the functionality delivered at the end of the sprint should be handed over to the customer ready to use. In other words, no user story has the right to receive the DONE status until the customer can reproduce and execute the story. Such a process in which the team delivers small parts with high-frequency increases performance allows for more frequent feedback and provides continuous value delivered to the customer. As for the duration of a sprint – it can last up to one month, while the most common duration is one or two weeks.
Before you announce the start, you first need to plan this sprint. To do so, you need to run Sprint Planning. As the name suggests, it’s a meeting where the entire upcoming sprint is planned. At Applover, we conduct sprint planning using planning poker and we base the estimations on story points.
If this is your first time encountering these terms, I’m coming with an explanation. Planning Poker, sometimes also called Scrum Poker, is a method of sprint planning using cards. It can be done in the office as a game or as a remote version. It’s a great way to estimate the workload in isolation from hourly values. Additionally, the poker approach eliminates the halo effect that very often distorts the estimates of planning, and in the case of very different values team members can confront their approach to the task and exchange knowledge. Perhaps someone overlooked a potential risk or in another scenario didn’t take into account reusable components that will make the work much easier.
Story Point, on the other hand, is an abstract value representing the amount of work to complete an issue. At Applover, we work with Story Points based on the Fibonacci Sequence. But you can also use many others. You’ll find them at PlanITPoker – the tool I use for remote Poker Planning.
Daily Stand Up
Let’s say you’ve managed to move User Stories from backlog to sprint, you’ve estimated the required workload and you’ve launched the sprint. Will everyone go their separate ways and the whole team will see each other in a week, two weeks, or maybe a month? No! To maintain a smooth flow of information, simplify communication, and resolve blockers as quickly as possible, you will meet daily at a meeting called Daily Stand Up. At this meeting, progress is discussed and blockers that are holding the team back are addressed. The name “daily stand up” comes from the standing mode of the meeting – there is no time to sit around. It has to be quick and focused, 15 minutes is the maximum time that can be spent on it.
Retro meeting in Scrum
When you are coming to the end of your first Sprint or any other Sprint, it is a good idea to slow down a bit and look at the process from the other side. This is the purpose of Retrospectives or Retro for short. The goal is to analyze the work done so far and how the development is going. It can be about the current or previous sprint. The output of such a meeting should be a plan consisting of three points:
- what can be improved in our work to improve performance,
- what should be stopped and what mistakes the team should eliminate in the future,
- what practices the team should continue because of their good impact on development.
Around the end of a sprint, you can also do Backlog Refinement, which is simply preparing issues that are on top of the backlog and will soon go into a sprint.
Do you want to find out more about Scrum software development?
Keep your Scrum teams on track
If you were able to complete all of the above steps, congratulations on your first completed sprint. Now you have to start all over again! I hope you had at least a great time and are looking through your scrum board with a smile on your face!
This iterative cycle is a tried-and-true strategy for increasing software agility. The project’s momentum is maintained and right after the project finishes, the Scrum framework assures that the most important work has been finished. Based on our years of expertise, it’s always great to increment your project management cycle. Feel free to get in touch with Applover, whenever you want top tech experts specialized in Scrum methodology.