Scrum Tools and Best Practices
Tags: agile, scrum, management, programming
Published: 2022-08-03 17:19:00

**Scrum is a simple framework, but it takes deliberate practice and motivation to master it. Learn which tools make it easy to implement with your team.**

For any project a team may be working on, there is an associated timeline built around when the project needs to be complete. There has been a lot of development in the past few decades on solutions to properly manage projects and incorporate feedback from users along the way.

According to [project-management.com](https://project-management.com/agile-project-management/#what-is-agile), “Agile project management utilizes an iterative approach that includes frequent and continuous releases, with feedback incorporated throughout.”

The iterative approach is the key element that differentiates agile project management from the [traditional “waterfall” project management](https://project-management.com/agile-vs-waterfall/#differences) methodology. With frequent and continuous releases, the agile framework allows the customer/client to review the work at certain points and thus provides opportunities for course correction.

The idea of agile project management came forth after the [Agile Manifesto](https://agilemanifesto.org/) was created in 2001. Seventeen software practitioners came together to uncover a new way to develop software. The following agile methodologies serve as the foundation for agile project management:

* [Scrum](https://www.visual-paradigm.com/scrum/what-is-agile-and-scrum/)
* [Extreme Programming](http://www.extremeprogramming.org/) (XP)
* [Lean Software Development](https://www.productplan.com/glossary/lean-software-development/)
* [Kanban](https://kanbanize.com/kanban-resources/getting-started/what-is-kanban)
* [Crystal](https://www.productplan.com/glossary/crystal-agile-framework/)


This article will focus on some of the best practices and benefits of scrum and explore several tools you can use to aid in its implementation in your organization.

## Why Scrum?

In 1999, Dave Snowden developed [the Cynefin framework](https://en.wikipedia.org/wiki/Cynefin_framework) to put certain “domains” into perspective to aid in decision-making. When it comes to software development, there are a lot of unknowns. These unknowns may be due to technological advances, changes in project environments, assumptions related to project requirements, and so on. In the context of the Cynefin framework, software development falls into the “complex” domain.

According to the [Scrum Guide 2020](https://www.scrum.org/resources/scrum-guide), “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

For the teams involved in complex software development, the scrum framework enables value delivery through frequent and continuous releases.

![Scrum framework](https://i.imgur.com/QvyNqSi.png)
*Image concept courtesy of [Scrum.org](https://www.scrum.org/resources/scrum-framework-poster)*

### Benefits of Using Scrum

The scrum framework defines [three roles](https://scrumguides.org/scrum-guide.html#scrum-team), [five events](https://scrumguides.org/scrum-guide.html#scrum-events), and [three artifacts](https://scrumguides.org/scrum-guide.html#scrum-artifacts), each of which will be discussed below. Its [pillars](https://scrumguides.org/scrum-guide.html#scrum-theory) of transparency, inspection, and adaptation make the scrum framework uniquely suited to provide the following benefits.

#### Better Collaboration between Developers and Business Stakeholders

The five events work toward enhancing collaboration between developers and business stakeholders. When these events are implemented as defined in the [Scrum Guide](https://www.scrum.org/resources/scrum-guide), the business stakeholders are made aware of the project’s progress through each of the five events:

* [Sprint](https://scrumguides.org/scrum-guide.html#the-sprint): the event encompassing the other four events, where ideas are turned into value
* [Sprint Planning](https://scrumguides.org/scrum-guide.html#sprint-planning): the event in which the sprint commences, where the developers commit for the work to be performed. It addresses the following questions:
	* Why is this sprint valuable?
	* What can be done in this sprint?
	* How will the work get done?
* [Daily Scrum](https://scrumguides.org/scrum-guide.html#daily-scrum): the most important event, in which the scrum team meets and reviews the [Sprint Goal](https://scrumguides.org/scrum-guide.html#sprint-backlog) (one of the scrum artifacts), adapting the [Sprint Backlog](https://scrumguides.org/scrum-guide.html#sprint-backlog) as necessary
* [Sprint Review](https://scrumguides.org/scrum-guide.html#sprint-review): the event in which the scrum team inspects the outcome of the sprint and determines future work by collaborating with the business stakeholders
* [Sprint Retrospective](https://scrumguides.org/scrum-guide.html#sprint-retrospective): the event in which the scrum team meets to inspect and review their way of working with the various people, processes, and tools involved

#### Visibility Using Information Radiators

Information radiators provide an at-a-glance [view of the latest information](https://www.agilealliance.org/glossary/information-radiators/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'information*20radiators))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) about the project.

The Sprint Backlog and [Product Backlog](https://scrumguides.org/scrum-guide.html#product-backlog) provide specific, detailed information about the work remaining to accomplish the project goal (often defined by two of the Scrum artifacts, the Sprint Goal and [Product Goal](https://scrumguides.org/scrum-guide.html#product-backlog)), which should be readily available at any point during the project to ensure transparency.

#### Clear Accountability

Three roles in scrum—the scrum master, product owner, and developers—are each responsible for various activities, such as business-stakeholder collaboration, development, validation, maintenance, operation, and so on. The accountabilities as specified in the Scrum Guide eliminate confusion and establish a clear understanding of what each role is uniquely responsible for.

#### Continuous Feedback

The scrum event [Sprint Review](https://scrumguides.org/scrum-guide.html#sprint-review) serves as an opportunity for the scrum team (scrum master, product owner, and developers) and business stakeholders to gather and discuss new information that may have emerged during each time-boxed sprint of two to four weeks. This allows for an iterative sequence of development, review, and feedback that can better help the project achieve its targeted result/goal.

When the [Increment](https://scrumguides.org/scrum-guide.html#scrum-artifacts) (the third of the scrum artifacts) is created as a result of work during the sprint, it becomes the point of discussion for the Sprint Review.

### Drawbacks of Scrum

While implementing scrum offers many valuable benefits, it also has a few drawbacks worth noting.

#### Too Much Flexibility?

Scrum offers a wide range of possibilities for its implementation. Due to the not-so-prescriptive approach of the Scrum Guide, implementation can vary hugely from an organization to another. In the Agile community, it often [starts a debate](https://www.reddit.com/r/agile/comments/nu6wlk/disadvantages_of_using_scrum/) surrounding “Are you *really* doing scrum?” This can easily turn into an endless quest of discovering better ways of “doing scrum” instead of discovering better ways of accomplishing the work at hand.

#### The Ambiguous Role of the Scrum Master

The responsibilities of the scrum master as defined in the Scrum Guide are similarly open to interpretation. Sometimes an organization employs a scrum master to do the work of a traditional project manager, while other organizations may [want the scrum master to focus on the development work](https://medium.com/serious-scrum/5-things-i-hate-about-scrum-aa52908dcd78). This ambiguous role can further compound confusion and blurred lines for the entire scrum team as to the actual responsibilities of the scrum master.

## Scrum Best Practices

At its core, Scrum is a *[framework](https://en.wikipedia.org/wiki/Framework)*: “an essential supporting structure which other things are built on top of.”

Being a supporting structure, a framework can be adapted according to the needs of the things built on top of it. While this flexibility *can* become overwhelming, it offers organizations the ability to adapt the scrum framework to meet their unique needs. There is no one solution for implementing the scrum “the right way.” Rather, the scrum framework provides broad guidance on how projects should be carried out, leaving specific applications to be determined by the team.

While these applications may differ from organization to organization, here are some of the best practices from its implementation across the industry that you can incorporate into your use of scrum.

### Keep Teams Small, Cross-Functional, and Self-Organizing

Typically, a nimble scrum team is made up of ten or fewer people. Effective lines of communication are key to a project’s success, and as your team grows, this becomes [geometrically more complex to manage](https://www.leadingagile.com/2018/02/lines-of-communication-team-size-applying-brooks-law/).

By keeping the scrum team small, you have fewer communication channels internal and external to the scrum team. For larger project implementations with many scrum teams involved, it makes sense to use the [Nexus framework](https://www.scrum.org/resources/nexus-guide) to scale the use of scrum.

The benefits of using scrum are further elevated if the scrum teams are cross-functional and self-organizing.

A *cross-functional* team consists of team members from different functional areas of the organization. Relying upon each other’s knowledge and experience, the scrum team can achieve the goals of the project faster and more efficiently.

A *self-organizing* team functions without any explicit mandate from authority/top-level individuals. They organize themselves into action. With the necessary empowerment and effective team structuring, teams can maximize the benefits of scrum.

### Keep Teams Focused

Unfortunately, even when you have the best processes in place, life happens. Something in production breaks, and it throws out sprint planning. Or an urgent tweak needs to be made in the middle of the sprint. For example, regulations in a country changed, and it is important to ensure that the software is compliant. Typically, this means neglecting the lowest-priority item or having to renegotiate priorities with the different stakeholders.

An alternative approach would be to assign one person each week to only work on any bugs and critical changes if and when they are needed. If your team requires someone to be on standby after hours, it works well to assign these two roles at the same time. If they encounter a problem in the middle of the night, they can implement the fix ASAP during the night and iron out repercussions the next day.

What if there aren’t any bugs or critical changes for them to work on? They can always start working on an item for an upcoming sprint to help reduce the backlog.

Rotating this person out each week not only ensures that no one person gets burned out and that sprint planning remains unimpacted by bugs; the development team also gets exposure to the entire product instead of their focus area.

### Follow Scrum Events “by the Book”

The most important aspect of scrum events is their allotted time box. The essence of scrum is in the simplicity with which the events are structured.

For instance, with Daily Scrum, the developers of the scrum team typically meet at the same time and place every working day of the sprint in order to analyze the Sprint Goal and adapt the Sprint Backlog as needed. Utilizing the same time and same place reduces complexity and helps to keep the developers focused on what matters.

When it comes to remote working, the world has rapidly learned to embrace certain tools to better conduct scrum events. The experience of implementing “digital scrum” has been seamless thanks to the wide range of tools available in the market. Here are some of the more popular options currently available:

* [Jira Software](https://www.atlassian.com/software/jira) provides [an Agile-based approach to run scrum events](https://www.atlassian.com/agile/tutorials/how-to-do-scrum-with-jira-software) to drive a scrum project. For instance, in the Sprint Planning meeting, the scrum team discusses the work to be performed for the given sprint. Jira Software facilitates Sprint Planning meetings, allowing for easier ordering of the work items in a sprint.

![Jira](https://i.imgur.com/flKL8cO.png)
*Image courtesy of [Atlassian](https://www.atlassian.com/blog/agile/sprint-planning-atlassian)*

* [Monday](http://monday.com/) also has a sprint planning template that makes it easy to [organize the information/work items involved in a sprint](https://monday.com/blog/project-management/scrum/).

![Monday](https://i.imgur.com/vfj2fML.png)
*Image courtesy of [Monday.com](https://monday.com/blog/project-management/scrum/)*

* [Status Hero](https://statushero.com/) focuses on keeping your team on track, employing a great [check-in feature](https://help.statushero.com/en/articles/841011-checking-in) that allows teams to monitor individual and collaborative progress toward goals. To eliminate additional meetings and better serve teams that are geographically distributed, the Daily Scrum can be conducted virtually and asynchronously using this check-in feature. Once the team members update their daily check-ins, a consolidated summary is made available to report on the status of each team member’s work on the project.

![Status Hero](https://i.imgur.com/sxR6m6l.png)
*Image courtesy of [Status Hero](https://help.statushero.com/en/articles/841011-checking-in)*

### Manage Product Backlogs Effectively

According to the [Scrum Guide](https://www.scrum.org/resources/scrum-guide), “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”

In the context of a scrum project, a Product Backlog holds the list of features to be developed, as well as bugs and the other security- or infrastructure-related work items. These features, bugs, and work items can be described in the form of [User Stories](https://www.mountaingoatsoftware.com/agile/user-stories), which detail the work items from the perspective of a user.

While the product owner typically remains accountable for the product backlog, the developers can also provide suggestions for its order and content. In many instances, nondevelopers with less technical insight, whether product owners or clients, don’t understand the impact of completing work in a specific order. Moving a couple of items around could result in less technical depth and potentially even slower overall delivery.

Developers can explain the importance of doing technical work in a certain order by using nontechnical explanations that are easy to understand. The following is an example: “Yes, we know we need to put on shoes so that we can walk through the area with thorns. However, when we need to put socks on after shows, we’re going to have to take the shoes off (taking care to remove some thorns) just to put the socks on and then put the shoes back on. It will be more efficient in the long run if we delay putting our shoes on until we’ve put our socks on.”

Tools like [Trello](https://trello.com/home) have made it possible to manage product backlogs effectively using product-management templates that [help provide better visibility](https://trello.com/templates/product-management/product-roadmap-template-FrbAJsbH) to the feature requests. Trello’s templates also make it possible to more easily facilitate the inward flow of information and feature needs from other teams, such as sales and marketing.

![Trello](https://i.imgur.com/i9IHx1z.png)
*Image courtesy of [Trello](https://trello.com/b/FrbAJsbH/product-roadmap-template)*

Similarly, [Airtable](https://airtable.com/) can help create a “custom agile workflow,” starting with organizing stories through a backlog. Airtable also offers prebuilt templates, like [this one](https://www.airtable.com/templates/product-design-and-ux/exps29rjSzaWD5UD7/agile-workflow), which includes columns such as Priority, Function, and Sprint, which are flexible and can easily be customized as per the product owner’s needs.

![Airtable](https://i.imgur.com/KshHu2S.png)
*Image courtesy of [Airtable](https://airtable.com/shrhf7WgpbGSr6mfH/tbls7KheB28XHnviC/viwKIlopa4ZutcbyR)*

### Collaborate on Estimating the Work

When it comes to Agile methodologies, there is a collaborative approach to estimating the work that can be done in a sprint. The scrum team may choose to use story point estimation, which you can learn more about [here](https://statushero.com/blog/engineering-estimates/).

Adding an estimate to a work item happens in the Product Backlog Refinement meeting. Though the product backlog refinement meeting is not a formal scrum event, the Scrum Guide references this meeting to yield more precise work items. Rather than following an estimate provided by just one person (i.e., a manager or technical lead), using story point estimation allows for a collaborative approach that considers the expertise of each of the developers on the team.

Instead of doing estimates by going around the room to ask everyone’s opinion, do [planning poker](https://en.wikipedia.org/wiki/Planning_poker), for which there are many free tools available online. People tend to take their cue from more experienced teammates because of [confirmation bias](https://en.wikipedia.org/wiki/Confirmation_bias): “My estimate can’t be lower than the most experienced member in the team.” This typically leads to inaccurate estimates.

It’s also important not to simply use the average estimate of the team to speed the process up. If one person scored higher or lower than the rest of the team, discuss that discrepancy. That person might have some insight that the others don’t. Conversely, they might lack some insight, and discussing the estimate will help them grow their knowledge and understanding.

### Utilize Team Velocity for Better Forecasts

The Sprint Planning event answers an important question: [what can be done in this sprint](https://scrumguides.org/scrum-guide.html#sprint-planning)? In the complex domain of software, it makes sense to answer this question relatively. Scrum teams often use “relative” story points to forecast the work items in the Sprint Backlog.

To best measure their ongoing and upcoming progress, it is important that the team uses a particular metric: After a few sprints, Scrum teams understand their “velocity,” which describes the amount of work [they can get done in future sprint(s)](https://statushero.com/blog/scrum-metrics-every-team-leader-needs-to-track/). In the Sprint Retrospective, Scrum teams can review their velocities and improve forecasting for the future sprints accordingly.

However, understanding the team’s velocity alone isn’t enough. Different people work at different paces, so it’s important to also understand individual velocity. Taking actual sprinting as an example, you assign one story point to running one hundred meters and two story points to running two hundred meters because it is roughly twice the effort involved. According to a user on [Quora](https://qr.ae/pvFMeY), the average speed for a male to run a hundred meters is between 15 and 20 seconds. Compare that to Usain Bolt’s [world record](https://en.wikipedia.org/wiki/200_metres#:~:text=The%20men's%20world%20record%20holder,at%20the%201988%20Summer%20Olympics.) time of running two hundred meters in 19.19 seconds. It means that the Usain Bolt on your team can complete two story points in the same time that everyone else can complete one.

It is important to know who on your team can do more (or less) work in the sprint than the rest, not for performance management but to take their leave days into consideration. When a high-performing developer plans on taking leave, you need to make sure that you adequately adjust your story points so that the team can handle their work during the upcoming sprint. The same goes if you implement the earlier suggestion to rotate team members to handle bugs or critical issues.

Lastly, keep [Parkinson’s law](https://en.wikipedia.org/wiki/Parkinson%27s_law) in mind: work expands (and is complicated) to fill the time available for its completion. If a team member keeps on being assigned twenty-one story points per sprint, chances are that it will be all that they can complete. Over time, you need to gradually increase the story points you assign to team members per sprint to prevent them from becoming complacent.

To help you accomplish all these suggestions, Status Hero has integrations and an API to help fetch the estimates and reports from other tools such as Jira, Azure DevOps, and Asana. Using the webhooks, you can populate required data in the activity stream. You can check out Jira integration as an example [here](https://help.statushero.com/en/articles/1222829-jira-integration).

## Conclusion

Scrum is a simple framework, but it takes deliberate practice and motivation to master it. In this article, you learned about the nuances of the scrum framework and examined some tools that can aid in its successful implementation.

As the hybrid/remote way of working continues to become increasingly popular, the importance of asynchronous communication has become crucial, especially for teams implementing scrum. If you are an agile coach, scrum master, or a scrum team member, consider using Status Hero to help synchronize and connect your team without the hassle of scheduled meetings or other interruptions.

_By Aditya Kulkarni. Having a development background, Aditya chose to pursue the path of being a Scrum Master and Agile Coach, and he's recently jumped back into the world of writing._