Scrum Methodology: An Agile Way of Managing Projects

Image Source: jordanjob.me/blog/scrum-diagram/

While some might consider Scrum a unique methodology, it is more of a framework for managing processes. Scrum is mainly based on timework iterations, otherwise known as sprints. Moreover, each sprint can be between two weeks and thirty days long. Because of that, teams can easily track progress and re-evaluate plans in fifteen-minute daily meetings also known as daily Scrums. 

This approach appeared in the nineties, and the term “scrum” comes from rugby. Hirotaka Takeuchi and Ikujiro Nonaka used it in their Harvard Business Review paper “The New New Product Development Game.” The idea behind it was to emphasize the importance of teams in convoluted product development. 

Even though Scrum has its focus on software development, it is not rare for people to use it in other fields too.

Scrum can challenge the more traditional approaches to development by enabling the collocation of all team members and communication between them. Scrum is based on the realization that the client can change their idea at any point and that there will be unpredictable challenges along the way.

In contrast to some other methodologies like the Waterfall, Scrum understands that problems can’t be fully defined upfront and focuses on increasing the team’s ability to deliver, respond, and adapt. 

The Scrum Process — Events

Here, we will take a look at the Scrum process and what stages are involved in it. 

Sprint

The first and most elemental unit of the Scrum process is a sprint, otherwise known as iteration or timebox. In essence, it works as a timeboxed effort, where the length is previously fixed and agreed, and it is usually between one and four weeks. Most commonly, a sprint is two weeks long. 

Before the beginning of each sprint, the team will have a planning event to establish their goals and required product backlog items. During this phase, the team will see what is ready and move it into a sprint backlog. Furthermore, they will discuss a breakdown of the work and create a forecast for the goal. 

After the end of each sprint, the team will have a sprint retrospective and review. That way, the team can easily follow their progress and plan improvements for the following phase. 

Sprint Planning

As previously mentioned, before each sprint starts, the Scrum team will host a planning event. 

During this stage, the team will discuss the scope of work they are planning to complete in the upcoming period. Moreover, they will choose items from the product backlog that they intend to complete during one sprint. After that, they will go over the work essential for completing the backlog items. Then, they will agree on the goal and create an outline of the forecast for the end of the sprint. 

Many recommend that the duration of the review should not exceed four hours for a four-week sprint. For lengthier sprints, time is calculated pro-rata. During the first half, the team will select backlog items they plan on finishing during the sprint. The second half is for identifying the tasks they need to complete to achieve that.

It is not rare for some backlog items to be split and returned to the backlog if the team doubts the possibility of finishing that work in a single sprint. 

Daily Scrum

The team will hold daily meetings during the sprint. For these daily events or stand-ups, there are several guidelines that teams should follow. 

For example, each daily Scrum should start at the same time, at the same place. While anyone can attend the event, only members of the development team should contribute. Daily Scrums should begin promptly, even if some of the team members are not present. Also, the meetings are limited to fifteen minutes. 

It is common practice for each team member to answer three main questions. That is, explain what they did the day before, what their plans are for the present day, and if they see any impediments that can stop them from reaching the goal.

If some potential risk or problem is identified, the Scrum Master should display it on the board. The team will then agree on the individual that will be in charge of resolving the matter. 

The team should not discuss any topic in detail during the meeting. However, after the event is over, they can get together and talk about any potential issues in detail. These are also known as “after parties” or “breakout sessions.”

Sprint Review

There are two main events at the end of each sprint — review and retrospective. During the review, the team will go over the work they finished in the past sprint, as well as potential work that remained undone. 

Furthermore, they will present completed, or work in progress, to the stakeholders on the demonstration and discuss future projects.

Incomplete work is never a part of the sprint review, and it usually lasts for 120 minutes for a two-week sprint. Naturally, if the sprint is longer, the length will increase proportionally. 

Sprint Retrospective

Similarly to the review, the team will reflect on the previous sprint and identify the actions needed for continuous process improvement. Three main questions that the team should answer are: 

• What went well during the last sprint?
• What did not go well?
• How can the team improve productivity in the upcoming sprint? 

Scrum Master facilitates retrospective, and the event should last for an hour and a half for standard two-week sprints. 

Scrum Artifacts

Two so-called Scrum artifacts are essential for the proper implementation of the framework — product and sprint backlogs. 

Product Backlog

The product backlog is, in essence, a breakdown of everything that needs to be completed. The product owner is responsible for everything regarding product backlogging, including content, ordering, and availability.

Based on factors such as risk, dependencies, business value, date, size, and others, the product owner will prioritize product backlog items or PBIs. Furthermore, backlogging often includes bug fixes, features, non-functioning elements, or whatever else the team might need to deliver the finished, viable product. 

Moreover, the product backlog also contains business value and development effort assessment. Teams often opt for using a Fibonacci sequence when assessing task difficulty. Tasks marked with 1, 2, or 3 story points require low effort and can be considered trivial. While those marked with numbers higher up on the scale (e.g., 8 or 13) can have a significant impact on the budget and delivery.

Using this method helps the product owner manage timelines and switch priorities if several features share the same business value. That way, they can schedule earlier delivery for the ones with either lower or higher development efforts. Lower development effort will result in a high return on investment, while higher effort development is riskier and more complex, which might motivate them to retire earlier. 

If the product owner opts for the Fibonacci, story-point method, the delivery of each item is estimated based on difficulty. Furthermore, story points are used to timebox effort, which means that it will remain constant over time. 

The main advantage of story points is that the team can compare them to points assigned in earlier sprints and reuse them. However, it is worth mentioning that estimates are subjective and can differ from team to team, based on their skills and efficiency. 

Sprint Backlog

While a product backlog covers the entire work that needs to be done, a sprint backlog focuses on work during a single sprint. The list of the upcoming tasks is designed by a Scrum team based on priority. The team will pick as much work as they need to feel the entire sprint. 

Naturally, the development team will consider previous sprints so that they can accurately determine the amount of work for the upcoming period. 

It is also possible for the development team to separate product backlogs into tasks. One of the policies of this method is never to assign tasks to teams or team members. Instead, team members will sign-up for tasks based on their skills, availability, and task priority. 

The entire spring backlog is the property of the development team, and all estimates are provided by it. Teams will often create a Scrum task board where they will mark work as “in progress,” “to do,” or “done.”

Once they have committed to the sprint backlog, they cannot add more tasks or change it in any way — only the development team can.

Becoming Familiar with Scrum Roles

When it comes to roles, there are three main types in the Scrum methodology — the product owner, the development team, and the Scrum Master. 

The Product Owner

The main role of the product owner is to maximize the value of the work or product arriving  from the development team. Moreover, they represent the stakeholder and act as the voice of the customer. Their goal is to ensure good business results. 

As we mentioned earlier, the product owner is in charge of the product backlog, and they will prioritize it based on dependencies and importance. Usually, a Scrum team will have a single product owner, and they should appoint someone other than the Scrum Master. 

The core responsibilities of the product owner are:

• Precisely defining items in the product backlog;
• Ordering needed items to ensure that the team will achieve goals;
• Optimizing the value of work, and negotiate priorities, funding, etc.;
• Ensuring that the product backlog is transparent, understandable, and visible to everyone;
• Ensuring that the development team has an understanding of the items in the product backlog;
• Communicating team status and delivery;
• Sharing progress during meetings and with stakeholders.

One of the main responsibilities of the product owner is communication and making sure that the project is moving in the desired direction.

The Development Team

For teams wanting to apply the Scrum framework, the ideal number of members is between three and nine. Scrum teams rarely have more than ten participants. However, anyone who contributes to project development and support is technically a part of the development team.

Among the main characteristics of this team is that it’s “self-governing.” Most work for the team will come from the product owner, and the Scrum Master will protect them from any potential distraction. However, since the team is self-organizing, they are allowed to communicate with the customer directly.

That way, the team will be able to get both accurate feedback and a better understanding of the project.

The Scrum Master

A good Scrum Master is a so-called servant-leader, and their chief quality is leadership. Their goal is to serve the team while leading them and remove any obstacle in the development process. 

Since Scrum Masters are neither team leaders nor project managers, they will act more as a buffer between the team and any potential distraction. Their goal is to ensure that the team follows a predetermined framework. 

The responsibilities of the team’s Scrum Master are:

• Being a coach to the team, focusing on the Scrum principles and values;
• Assisting the product owner in the maintenance of the product backlog and making sure that everyone understands what they need to do; 
• Advocating self-organization;
• Guiding the team to ensure they avoid or overcome any impediment;
• Organizing team events to ensure progress;
• Promoting Agile and Scrum principles to stakeholders.

Great Scrum Masters are usually extroverts and have formidable leadership skills. However, they do not act with authority, but rather with compassion and understanding.

Scrum Core Values

Both the Scrum team and all the individuals that make it possess five core values.

• Courage — Each team member understands that they possess the courage to overcome any obstacle, conflict, or challenge, and do the right thing.
• Focus — Every individual in the team will focus on the sprint backlog and team goals, as well as do their part to ensure maximum efficiency. They will do no additional work outside the backlog.
• Commitment — Members of the team will personally commit to achieving team goals, and they will do their best each sprint. 
• Respect — Scrum team members respect each other, and they see their teammates as competent, capable, and reliable. They will all work with good intent. 
• Openness — Both team members and stakeholders are transparent about work and challenges they might face

The Advantages of the Scrum Methodology

With this sprint-focused model, the workflow focuses on communication and management. For the duration of a sprint, the team can dissect their goals step-by-step. Moreover, the incremental delivery can shorten the time to market and can result in higher revenue. 

Since each sprint is reviewed before proceeding to the next, it means that the team will conduct testing throughout the whole process. The team can change its focus, improve, and adapt along the way. 

With Scrum, the team does the work simultaneously instead of sequentially. The development team works “on the go,” and everything is perfectly clear before the project even starts. 

Furthermore, each task is prioritized by importance, which means that the finished ones can have a significant impact on the return of the investment. 

Because there is no team leader, the developers can feel more in touch with the project, and feel more responsible and invested. 

The Disadvantages of Scrum

The most apparent problem is that the Scrum Master might have a difficult time organizing everything and making sure that every piece of the puzzle is in line. As a result, the project can often lack definition and structure. 

While frequent changes are welcome, they can sometimes prove to be too challenging to follow, and the whole process can become rather intense. 

Besides, daily meetings require resources, and the whole process requires each and every individual to maintain a high level of dedication, maturity, and communication. 

Lack of expertise can also be a problem since the team requires both commitment and a high level of experience. A Scrum Master without sufficient skills can ruin the entire project. Without clear and understandable goals and tasks, the project can lead to deal-breaking inaccuracies.