Success stories

What Is Scrum? Why Do I Keep Hearing About It?

by: Shiv Sharma
What Is Scrum? Why Do I Keep Hearing About It?

If you’re a software developer, this article isn’t for you. You probably already know about Scrum and have plenty of resources to learn more about it online. 

But if you are from a non-IT background and are curious about Scrum, you’ve landed at the right place. Most articles about Scrum are intended for developers and saturated with IT terminology. They can be overwhelming. 

But Scrum isn’t intimidating at all. In fact, it’s so popular because it can be useful for all kinds of teams. 

You might have heard of Scrum together with Agile. It’s because to understand Scrum you need to know what Agile is. 

Traditionally, project management in IT was similar to other forms of engineering. There was extensive planning before working on a feature. Similar to “the more you sweat in practice, the less you bleed in war.” mantra, it was believed that the more time you spend on planning, the less time you need to spend on coding. It seemed like a reasonable philosophy.  After all, almost all other forms of engineering had relied on it.

However, software development is a lot more dynamic because it’s business requirements change rapidly. If you spend too much time on planning, the customer requirements might change completely by the time you’re finished. Software engineers realized that they needed a radical change in the way they develop software. Hence, the Agile philosophy was born. 

Agile isn’t a rigid process. It’s a philosophy.  It’s the mindset of satisfying your customers by optimizing your process for their changing requirements. Gradually non-IT teams also realized the importance of having a project management process that can adapt quickly to changing customer requirements. Agile spread like wildfire in all kinds of teams and organizations. Learn more about Agile

So, what exactly is Scrum?

Agile is a philosophy. It gives you principles but doesn’t tell you how to implement them. There are various methodologies (or frameworks as they’re often called) that can help your team become Agile. Scrum is the most popular and widely used framework for embracing the Agile philosophy. In other words, Scrum is a project management process that can help your team serve the changing requirements of your stakeholders better, hence becoming Agile. 

Scrum and Agile are often used interchangeably. That’s incorrect. Scrum is one of the many frameworks that can be used to implement the Agile philosophy. You can be Agile without following Scrum. You can’t follow Scrum without being Agile. 

How does Scrum work? Here are its 5 essential steps. 

1. Assemble your Scrum team

Scrum teams can only work if they have few people. Scrum.org recommends less than 7 members. That’s occasionally stretched to 9. Any more members would make the entire process counterproductive. 

If you have a large organization with bigger teams, you can still try out Scrum for projects that require functional teams. For example, if you are a consulting firm that needs to work on an in-depth research project for a client, the people working on it can be assembled into a scrum team.  

2. Appoint Scrum roles

Every Scrum team needs to have at least three roles –

  • Product Owner – The product owner is someone who is responsible for the final outcome of the Scrum. They represent the voice of the customers/clients to the Scrum team and act as the face of the Scrum team in front of the customers. They are called “product” owners because, in engineering teams, the focus of every Scrum is software/product. In our example, the product is the research project and the product owner is responsible for ensuring its success. Every Scrum team should strictly have only one product owner.
  • Scrum Master – The Scrum master is the closest thing to a project manager in a Scrum team. The official Scrum guide defines Scrum master as a servant leader of the Scrum team who helps everyone understand Scrum theory, practices, rules and values. The Product Owner defines “What” and “Why” of the project while Scrum Master is responsible for “How”. 

Scrum teams are intended to be self-organizing. Therefore Scrum masters don’t tell the team what to do. They play a supportive role by absorbing the pressure from stakeholders, clearing the path for execution, and building a culture of ownership and trust in the Scrum team. They are not project managers because they don’t exercise control, set priorities or deadlines.  In our example, Scrum masters won’t tell the team which topic to research first or how to format the report. They will simply ensure that the team is supported and the Scrum principles are upheld. There should be only one Scrum master in the team. 

  • Execution team  – Everyone else in the Scrum team is in the Execution team (also called the development team). They are self-organizing and drive the Scrum plan forward. The execution team in Scrum doesn’t rely on spoonfeeding. They not only get work done but also help with the estimation of deliverables. Scrum teams are usually autonomous and capable of finishing the project from start to finish. 

3. Plan your team’s sprint

Once the team is assembled and the roles are defined, the next step is to plan your Scrum team’s sprint. Sprint is a small timeframe within which the Scrum team needs to deliver certain results. It’s a timeboxed effort and the basic unit of Scrum. A Scrum project has multiple sprints, each sprint having its own goals. 

A typical sprint lasts between 1 – 4 weeks, with 2 weeks being the most popular option. Each sprint has a backlog that consists of all the to-dos of that sprint. In a way, sprints serve as milestones for achieving the final result. In our example, let’s assume that the project to deliver the final research is due in one month. It can then be broken down into two 2 week sprints. The objectives of first sprint can be to complete all primary research. Sprints allow the Scrum team to adjust their project based on changing requirements – the core principle of agile methodology. 

In the sprint planning meeting (organized by Scrum master), the product owner and the execution team discuss the following things:

  • What should the team accomplish during the sprint? This is consolidated in the sprint backlog.
  • Discuss the approach to delivering sprint goals. Is there any external support needed?
  • Get the buy-in from everyone in the team. It’s important because Scrum is not a top-down approach. 

According to the Scrum Guide, the sprint backlog is not etched in stone. It’s an estimate by the Scrum team. The only certainty in the sprint is its duration. Learn more about sprint planning

4. Organize daily standups

Daily standups (also known as daily scrums) are 15-minute time-boxed meeting for the execution team to synchronize their efforts and plan for the next 24 hours. The team holds daily standups every day for the duration of the sprint. Daily standups boost the chances of the Scrum team to meet their sprint goal by removing obstacles and aligning the team’s efforts. 

If there are any changes in the estimation or forecast of the sprint backlog, the team discusses them during the daily standups. Daily standups ensure that the Scrum team and stakeholders don’t drift away from each other and their expectations are aligned. If done well, there would be no nasty surprises at the end of the sprint. 

The Scrum master organizes this meeting and ensures that it is timeboxed but the execution team leads the meeting. It’s an internal meeting of the execution team. It’s only meant for internal team collaboration and not status updates. Therefore, usually the product owner doesn’t join it. If they do, then they do so as mere observers. Learn more about daily standup

5. Sprint review and retrospective

At the end of each sprint, the Scrum team holds two important meetings. They are occasionally bundled into one, but both meetings have two distinctive goals. 

  • Sprint review – Each sprint has a tangible goal. It aims to deliver results that offer immediate value to the stakeholders. The sprint retrospective is a meeting held at the end of each sprint where all the stakeholders and the Scrum team meet to discuss the results of the sprint. Like all sprint meetings, this too is organized and facilitated by the Scrum master. The team analyzes if the sprint goals were accomplished. It answers sprint related questions from the stakeholders. The team also discusses the priorities for the next sprint. This serves as the foundation for the upcoming sprint planning meeting.
  • Sprint retrospective – Sprint retrospective is a meeting that’s also organized at the end of each sprint, usually just after sprint review. It’s an internal meeting for the Scrum team and doesn’t have external stakeholders. The purpose of sprint retrospective is for the team to look back at the sprint and highlight what can be improved.

Continuous improvement is the hallmark of Agile philosophy and the Scrum team uses sprint retros to ensure they take key learnings from each sprint and implement them in the next one. Learn more about sprint review and retrospective. 

Once you assemble the Scrum team and definite its roles, Scrum essentially boils down to the following cyclical process. This is of course a simplified version but the core remains the same in all Scrum projects.  

If you would like to try out Scrum with your team, sign up for free on Taskworld. It’s an online collaboration tool that’s ideal for Scrum projects. 

Want to get more actionable productivity tips?

Want to give your team a productivity boost ?

Interested in a media collaboration? Reach out! :)