Home Blog Agile How to improve productivity in agile scrum teams

How to improve productivity in agile scrum teams

Agile working is about flexibility, responsiveness, and balancing user and business needs. Consequently, agile frameworks – such as scrum – have achieved widespread mainstream acceptance and use in the software development industry. According to the Agile Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams,” and, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

How to improve productivity in agile scrum teams

Table of contents

Agile software development relies heavily on teams and team productivity for success. But how do we define agile productivity, how do we measure it, and – maybe most importantly – how do we improve productivity in agile scrum teams?

Let’s look at some agile metrics and the factors that influence agile and scrum productivity…

Agile metrics – how to measure agile productivity?

Metrics can be tricky. Nobody wants their performance to be driven or judged by statistics alone. Yet without some form of objectivity any measurement of performance risks being purely anecdotal or opinion-based. The challenge is to give the team some kind of objective indicator of how they’re doing, without encroaching on their agile self-organization and freedom to make decisions. The following selection of agile metrics gives an insight into scrum team performance.

Sprint burndown charts

Scrum teams work in sprints: short periods of time with specific goals that result in a fresh product iteration. At the beginning of each sprint, the team agrees the work from the project backlog it will complete. A burndown chart is a visual way of tracking the amount of work done over time, as the sprint progresses.

Product/Release burndown chart

Where a sprint burndown shows progress during a single work period, a release burndown chart tracks team activity on a longer scale, incorporating multiple sprints. Agile teams are quick to pivot, changing project priorities in response to changing circumstances. Sprint burndown charts usually show a consistent downward trajectory, as work is completed. A product burndown chart reflects changes in priority (usually associated with additional or different tasks being added) to give an accurate ‘bigger picture’ perspective.

Velocity/Speed

Velocity is simply how quickly the team completes work during a sprint, often measured in work-hours. This metric feeds back into the planning and forecasting process. Velocity gives an indication of how quickly the team is likely to get through the remainder of the project backlog. Velocity can be used to track a new team’s development (they speed up as their collaboration improves), show whether ongoing performance is consistent or not, and act as feedback on changes to processes or ways of working (faster indicates the change was an improvement).

Cumulative flow diagram

Moving on from daily or sprint updates, the cumulative flow diagram is a representation of the project as a whole, showing the user stories that have been created, are currently being created, and are waiting for work to begin. A big advantage of a cumulative flow diagram is that it monitors the work in progress (WIP). If the WIP begins to grow, that’s a warning sign – perhaps that tasks are taking too long, that the product backlog is getting out of control, or that there may be a bottleneck in the team’s workflow.

The advantage of using such metrics is that they act as early warnings when the project is at risk of derailing. Examples of warning signs are:

  • The team regularly finishes sprints early (the team isn’t committing to doing enough in their sprint planning).
  • The team is missing sprint goals (committing to too much).
  • The work is ‘burning down’ but is frequently ‘topped up’ as priorities change and features or tasks added (this is potentially time to revisit the original project goals and assumptions).
  • Velocity is irregular, possibly a warning of inefficient work estimation by the team.
  • Growing levels of work in progress may indicate the team is not closing issues that are no longer relevant.

These are not the only metrics for scrum team productivity. Others may be less agile-related but still be relevant to the design and development of digital products, such as number of bugs or defects discovered (both during development and after release), level of technical debt incurred, and the number of requests from users for support or help.

How to increase productivity in agile team

8 key factors influencing agile team productivity

Metrics and measurements are important but what can you do if those metrics begin to show low or falling agile productivity? What are your potential productivity boosters that will impact on the team’s work?

1. How big is the team?

Scrum development teams are self-organizing, working together with stakeholders to identify and deliver project priorities. Scrum comes with a range of tools and techniques to facilitate this kind of productive independence (for more on the benefits of self-organization, check out our article on why we don’t have project manager roles at Boldare!) Team size is an issue. Too big and the decision-making process slows down, communication is strained, and time can be lost in lengthy discussion. The ideal is a team of three to nine people. If the project is large enough to need more people, e.g. you’re building a range of products and require a bigger team, consider using Nexus Scrum which can be used to coordinate multiple scrum teams.

2. Don’t take shortcuts with the product backlog

Clarity on what needs to be done and the order of priority for development comes from the product backlog and user stories that the team puts together. Insufficient detail in user stories or the backlog leads to uncertainty and a lack of joint focus in the team. Better to spend a little extra time working through the product vision up front and creating user stories with enough information.

3. Keep everyone goal-oriented

Acceptance criteria for product iterations and definitions of done are critical for productive agile working. When the whole team is involved in discussing and agreeing these key outcomes, it is focused on delivering the right work. Acceptance criteria influence not only the design and development work but also the project’s testing strategy, ensuring that the right factors are checked before work is signed off.

4. Meetings, meetings, meetings…

Regular meetings are a key feature of agile working and the scrum framework. Sprint planning meetings should be ambitious but realistic, focusing the work of the sprint to come on the project’s leading priorities. Sprint reviews and sprint retrospective meetings keep the work on track and enable the team to look at the project from the outside, ensuring the process itself is working to the team and project’s benefit.

You might be also interested in the article:

Guide to Efficient Sprint Review Meetings

Guide to Efficient Sprint Review Meetings

5. Transparency

People work better when they’re not in silos. A person who not only knows what they’re doing, but also what their teammates are doing and how that relates to and impacts on their own work can see the bigger picture. That perspective leads to better decisions, better quality products, and more efficient teamwork. That transparency includes openness about the metrics and measures in use (put those burndown charts where everyone can see them!) but also a common understanding around priorities, roles and skills. At Boldare, we have worked with a policy of radical transparency for some time now.

6. An attitude of continuous improvement

In teamwork, mindset is everything and a mindset of continuous improvement is hardwired into agile working; as seen in the final statement of the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” This links back to the use of sprint retrospective meetings to constantly scrutinize and improve the way the team works. It goes further. When a philosophy of continuous improvement (including the belief that improvement is always possible) is embedded in the team, it is constantly searching for more effective (and productive!) ways of working.

7. Remove barriers and obstacles

External factors, unexpected interruptions and unforeseen problems are normal occurrences in any project. Part of the role of scrum master on the development team is to support, guide and facilitate the development process, including using their scrum and agile expertise to anticipate and head off likely issues. The more issues that can be spotted before they arrive, the less time the team wastes on non-productive work. This can be especially true when working on scaling an existing product – while the team is working on the new or improved features, the product is still in use and users are flagging up fresh issues.

8. Ensure the team is equipped with the latest tools

How does the team communicate? How does it manage and keep track of tasks and priorities? Are your developers up to speed with the latest development tools for integration, tracking changes, etc.? What about the latest frameworks and development practices? Visioning, product backlogs and sprint planning help the team know what to do, but do they have the best tools to achieve that goal?

You might be also interested in the article:

Standard remote tools in a non-standard way: tips from #BoldareTeam

Standard remote tools in a non-standard way: tips from #BoldareTeam

Non-productive approaches in agile development teams

Having outlined the key productivity factors, it’s worth flipping the perspective and listing a number of ‘no-no’ behaviors; often these are attempts at short cuts that end up costing you more time or resources.

  • Setting unrealistic target dates or deadlines as ‘motivation’.
  • Agreeing sprint goals that are too ‘easy’.
  • People being overprotective of their specialisms or areas of expertise.
  • Putting off tackling problems or defects in order to meet a deadline.
  • Seeing changing circumstances or requirements as a problem.
  • Not keeping the product owner or other stakeholders in the loop.
  • Being distracted by interruptions or non-goal-related issues.

How to improve productivity in agile? Summary

The agile philosophy and frameworks such as scrum have productivity built-in. Like any other ‘system’, you can go through the motions, have all the right meetings and so on, and still work inefficiently and be missing deadlines. To maintain high levels of productivity in your agile teams, first you need to agree exactly how you will measure that productivity – define it in concrete terms using specific metrics. Next, while the Agile Manifesto paints a clear picture of the ideal agile development team and project, you need to consider the factors that determine whether that team and project operate productively or not: including the attitude of the team, the systems that fit the project, and how transparently they are used.