Scrum has been and still is one of the most popular Agile frameworks on the market. Created to help teams manage their work and deliver value in a changing environment, it is still as useful today as it was when first presented in 1995. With clear processes and events Scrum works great for both new and experienced users. Thus is often chosen by teams that are just starting out in the Agile world.
Curiuos to know how it works? Keep on reading.
What is Scrum?
Scrum was first formally introduced in the 1995 OOPSLA conference by Ken Schwaber and Jeff Sutherland. Credited as creators of Scrum, they see themselves more like the parents of Scrum. As the framework has been worked on and improved by many others since then.
As they say in this Scrum Guide update, the need for such a framework became evident as waterfall projects were constantly late and anything the managers did made them even later. Looking for a better way to deliver results, Jeff started working with smaller teams and organizing work around iterations.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
It soon became clear that to improve previous project management practices, teams needed transparency, focus, commitment and a will to change and adapt. This also meant taking responsibility if something went wrong, which in waterfall was easily transferred to someone else. Thus never getting to the bottom of the problem. Ken and Jeff even joke that waterfall was created in a way so that no one would ever get the blame and everybody could keep their jobs.
The name of Scrum came about as the parallel was drawn between small closely working teams and the scrummage from Rugby. And to keep the core ideas of Scrum clear, Ken and Jeff have released a Scrum Guide outlining the main ideas and practices.
The Core Idea
The essence of Scrum is quite different from the waterfall methodology. It is all about a single team looking at a problem and finding a way to turn it into something useful. Working within a close group of people it becomes easier to communicate, while short iterations let check the effectiveness of each solution fast. This way of operations require transparency and accountability, while the team works as one unit with a single goal.
The best Scrum application examples come from environments, where no matter the company size, people still work in small autonomous teams. Scrum scales nicely and can facilitate the work between teams and networks of teams. However, in such cases you have to be prepared for lower productivity.
In the time where everything changes fast, Scrum offers a way of testing out ideas without great losses. As circumstances change, teams include that in their Sprint planning and usually after a few iterations can already test out the new improved product. Thus giving quick feedback and allowing to easily decide whether to continue in a particular direction.
Scrum explained shortly
Scrum works by having small teams complete work in small iterations. Work is planned, completed and reviewed in 1-4 week increments, making it easy to react and adapt to any changes happening inside or outside the company. To make sure everyone knows what to do, certain rules and practices have to be followed. Here is a short glossary.
The Scrum Team
It all starts with a team and in Scrum they are designed to be self-organizing and cross-functional. Meaning they can choose on how to best accomplish their work and that they have all the competencies to deliver a result. Three specific roles are defined to ensure this process- Product Owner, Scrum Team and Scrum Master.
The Product Owner is the sole person on the Scrum team responsible for setting the project direction and maximizing the value of the end product. To make sure this happens, only he or she can manage the Product Backlog, thus deciding what the team will work on next. To make the work go smoothly, the Backlog items have to be clear, prioritized and ready to be completed by the team.
It is important to understand the Product Owner is not in charge of the team, but in charge of the product. Their goal is not to control work, but to set the vision and relay customer expectations to the team so they could be fulfilled.
The Scrum Team
The mission of a Scrum Team is to deliver value. It is this group that creates the final product or service for the client. Being a cross-functional and self-organizing team of people, they plan and complete iterations autonomously, while taking direction from the Product Backlog. Product Owner and Scrum Master are usually not counted as a part of the team, unless they also work on delivering value.
In general, the Scrum team is kept small. It only has to be big enough to deliver significant work increments within a Sprint. Having a team that is under 3 people, decreases interaction and can have issues due to skill constraints. While having a team that is too large generates too much complexity for the process. Thus larger teams should be divided into several smaller ones.
The Scrum masters’ role is to facilitate the Scrum process. Making sure the team and all the stakeholders understand the process, values and theory. It is the Scrum Master that facilitates transition into Scrum and then keeps on working to improve the processes and guides conversations between PO, the team and the stakeholders.
It is also not unusual to have outside consultants as Scrum Masters. As the Scrum knowledge level required for this role is quite high.
Scrum defines 5 specific events that have to be held by the team. This is done to create regularity and eliminate the need for any additional meetings. Sprint is the largest event of the five and fits all the smaller events within itself. It is also the only event that cannot be cut short once it has begun. Other Scrum events are also time-boxed, but the teams can choose to make them shorter if they want to.
All of the Scrum events are created as opportunities to inspect and adapt to the changing circumstances.
The heart of Scrum is a time defined (1-4 weeks) work iteration called Sprint. A time during which the Scrum team plans, works and creates a potentially releasable product increment. It is during each Sprint, that the other 4 Scrum events are held and as one Sprint ends another one begins immediately.
The duration of the Sprint is set at the beginning of the project and usually does not differ from Sprint to Sprint. Also, once a Sprint has begun, it has to be finished in accordance to the set goals and time frame. Only the Product Owner has the power to cancel a Sprint and this is only done if the Sprint goal becomes obsolete due to outside circumstances. A new goal is then set and a Sprint is re-planned. However, due to short iterations this is rarely necessary.
At the beginning of each Sprint, the Sprint Planning is held. It is a time boxed 8 hour event. Here the team and the Product Owner discuss what is the goal for the coming Sprint. They also decide which product backlog items will help achieve this goal. It is solely the team that then decides how many product backlog items they will be taking on. It is also up to the team to come up with a way to deliver the Sprint goal during the time of the Sprint.
A Sprint backlog is created where all tasks needed to fulfill user stories are held. They can be prioritized and estimations can be added by the team to better understand the scope. Product Owner does not participate in the choosing and defining of the Sprint Backlog items, but simply tells what should be achieved.
The third event is the Daily Scrum. As it is clear from the name, it is a daily 15 minute meeting for the Scrum team. Here the team reflects and plans the next 24 hours of work.
Each of the team members take approximately a minute to tell the team what they have done yesterday, what they will do today and how all of this is helping the team to reach the Sprint goal. the team members are also encouraged to voice any issues they see. Especially ones they see interfering with the Sprint goal. Usually these issues are addressed after the Daily Scrum. As the team needs to gather and possibly take a new course of action to be successfull.
Once the Sprint is over, the Scrum team, Product Owner and stakeholders hold a Sprint Review. During this meeting all the attendees discuss what was accomplished during the Sprint. According to the information and changes made to the backlog, they also decide what has to be done next to optimize value.
This meeting is geared to gather feedback and foster collaboration between the team, PO and the stakeholders. The time box for this meeting is 4 hours for a 4 week Sprint.
After the Sprint Review, the team holds one final meeting – the Sprint Retrospective. Contrary to Sprint review, this is a chance for the team to evaluate not what they have accomplished, but how they accomplished it. Team members discuss which practices have and have not worked during the Sprint and how the team can improve them in the next Sprint.
Sprint Retrospective is facilitated by the Scrum Master and is time boxed to 3 hours. It is a formal opportunity to inspect and find ways to improve the process in order to deliver better results in the next Sprint.
To easily keep track of the process, Scrum uses a visual board that stores all of the project tasks. This board is usually comprised out of several sections – Product Backlog, Sprint Backlog, Doing and Done. Below is an example Scrum board designed in Teamhood. To help prioritize important user stories, it has an additional ‘High Priority’ column in the Product Backlog section.
Product Backlog is managed by the Product Owner and holds large tasks in the form of Epics and user stories that define the customer wishes for the end product. It is the Product Owner’s responsibility to gather and prioritize items in the Product Backlog.
Sprint Backlog is managed by the Scrum team and holds all the tasks that the team has planned for the current Sprint. It is just the Scrum team that manages Sprint Backlog.
Doing and Done columns are also managed by the Scrum team and represent the progress of what has been done. Team members move tasks from Sprint Backlog into Doing after they start working on them. And then into Done as they are finished with a task.
Using these roles, meetings and artifacts, each Scrum team aims to create a process where it is easy to adapt and deliver value. If you are still a little unsure how all of them fit together, here is a short video.
And for those of you that are already practicing Scrum on the daily basis, we have prepared a cheat sheet. Grab it and keep it handy when you are just a little lost on what some term or process looks like.
While Scrum is one of the more defined Agile applications, there are still some misconceptions when it comes to using it. The parents of Scrum Ken Schwaber and Jeff Sutherland outline the following 6 as being the most common ones they have encountered.
1. Scrum Master is in charge
While the word ‘master’ sure sounds grand, the Scrum Master is not there to give orders. The role of the Scrum Master is all about binding people and helping them work together in the Scrum way. They have to facilitate the Scrum process in changing people’s perception, adapting the company culture and then helping to fulfill the daily Scrum operations.
Scrum master is not in charge of anything, but making sure the Scrum process works
2. Daily Meetings are just about checking in
While it may seem just like a check-in on the surface, Daily Scrum is actually a way for the team to meet and discuss further course of action. To better understand its purpose we could look at this meeting like a football huddle. Where the team gathers, tries to figure out why the quarterback got injured and what is the best course of action to win the game.
Daily Scrum is there to replan and shift focus according to the changed circumstances. While making sure the Sprint Goal is being met. Some teams even shift focus of this meeting from reporting of the progress onto the Sprint Backlog. As they take the most important task there and discuss what they can do to make sure it is completed today. Thus focusing on the goal what can be done to reach it.
Daily meetings are not about reporting, but about finding a better way to do things today
3. The meetings should take the whole time they are given.
Scrum defines a time box for each meeting. It says what is the maximum amount of time that each meeting should take. However, what most teems fail to understand is that this is just the maximum time, not the required time.
In fact, more advanced teams usually take a lot less time to complete the events. As they already have an established process and work more efficiently. Scrum is designed to deliver more value in less time and the events are no different.
Time Boxes are there to guide your meetings, not requirements to be met exactly
4. It is enough to only discuss changes during Sprint Retrospectives
Sprint Retrospectives are designed as a place to discuss and improve the way teams complete work during the next Sprint. However, as most teams perform this event, many forget to actually implement the solutions.
It should be a rule of thumb for the team to include at least one discussed solution in the next Sprint and, if possible, more. Thus making sure continuous improvement is made not only to the product, but to the process as well.
It is not enough to discuss, but is also important to implement changes on a regular basis
5. Scrum is just for software developers
While it has started out as a framework for software development, Scrum has proven to be adaptable in many other fields since. Product development, service providers, automotive industries and even government offices are using Scrum to be more adaptable and responsive to change.
Scrum is created for any company that wants to be able to react and adopt to the changing market
6. You have to release after each Sprint
The idea of working in Sprints is to have something of value created after each short work cycle. However, this does not mean you have to necessarily release or ship a product to your customers after every Sprint.
Slower teams may take several Sprints to release a product and faster teams could release several times during one Sprint. As long as you have finished an addition of value after each Sprint you do not have to worry about aligning your releases and Sprints.
At the end of each Sprint you have to deliver additional value, not necessarily a full release
Scrum is a great choice for teams that want to move fast and react to the changing environment. Planning, completing and reviewing the work in short iterations allows to quickly test out new ideas and deliver a final result that is done in accordance to the customer feedback. Scrum was created for small collocated teams, but has since proven to be a great candidate for scaling. Great for Agile beginners it may very well be your intro into Agile.