Scrum Best Practices for Teams

When you’re developing complicated products, it’s a given that customers will change their minds. Project teams can’t anticipate how customer wants and needs will flip-flop during the course of their projects.

Scrum best practices empower team members to adapt their development approach as changes occur or problems arise. They work together to:

• Figure out the best way to meet emerging requirements
• Remove impediments to progress
• Reprioritize the work that needs to be done to meet project goals

This mindset makes Scrum ideally suited to complex projects that are likely to have unpredictable changes and challenges.

Before we dive into Scrum best practices, let’s take a quick look at the origins of Scrum and how teams use Scrum to develop products.

Created in the early 1990s by Ken Schwaber and Jeff Sutherland, Scrum is a framework for team collaboration on complex products of the highest possible value. Scrum teams use an iterative, incremental approach to work, so they can quickly solve problems and deliver useful versions of products or other desired outcomes. Whether it’s used to develop software or manage organizational operations, Scrum enables small teams of people to self-organize, collaborate and continuously deliver value to customers.

Scrum is best known as a way of doing work within the Agile methodology, which emerged in the 1970s and was popularized in 2001 with the publication of the Manifesto for Agile Software Development. Inspired by the Manifesto’s core values and principles, companies embraced the Agile methodology for its benefits to the business and its people. Scrum places high value on people as an asset. It is built on five core values:

1. Focus on the goals of the Scrum Team
2. Openness about the challenges of performing the work
3. Courage to do the right thing and work on tough problems
4. Commitment to achieving Scrum Team goals
5. Respect for each other as capable and independent people

Proficiency in Scrum comes with practice living these core values. Here’s how Scrum works, in a nutshell. Consider the potential impact of Scrum best practices on the development cycle.

Scrum begins with collaboration among customers, users, stakeholders and the Scrum team to define what they will be working on and why. Together, they create a Product Backlog that lists all of the items that must be developed to deliver a valued, working product. In a subsequent four- to eight-hour Scrum Planning Event, the Scrum Team chooses a prioritized list of items from the Product Backlog and commits to completing these items in a one- to four-week Sprint. This list becomes the Sprint Backlog, and the items are described in User Stories, each detailing a requirement from a user’s point of view.

During the Sprint, the Development Team, a small, cross-functional group of five to seven members, works on the items in the Sprint Backlog. In 15-minute Daily Scrums, each team member reports what they worked on in the past 24 hours, what they will work on in the next 24 hours, and what impediments could prevent them from achieving the Sprint Goal.

This time-boxed event promotes transparency and quick decision-making. At the end of the Sprint, the Scrum Team meets with stakeholders to determine if the deliverable is done. Have they met the Sprint Goal by delivering an increment of the Product Backlog that is functional and valued?

The Sprint Review also assesses the Product Backlog status:

• Which items are done
• Which items are not done
• What to do next

A separate Sprint Retrospective is an opportunity for the team to talk about Scrum best practices and how they can do better in the next Sprint cycle. They strive for continuous improvement.

Velocity is the primary measure of work completed during the Sprint, based on the User Stories completed vs. User Stories estimated to complete. Each User Story is awarded Story Points based on its complexity. Scrum Teams use Story Points and Velocity to estimate work as well as to evaluate performance.

In Scrum, achieving optimal Velocity means the Scrum Team quickly and consistently delivers working increments of value to the customer (although definitions of Velocity are subject to debate). A high-velocity Scrum Team that can perform reliably, predictably and on pace is in demand for project after project. Keep them together, no matter what. This seemingly simple way of working can quickly devolve into herding cats if the Scrum Team isn’t using Scrum best practices to do its best work. Any team can improve its performance by implementing these tips for each aspect of the methodology, always with an eye toward delivering a working product of value during each Sprint.

Promote peer-to-peer collaboration

Mutual respect among peers is a core value in Scrum, and transparency is a pillar of the process. Using a project collaboration platform can promote collaboration and conversation among the Scrum team and stakeholders, no matter where they are located. From task-specific issues to Scrum best practices, participants can share information in real time, helping to prevent bottlenecks. A central hub for User Stories, tasks lists, burndown charts, notifications, comments and feedback can give the Scrum participants a clear view of the process and strong voice in resolving issues.

Product owner: As the voice of the customer and product stakeholders, the Product Owner conveys their needs to the Scrum team, maintains the Product Backlog, and sets priorities based on each item’s value to the customer. The Product Owner is responsible for ensuring the team accomplishes its goal. For full transparency, it’s critical to keep all parties in the loop on both progress and impediments, such as how changing requirements can affect the outcome.

Development team: The Development Team is the tight-knit group of multi-talented individuals who are ultimately responsible for development of the product. It’s up to each team member to understand what the customer wants and how each task contributes to delivery of a working product. The Development Team needs to stay in sync by communicating with each other, giving and receiving feedback, and being adaptable.

Collaboration and communication keep the Scrum Team focused. Damien Filiatrault, founder of the Scalable Path network of software developers, notes why Scrum is effective:

“Scrum facilitates communication by creating feedback loops. We want developers to stay in sync with each other and we want the customer to stay in touch with the development team. We also want to create cycles of development in which the customer can see tangible results and give feedback early. There is nothing like working on a deadline for months only to find out the customer was anticipating a different result. Scrum’s methods are designed to help eliminate gaps in the Development Team’s understanding of what a customer wants.”

Scrum Master: As the Development Team’s pseudo coach, the Scrum Master promotes Scrum principles, facilitates adaptive problem-solving and helps team members learn how to work quickly without compromising on quality. The Scrum Master understands the full Product Backlog and can let team members know what needs to be done at any given time. To keep work moving forward, the Scrum Master also shields the Development Team from distractions, addresses issues that block progress and resolves conflicts.

Continually improve performance in Scrum events

Scrum Events are forums for Scrum best practices, starting with sticking to schedules. Each event happens for a purpose and a set time. Adding meetings introduces time-wasting events and overrides Scrum’s built-in efficiencies. Lengthening or shortening sanctioned events disrupts the rhythm of the team’s work, setting up a pattern of practices that can lead to burnout, low velocity or poor quality.

A Lean-Agile application with configurable tools can improve Agile delivery within the Scrum framework. These tools not only automate tasks but also use analytics and team metrics to monitor and predict progress.

Sprint planning: When the Scrum Team sits down for this time-boxed meeting, they have four hours or less to decide how much of the Product Backlog they can complete in this Sprint. Estimates are based on the Story Points, or increments of time to finish User Story tasks. The trick here is to agree on what the Development Team can realistically accomplish. Once there is consensus, the Sprint Goal is set. The Increment must be doable, have value and function independently or in conjunction with any previous increments completed to date.

Sprint (a.k.a, iteration): The Sprint can be time-boxed at one to four weeks, but once set the schedule cannot be changed. Adding days or subtracting User Stories rewards poor skills, such as overambitious estimating or writing ambiguous User Stories. The intent is for Scrum Teams to work as fast as possible without sacrificing quality. Like the quick break from a rugby huddle (the scrum where Scrum got its name), the Sprint is a dash toward the goal. Teams use a burndown chart to track daily progress, plotting tasks planned to complete vs. tasks completed. The odds of achieving the Sprint Goal improve when the team collaborates, problem-solves and quickly adapts to change.

Daily Scrum (a.k.a., daily standup): This time-boxed meeting lets everyone know what’s happening. Meet at the same time and place every day, and don’t run over the time limit. To stay focused, everyone stands up, no excuses. Each team member answers the same three questions:

• What have I accomplished since the last Daily Scrum?
• What am I going to accomplish before the next Daily Scrum?
• What is impeding my work or blocking progress?

Use a visual tool such as an online Kanban board to organize the storyboard, reference task lists, and make updates.

Sprint review: On the last day of the Sprint, the Scrum Team demos finished backlog items to the stakeholders. This high-level show-and-tell lets the team read the User Stories, then show how the items they’ve completed fill the user requirements. Some stories are accepted as Done, but some are unfinished tales that are returned to the backlog. Talk about what the Development Team can accomplish in the next iteration. Be open about lessons learned to date and what improvements can be made in the upcoming Sprint.

Sprint retrospective: No matter what burndown or Velocity the Scrum Team achieves, there are always mistakes to learn from and improvements to be made. This debriefing is only effective if every team member commits to continuous improvement. Ask hard questions like why tasks aren’t completed, how blocks could have been handled or what is affecting team velocity. If Scrum best practices aren’t in place to improve delivery, now is the time to add them to the team’s wheelhouse.

Sticky notes on whiteboards make a visceral statement about product complexity and a Scrum Team’s commitment to burning through the backlog. A Lean and Agile delivery solution can speed product development by empowering teams to work at optimal velocity, no matter how many times requirements change, or major issues block progress. From planning the Product Backlog to adopting Scrum best practices, Scrum practitioners can use these tools to collaborate, adapt and deliver value to customers.

Create transparent Scrum artifacts for inspection and adaptation

Based on an empirical approach that calls for transparency, inspection and adaptation, Scrum produces artifacts that can be verified by everyone on the team. Knowing what the team is working toward and why builds trust among all participants. Making artifacts accessible on a cloud-based platform sets the standard for transparency throughout the project.

Product backlog: The Product Backlog is the single source of information about everything that needs to be done to develop the product. It is also a constantly changing list of requirements. The Scrum Team estimates the effort for each item, stakeholders assign their value, and the Product Owner prioritizes them.

When the customer, stakeholders and Scrum team create the Product Backlog together, everyone understands the rationale. The team sees the customer’s vision, and the customer gets insight into the effort it will take to make that vision a reality.

A joint discussion also surfaces unforeseen complexities or dependencies and yields more accurate estimates. Collaboration at this early stage builds trust and reduces conflict.

Sprint backlog: This is the increment of the Product Backlog that the Development Team agrees it can finish in one Sprint. If the team estimates the effort accurately, they can deliver a valuable part of the product that can be used right away. The Sprint Backlog is comprised of short, simple User Stories, each with a clear breakdown of tasks. Once the Sprint Backlog is set, don’t change it.

User story: A User Story is a simplified description of a product feature or function. User Stories are added to and deleted from the Product Backlog as requirements change. Writing a good User Story – what the feature is, how it works and why the user wants it – ensures the final product meets user needs. Everyone on the Scrum Team should write User Stories. The Development Team creates the task lists that break down how to develop each User Story.

Increment: An Increment is the sum of all the Product Backlog items completed during the Sprint, plus the cumulative value of all previously completed Increments. Upon inspection, an Increment that is deemed to be Done can be released to the customer. If testing and quality assurance have been integrated into the development cycle, any quality issues should be resolved by now. Any remaining bugs get bumped to the next Sprint for fixes.

Definition of Done: Participate in writing the Definition of Done (DoD) during the Sprint Planning Event so that the team has a shared understanding of what work needs to be completed for this increment of the project. The DoD also applies measures of quality, so that it is not a subjective value. Equally important, the DoD creates transparency, getting everyone on the same page about what to expect.

Automate Scrum practices to accelerate enterprise-level initiatives

The Scrum Framework is scalable from an individual team practice to enterprise-wide product development teams. If your organization has multiple Scrum Teams, each team probably uses an adaptation of the framework that works best for its members.

In large organizations where multiple Scrum Teams work in parallel on the same product or on multiple products in a portfolio, there are frameworks for scaling Scrum and coordinating Scrum Teams. These include Large-scale Scrum (LeSS), scrum of scrums, Scrum at Scale and Scaled Agile Framework (SAFe). A methodology-agnostic application can provide configurable tools that allow project teams to work the way they want to work.

Transparency: File sharing and document management can make the Scrum Team’s work transparent to executives, stakeholders, customers and users. Centralize the Scrum Artifact repository and provide access to all the players while tracking changes, recording read-only/edit access history and making the most current version available at all times.

Inspection: Scrum Boards visualize work status, priorities and progress, from tasks not started to the work done. Instead of sticky notes on white boards, Scrum Teams can have configurable story boards for tracking and reporting progress, no matter where members are located. These tools can facilitate inspection of Scrum Artifacts and Events, from product visioning workshops through Sprint Retrospectives.

Adaptation: Change happens. When it does, Scrum teams can adapt and respond with agility. Scrum values processes over tools, but there is no denying that that the versatile applications available to today’s Scrum teams can speed their reflexes and save time.

Using roadmapping tools, for example, organizations can:

• Plan for incremental product delivery
• Establish the business value and priority of each increment
• Estimate how long the product will take to develop in iterative cycles

Scrum teams can quickly break down Product Backlogs into executable tasks and track their progress toward delivery over multiple Sprints. Purpose-built tools support Scrum best practices. The right applications can make even novice teams more agile and adaptable.

Let Scrum be Scrum

Applying best practices can make Scrum Teams more proficient. Automating Scrum practices drives agility across development teams and empowers them to manage the speed of delivery.

Because Scrum is adaptable yet immutable, leveraging software designed to support Scrum can optimize implementation without compromising Scrum Values and the value derived from using this simple yet powerful framework. As the co-creators of Scrum and the Official Scrum Guide note:

“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies and practices.”

Scrum is very well-suited to intricate projects that are expected to have numerous changes as they move through the pipeline towards completion. When implementing Scrum, be sure to let team members know that stakeholder changes are expected and that they are encouraged to adjust their approach as challenges occur or changes need to be made.

Organization that implement Scrum understand that it inherently values people and trusts team members to provide excellent products, often on constricted timelines. Pursuing this fundamentally Lean and Agile approach results in faster turnarounds, offers greater flexibility, and produces less waste.