Get certified - Transform your world of work today


How to Improve Team Performance in Scrum

24 August 2017

Agile is all about people. As an Agile community, we should always keep in mind the first value of Agile that improves a team’s performance — "Individuals and interactions over processes and tools." People are valued more highly than processes or tools because it's the people who respond to business needs and drive the development process, not the other way around.

Various techniques and approaches are offered in an effort to help the Scrum Team enhance its performance. However, the following summarizes practical actions that are based on practical experience and many years of being an Agile team coach.

Determine sprint capacity

Sprint capacity is sometimes determined at the end of the sprint planning session. When I ask whether we are ready to start the development process for the committed user stories, I sometimes get annoyed or skeptical looks. My expectation is to have such excited and motivated team members that they will succeed with their sprint plan. However, their reaction is a clear sign that they don’t have control over the amount of work they commit to.

In any case, I always use a good technique to determine a team’s level of commitment to a sprint plan called the Fist of Five. Another approach that I use in dealing with sprint capacity is to be proactive by encouraging the team during Sprint Zero or during the grooming session that they should not be hesitant and push back on the product owner (PO) who is asking for a particular story in a particular sprint that they think will not be accomplished. Commit only to what you are sure that you will deliver.

One of the main Agile principles that we forget is "Self-organizing teams encourage great architectures, requirements, and designs." Skilled and motivated team members who have decision-making power take ownership, communicate frequently with other team members, and share ideas that deliver quality products.

Focus on the sprint goal

Do not add work during the sprint that might interrupt the team's focus. I have worked as a lead ScrumMaster at one of the leading IT companies with many distributed teams around the world. I always made sure that the answer to my question about whether the team put all their work in the product backlog was generally yes. That is a clear indication that they were making the team’s work visible.

Nevertheless, I was surprised to learn that if work was added during the sprint and the answer was yes, I found out that planned work indeed went in the backlog, but a lot of unplanned work was sneaking into the sprint and coming from many sources, including the PO, a manager, and sometimes from the business side. Ensure that all product backlog items are visible by adding them to the product backlog before the sprint. Encourage the team to focus on their sprint goal without interrupting them by adding items during the sprint.

The Scrum Team is a self-organizing team, which empowers them to decide what gets into the sprint backlog. In addition, management discusses with the team prior to the start of the sprint an action plan for addressing specific problems. The team puts one improvement at the top of the sprint backlog before any product work is planned. This emphasizes its importance and ensures that there is time to implement it to tackle any urgent issue.

The second Agile principle states, "Accommodate changing requirements throughout the development process." Under this principle, the team avoids delays when a requirement or feature request changes. Work is made visible and prioritized in the backlog at the beginning of the sprint, not during the sprint.

Encourage teams to get things done

The team must complete the high-priority story; other approved backlog items (user stories) can be worked on but not until the high-priority story is done. Do not allow multitasking as part of the cultural norm. Any exceptions should be agreed upon during sprint planning.

Also, keep stories small, and make sure that they are ready. Small stories result in clear, more focused and simple acceptance criteria, which makes them easier to integrate with other related stories. Therefore, there should be about seven to ten stories per sprint. Even smaller stories are preferred for the health of the project.

Return unfinished work to the backlog

Remove unfinished work by directly asking the team at the end of the sprint, "Have we really completed the work that is supposed to be delivered at the end of this sprint?" If the answer is yes, then the incomplete work must go back in the backlog. Then, the team thoroughly discusses the impediments objectively so that they can learn from and clearly plan on how to capitalize on their successes and avoid the unsuccessful work during future sprints. This can be done via an objective and well-planned retrospective session.

Apply best engineering practices

Ensure that the team is indeed using best engineering practices, including standards for written code, pairing, test-driven development, continuous integration, continuous deployment, and so on. Be strategic about how you approach the team since you cannot tell the team how to implement best engineering practices. For example, we can ask questions such as What would be good engineering practices that will maintain the team’s high performance and increase the productivity? Give examples of other organizations where best engineering practices help in increasing team performance.

Consider running Sprint Zero to thoroughly discuss with the team the major issues that might slow down their performance. Use Sprint Zero to tackle what could potentially stop them from getting all the work done, and what can help them with moving forward so that you can capitalize on them.

Be a true servant leader

Help your team by asking what their needs are in terms of work environment, equipment, and software. Help them to implement ideas from the retrospective.

Present the team with the problem, not the solution

One of the intelligent and approving approaches to motivating the team in increasing its performance is to present the team with the problem, not with the solution. Multiple brains are better than one. Challenge them enough to get the best out them. When the team feels truly involved in the process, they own the process.

Allow the time and space to build and develop

As the ScrumMaster, protect the team from any distraction so that they can focus on the work they pull during the sprint planning. I was working with multiple teams as a lead ScrumMaster in one of the top Fortune 500 companies when my contract ended. I was impressed that the teams greatly acknowledged and appreciated that I was giving them the time and space since I was practicing the first and most important Agile principle, "People and interaction over tools and process." They stated that other ScrumMasters were continuously asking about the status, which made them unhappy.

My point is that Agile is all about trusting and empowering people, as expressed in one of the Agile principles, "Support, trust, and motivate the people involved." Motivated teams are more likely to deliver their best work than are unhappy teams.

Write automated tests

Have development write automated tests to determine whether the acceptance criteria for user stories are met. This verification is done by adding acceptance tests to the Definition of Done for user stories. This team practice leads to two positive outcomes: Developers focus on completing the acceptance criteria and quality is maintained since these tests avoid defects that are introduced through new functionality that can break existing features or require refactoring.

Another Agile principle states, "Attention to technical detail and design enhances agility." The right skills and good design ensure that the team can maintain the pace, constantly improving the product and sustaining change.

Run workshops

Run a workshop for the whole team at least once per sprint to review or discuss coding guidelines, design tools, new technology, and your current architecture and engineering practices. As a result, the team will be able to find its own way to get the work done. Also, the team commitment will be stronger because they have more ownership in the process. The Agile principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” means that cultivating a culture of self-improvement, process improvement, and advancing skills and techniques helps team members work more efficiently.

Allow emergency Scrum meetings

A development team is allowed to call an emergency Scrum meeting whenever it feels there is an issue that jeopardizes the sprint goal. Have all team members join the emergency meeting so that the issue can be taken care of as quickly as possible.

Use a Scrum board to view work in progress

Use the Scrum board to view part of the team’s daily work in progress (WIP). For example, team members can easily see that there are user stories accumulating (bottlenecking) in a column on the Scrum board that require testing.

Introduce WIP limits like those normally seen on Kanban boards. These limits force the team to manage the user stories that are blocking the flow. As a result, developers help testers by writing automated tests while testers focus on which scenarios to test. In addition, hold an emergency Scrum meeting if a limit is violated, and for the team to discuss how to resolve the holdup.

Choose a personal sprint goal

As a ScrumMaster, encourage each team member to choose a personal sprint goal at the end of the retrospective. This improves either the engineering skills or tool mastery.

In conclusion, the journey to agility is an endless learning course of actions in which the discovery of new techniques to enhance the team’s performance are always sought out.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.5 (4 ratings)


Tim Baffa, CSM, 8/24/2017 1:43:36 PM

There is some good information and advice in your article, thank you.

However, I was confused by the "Return unfinished Work to the Backlog" paragraph though. I think it isn't worded correctly.

And you refer to the concept of a "Sprint Zero", which is well-known as an anti-Scrum pattern. The Scrum Guide clearly states that each sprint must produce a potentially-releasable product increment. To me, a Sprint Zero is reflective of a "big design up front" approach (we can't start working until we figure some stuff out).

There might be some prep work needed (create first few PBI's, establish Scrum Team, etc.), but don't call it a sprint. Call it a kickoff effort, whatever you want, but as soon as you are able to start working, START.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up