An Introduction to Scrum: Roles, Ceremonies, and Processes for Agile Teams

Scrum is perfect for small, remote teams working on complex software products. But its rapid rise in popularity has meant that Agile Project Management with Scrum is often not fully understood, even by those who have been exposed to it.

In this series, I hope to clear up some of the confusion around terminology, while providing a clear framework on how we implement Scrum across the majority of the projects we deliver at Scalable Path.

Agile vs Waterfall

By deciding to build your software with Scrum, you are also embracing the Agile methodology. Agile was a response to a problem: software projects were coming in over deadline and over budget.

Probably the most famous cautionary tales come to us via Microsoft: Windows 95 was late. Windows 2000 was late. Windows Vista was seriously late. All of these releases were built using a traditional project management method called Waterfall.

• Planning
• Design
• Development
• Testing
• Delivery

The Waterfall method has a long, distinguished history, but was found lacking for software development in the Internet age. An age where products become dated quickly and are often in a permanent state of evolution.

Today, Microsoft has fully embraced Agile. This is because Agile turned previous approaches on their head, well on their side at least.

Agile encourages releasing software incrementally, instead of trying to deliver it all at once near the end. The diagram above clearly illustrates the fundamental differences between Waterfall and Agile. It is this incremental style that has led to Agile systematically sweeping through the software development landscape. So much so, that less than 10% of projects currently use the Waterfall project management approach.

I find it easy to think of Agile as the guiding project management philosophy and the Scrum methodology as the specific rules and directions used day today.

What is Scrum?

Scrum is a project management framework popular in software development. In this model, a team consists of a Scrum Master, Product Owner, and Developers. Each project is broken into bite-size chunks, prioritizing them and delivering them in short bursts called ‘Sprints’. Ultimately, it’s an empirical process that emphasizes teamwork and an iterative process.

The popularity of the Scrum methodology likely stems from the way it deals with complexity and change. It does this in a similar way to how you or I would when faced with lots of work and not much time.

The Elements of Scrum Methodology

The Product Backlog

Write a list of all the tasks or features you would like to complete. In Scrum, these issues are often called ‘User Stories’ and describe the user of the software that the feature is for, what they want to do and why.

Estimation

Every user story is given a score based on its assumed complexity. Common estimating methods include t-shirt sizes (S, M, L, XL), powers of 2 (1, 2, 4, 8) or the Fibonacci sequence (0,1, 2, 3, 5, 8, etc). We use the Fibonacci sequence at Scalable Path and wrote a short article on why it is useful when developing digital products.

Grooming Your Backlog

Stories in the backlog are then prioritized by the client, based on their importance to the business. The stories near the top of the backlog need to be defined enough to begin working on them. It is less important to fully define stories that are low priority and not likely to be developed soon.

Scrum Sprints

Once the user stories in the backlog are sufficiently prepared, the Scrum Team can decide together on a subset of the stories that they think they can complete in a short period of time. These stories are put into a sprint and the development team focuses only on these issues for the duration of that sprint.

Most Scrum coaches recommend sprints to be one or two weeks long. We tend to run ours for two weeks, partly because of the overhead that comes with every release. A two-week schedule halves the percentage of time we spend doing deployment and releasing. If a project has mature automated testing and deployment, releases can be done more frequently without incurring overhead.

The period you opt for will be unique to your Scrum Master, client requirements and team. Here are some thoughts that should help you make a more informed decision:

• Remember Scrum is about fast feedback and improvement. Shorter sprints speed up feedback.
• High-performance teams often work better under pressure. Shorter Sprints provide this pressure.
• Each Sprint should be an independent shippable product. If your team is newly formed or you are working on larger tasks, you may need 2 or more weeks to achieve this.

At the end of a sprint, you should have a new version of the product. Then the process repeats and the next set of most important stories are pulled into the next Sprint.

Five Reasons Why Companies Are Embracing Scrum Methodology

Several factors contribute to Scrum’s widespread adoption as a popular framework for agile project management. Its adaptability, emphasis on collaboration, and ability to accommodate change make it a powerful tool for organizations seeking to optimize their development processes. Furthermore, Scrum’s iterative approach ensures that the end product aligns with customer needs and expectations, leading to improved satisfaction and outcomes. Here are 5 key benefits that have contributed to Scrum’s success and popularity:

1. Iterative Development

Scrum embraces the agile MVP approach championed by Eric Ries: start with something simple and add to it over time. Scrum comes with baked-in guidelines that assume requirements will evolve – and so it is flexible when this happens. This is in sharp contrast to traditional project management approaches that shun change because of its high perceived cost.

2. Multi-Disciplinary

Scrum encourages a multi-disciplinary culture where roles overlap (which is why it is so popular with startups). This approach is very effective at reducing ego within individuals and giving people a much better understanding of the value of other roles.

3. Scope Can Change

The second Agile principle says, “Welcomes changing requirements, even late in development.” It’s even built into the Agile Manifesto. The client feedback that follows every Sprint is ideal for clients who get to ensure the project stays true to their vision and provide timely insights as the software evolves. But it also gives the development team the ability to innovate without sacrificing too much time or budget.

4. Better Communication

When you develop iteratively, you can take on board valuable feedback throughout the process. A lack of client communication on a Waterfall project might not become apparent until the product is in the final QA stages. With Agile, any issues are likely to surface earlier on as features in a particular sprint are tested. This regular collaboration between all stakeholders is one of the reasons we recommend using Scrum methodology for remote or decentralized teams, where communication needs to be part of the process.

5. Transparency and Accountability

Agile is built on transparency, and Scrum epitomizes this by keeping all tasks and communications visible to everyone. While transparency is vital to the correct functioning of a Sprint, it also has the added benefit of increasing the performance of team members. Harvard Business Review’s 2013 employee engagement survey revealed that 70 percent say they’re most engaged in workplaces that encourage transparency.

Scrum Roles and Responsibilities

The Product Owner

If it’s your product that is being built or maintained, then this is you. You have the vision for the product, you know who the customers are and how the product will fulfill their needs. You also understand how the product meets your business and market requirements. If this paragraph is speeding your heart rate up, don’t worry, we wrote a guide on being an awesome Product Owner.

As a Product Owner, one of your main responsibilities is to manage the Product Backlog (This is the umbrella term for all the User Stories mentioned previously). You have to ensure everyone in the business and the Scrum team agrees and understands these features.

The Scrum Master

Scrum can be challenging to do well, and a Scrum Master’s job is to make sure the team follows the process they have decided upon. For example, the Scrum Master will schedule the daily standup meetings, ask questions of the development team, make sure meetings don’t go too long, and remove “blockers” that may be preventing developers from proceeding with their work. Scrum Master may be a member of the development team who has been trained in Scrum (e.g. a Certified Scrum Master) or may be a dedicated project manager.

The Development Team

The Development Team, which is typically up to 8 individuals, has a simple goal – to work together to develop the product.

An Agile team is self-organizing, which essentially means it is the role of the team to identify which competencies they are lacking for any particular project. But you do need a few key roles to get started. Typically a Lead Designer and Lead Developer will give you the knowledge to identify any remaining positions.

Scrum Ceremonies

Ceremonies are simply the Scrum term for ‘meetings’. The use of ritualistic terminology should give you an idea of the importance these have within Scrum.

Agile guidelines typically list 4 key ceremonies. For a new project (or team) we strongly suggest you include each in your sprint process. They help ensure that the projects stay on track, that all members are fully informed and that your team will become more efficient at delivering work.

Over time though, as both projects and teams evolve, these set requirements may start to appear overly rigid. Agile, as its name implies, should not constrain you. We tweak the process for many of our projects as we become more familiar with the optimal way they should be run.

Sprint Planning

This ceremony is attended by the development team, Scrum Master and the Product Owner and occurs before each sprint. The Scrum Master should encourage collaboration by all members to ensure full team buy-in.

The aim of the sprint planning is to clarify every story that will be pushed live in the sprint. To facilitate this, the Product Owner will have prepared and prioritized the product backlog. Each item is then discussed individually and the team estimates the effort involved. This process continues until an agreement is made on what stories can be completed in the upcoming sprint.

The Daily Standup Meeting

As its name suggests, this ceremony occurs every day and is attended by the development team, the Scrum Master and the Product Owner.

“We sometimes tweak the frequency of other Scrum ceremonies, but always ensure we hold our Daily Standup. It is essential to the success of every project,” says Damien, CEO at Scalable Path. This meeting should be no longer than 15/20 mins. In fact, the use of the name ‘stand up’ was chosen so that, when meeting in person, teams would remain upright to encourage a short discussion.

Topics to be covered should be limited to:

• What was done yesterday
• What is being done today
• Any blockers or questions they might have

The product owner is there to answer any questions about how the software should function (or if necessary, take notes to get answers to questions later).

Sprint Review/Demo

The sprint review meeting is an informal round-up of all completed stories and a demonstration of the new product increment. By ‘informal’ I mean no slides should be used to guide the direction of the conversations.

Included in this meeting are the Product Owner, the development team, the Scrum Master and often stakeholders from the client who want to see the output of the sprint.

If any stories were not completed, these are discussed ad the Product Owner updates the product backlog for the next sprint.

Retrospective

There is a natural tendency to skip the Retrospective in the rush to start the next sprint. But doing so regularly will affect growth and performance. Each team needs time to reflect on how they can become more efficient and adjust their behavior accordingly.

The Retrospective is, at its core, about how the team can optimize the way they work together. This should not be limited to discussions about the flow of stories through the process but should include anything that affects output: from the attitude of the team to the software being used.

If you feel you need a framework for this part of the meeting then you may want to categorize all issues raised into the following buckets:

• Start doing
• Stop doing
• Continue doing

The retrospective is attended by the development team, the Scrum Master and the Product Owner.

Conclusion

In this article, we’ve looked at the Scrum methodology, including how it works and its benefits for teams. Now that you’re equipped with a better understanding of Scrum, the next steps to getting started are to form a Scrum team, create a product backlog, and plan your first sprint. Hopefully, you can begin leveraging this framework in your software development efforts and start seeing the benefits!