/ POSTS

20+ Scrum best practices to reach your team's full potential

If you’re reading the EasyRetro blog right now, then chances are you already know how powerful Agile and Scrum can be.

The question is, are you doing it right?

There are countless guides offering tips and tricks to help you run your sprints well — and trying to follow them all can be confusing. That’s why we’ve put together the ultimate list of Scrum best practices. These are practices, habits, and commitments that any team should follow in order to achieve their full potential.

Before we dive in, though, let’s address a question we hear a lot:

How many Scrum teams per Scrum Master?

Truthfully, a great, well-experienced Scrum Master could be responsible for two, even three, teams depending on the workload. However, this assumes that the Scrum Master is only performing that role rather than splitting their time between being the Scrum Master and another development role, such as coding or QC.

For smaller teams, a Scrum Master will often perform more than just that role. Often they’ll be a part of the development team who is flexible enough to handle both development and leadership roles.

If your team is new to the world of Scrum and Agile, then we’d recommend one Scrum Master per team.

General practice tips for Scrum teams

Pick the right product management tool and make sure it’s readily accessible

Using the right tools makes all the difference when working with Scrum. Using something like EasyRetro can help you visualize every step of the process. Using a cloud-based platform makes it quick and easy to pull up boards, burndown charts, and anything else you need to visualize your sprint’s tasks and progress.

Set workshops with stakeholders to form product backlog and product vision

The product backlog is one of the most important artifacts used in Scrum and documents the stakeholders’ product vision. It’s good practice to fill in the product backlog together with stakeholders so they can stay in the loop from the very start.

Invite stakeholders to Scrum meetings

Stakeholders and/or product owners should always be included in Scrum meetings where possible. It’s an easy way to keep them updated on any goings-on and allows them to experience how meetings are run.

It also helps them understand how the team communicates internally — this can lead to vital feedback from an outside perspective.

Don’t break up existing teams

We all know the old saying: “if it ain’t broke, don’t fix it”. That applies to teams that already work well together.

Working with Scrum and Agile methodologies requires a team that can work efficiently. If you break up a team that’s been working together for a while, it means they’ll have to adapt to a new way of working with new people. Not a very agile practice!

Focus on team-building, especially with new groups

On a similar note, team-building is absolutely vital for Agile and Scrum success.

You won’t always have a team ready and waiting for a project — and you’ll sometimes have to patch a new team together to meet the product needs. Team-building exercises are invaluable when creating a new team for an Agile project, and can help promote communication, collaboration, and efficiency.

Take daily standup meetings seriously

The daily standup meeting is a vital part of working Agile.

This quick meeting may seem like a casual affair, but it serves to keep everyone on the team in the loop and can identify problem areas before they damage output. Everyone needs to turn up every day to ensure tasks are being completed on schedule.

Don’t slack on communication when working remotely

By this stage, we all know how difficult it can be to communicate remotely. But we should also have figured out the best ways to do it.

Simply posting on Slack or mentioning something during a Zoom call may not be enough for your point to stick. Always make sure the correct people are notified with every update, either with tags or direct communication. And don’t fear a follow-up message either.

Scrum best practices for planning and estimates

Clarify the objective with an agenda

Working Agile requires everyone to be on the same page at all times. That’s why one of the first things you should do in the planning stages is set an agenda for the meetings. This helps to define the roadmap and allows the team to know what they’re headed — giving them time to think of contributions.

EasyRetro has a great and FREE agenda planning tool to make this even simpler.

Estimate together with stakeholders

Stakeholders should be part of the planning process. This will allow the team to clarify any details before development starts. It also allows for the customer to gain insight into the process and justify estimates if they’re not in line with their expectations.

Plan a new sprint when the product backlog has enough items

A product backlog is a prioritized list of work for the development team that’s derived from the roadmap and its requirements. And we can’t stress how important the product backlog is when working with Scrum.

Sprint planning should be saved until the product backlog has enough items to complete at least two sprints. Without enough items in the product backlog, the project could lose focus.

Set the main goal for each sprint

A sprint doesn’t work if there’s nothing to aim for. Sprint goals should always be made clear before undertaking a sprint. The goal allows the team to understand what tasks need completing and how to prioritize the items.

Goals should be presented in clear one- or two-sentence statements such as: “Implement the check-out workflow: view the cart, set payment, choose a delivery method, pay, receive a confirmation email.”

Plan 6-hour days to mitigate risks

It may seem sensible to plan for the full working day, but failing to plan for potential issues can derail a project very quickly.

Our top tip? Leave two hours in the day unplanned. That way you have extra time to fix any issues that present themselves — an absent team member or computing issues, for example.

Don’t stretch sprint time

Sprint lengths are set for a reason. There will always be the temptation to stretch a sprint if the work isn’t quite complete, but that makes it difficult to judge the effectiveness of the sprint and its length.

Stretching sprints can also encourage the team to become less respectful of other set timeframes.

… but don’t cut sprint time either

Like we mentioned above, sprint lengths are set for a reason. Cutting a sprint short because all the tasks appear to be complete can be just as detrimental down the line.

If you find a rare moment of spare time, consider coming up with some small stories and adding them to the scope until you hit the sprint ending.

Best practice approaches for managing Scrum backlogs

Always separate product backlog and sprint backlog

The sprint backlog should be set in stone in most situations, but the product backlog can change at any moment.

Keeping them separate is vital. That way the team can accurately plan the upcoming sprints by comparing sprint backlogs.

Use task prioritization techniques for product backlogs

There are multiple backlog prioritization techniques, but not all of them work well with Scrum and Agile.

Traditional practices often use HiPPO to prioritize. The problem with this in an Agile setting is that it doesn’t take the team’s workflow into account. Instead, using a prioritization technique such as the Kano model ensures the team is going to be working efficiently and to the best of their abilities.

Assign IDs to items

A simple practice that many teams forget about: you must assign IDs to product backlog items.

It’s just like organizing any other folder — document files, image collateral, or even digital films and music! Giving items an easily recognizable ID can reduce time spent finding specific items and allows the team to collaborate easily (even when working remotely).

Visualize dependencies to capture bottlenecks

Dependencies should be sorted into two groups for best practice approaches:

  • Functional dependencies
  • These are defined by the stakeholders and product owners, as they are the ones who will consider the product’s market behavior.
  • Technical dependencies
  • These are defined by the technical engineers and can include items such as integrating payment gateways before developing the shipping set-up flow.

Use Scrum boards

If there’s one thing we know at EasyRetro, it’s Scrum boards.

Scrum boards are the easiest way to visualize your sprint, tasks, or anything else you might need to bring to life. The boards are built with cards — either in-person with sticky notes or online with one of EasyRetro’s great templates. The team writes their tasks on the cards and adds the cards to the board, showing colleagues and stakeholders exactly what is happening in a clear and concise fashion.

We have a great guide to Scrum boards and over 100 templates to get you started.

Scrum practices for tracking and predicting

Visualize sprint burndown

Burndown charts are an easy-to-understand way to show your team’s progress throughout a sprint.

The chart shows the completed items per day against the planned rate of completion — helping Scrum teams to stay on track. Visualizing the progress also helps detect any issues quickly. That way they can be discussed during daily standups with a focus on resolving them early to keep up a good pace.

Use release burndown charts

Similar to sprint burndown, a release burndown chart helps estimate how many sprints are needed to complete a project on schedule and whether the team must adjust the estimated timeframe as the project progresses.

Release burndowns are particularly important if the product backlog was updated with new items along the development course.

Use velocity measurements

Velocity is a measurement that considers how many items are completed during each sprint compared to initial estimates. Velocity measurements are needed to better forecast team commitment and eventual results to reveal estimation problems in the longer term.

Usually, 3-5 sprints are enough to gauge general team velocity.

Use quality collaboration software

You can have a fantastic team that works together with ease. But give them the wrong tools and you’ll soon find they’re spending more time fixing problems than working on the product.

Using the right software that fits with your team’s workflow is vital to get the best out of them.

How great Scrum teams manage engineering and quality assurance

Don’t separate testing and development

Testing should be seen as part of the development process — not as an afterthought.

Testing the product as you develop it, rather than waiting for it to be finished, can save time and money. It also helps maintain a design thinking ethos.

Frequent product testing catches issues early — before the issue becomes embedded within the final version. That means your end-users get a seamless, error-free experience, and your development team won’t need to go back to the release product to fix any careless mistakes.

Address bug debt in the following sprint

It can be tempting to fix bugs as soon as they’re discovered. But is that the right approach when working within Scrum? After all, jumping on bugs immediately can derail a sprint — leading to a knock-on effect across the team and on the overall project time.

If you can afford to, then make a note of the bug and leave it for the next sprint.

Implement continuous integration

By their very nature, Agile and Scrum are highly flexible methodologies and thrive off of last-minute change. And yet, even if your team is brilliant at switching gears at the drop of a hat, there are always ways to improve efficiency during development.

Utilizing a technique such as continuous integration can do just that.

Continuous integration involves running automated tests for every feature after an engineer commits it. The test will look to validate the new feature and automatically include it into the build. This means bugs are found quicker, giving the team regular updates on possible integration issues too.

Is your Scrum team ready to step up?

Scrum is an exciting, high-potential approach to product and development work. But it takes some getting used to!

If your team is just setting off on its Scrum and Agile journey, then the tips and tricks above are well worth exploring. And you’ll find plenty of other insights and guides on the EasyRetro blog, as well.

Want to create a free retrospective with your team?