Part 1: How to eliminate waste in a Scrum environment

In this article, I talk about types of wastes, giving some examples and ideas to help you eliminate or, even better, avoid waste altogether.

Part 1: How to eliminate waste in a Scrum environment

Date: 15 March 2017

In my last article, I talked about Lean principles and how Agile can be used to apply those principles to deliver high-quality software.

Here I want to elaborate more on the first Lean principle of Eliminate Waste and give more insight into how it could be applied in a Scrum environment using simple examples of common ‘waste’ that could be generated while working on a Scrum project. My aim is to make it easy for you to identify and eliminate waste around you in any project. You might even do a better job and try to avoid creating any!

Here’s a recap of the seven Lean software development principles:

Figure 1 – Lean Software Development Principles

First, what do we mean by ‘waste’? Waste is anything that doesn’t add real value to the project. When people start losing track of the value added by doing a certain task or following some process, they sometimes start, unknowingly, to generate waste.

In Scrum, there are few time-boxed events that must be transparent and regular. And each of these events has a specific purpose and is essential to Scrum’s success.

Let’s have a quick view of the objective/added value behind each Scrum event before looking into how we can cut down or eliminate waste in a Scrum project:

Figure 2 – Scrum events and their objective as per

One key problem I’ve dealt with and heard repeated by others is that people at some point start to lose interest in Scrum events.

Being part of a Scrum team for a long time can make it easy to lose track of why those Scrum events exist in the first place! Attending the events/meetings – sometimes – becomes more of a routine event that no longer keeps people interested. Try to refresh the team every now and then by reminding them of why we’re having those events. Once you achieve the objective of the event/meeting, wrap it up. The team does not have to hang around just because the room is booked for longer! If any of the team members are not gaining nor adding any value to the meeting, then it might be time to reconsider the value of having them attend the meeting.

If team members start to lose interest in any of the Scrum events, the team has a problem. Try to salvage the situation by:

  • Revisiting the objectives of the event and reminding the team of the value added by completing it.
  • Taking a step back and see if that value is still being delivered. If not, start discussing with the team why this has happened.
  • Then, working with the team to re-focus on delivering that value and achieving the objective behind the event.

After making sure the team is completely aware of the values added and the objectives behind the Scrum events, review the seven wastes in software development. Let’s see how they can easily be managed in a Scrum environment and how we can identify and eliminate them.

Seven wastes in software development

First, let’s have a look at the seven types of ‘waste’ usually generated in a software development environment. This article covers the first two types of waste – ‘Partially done work’ and ‘Extra features’. The other types of waste will be covered in Part 2.

Figure 3 – Seven wastes in software development as identified by Tom and Mary Poppendieck

  1. Partially done work

This type of waste can be easily generated in a Scrum environment, especially if the team started to drop some of the Agile values and Scrum rules – for example, uncompleted stories*’ or ‘underestimation’. If the team committed to finishing a certain number of stories/story points and wasn’t able to complete them by the end of the sprint, this would be considered as ‘waste’.

To work on eliminating such waste, the team should review their processes and make sure they’re being Agile by answering:

  • Are you being transparent at stand-ups? (If so, you might have noticed that some stories are taking more time than what was estimated. Have you discussed any blockage? Have you asked for any required support? Did you warn the business of the risks of carrying on with the story?)
  • Are you supporting each other as a team? Or is each one only focused on their own tasks? Always remember to be collaborative and open to supporting your teammates with different tasks
  • Is the team focused? Or is each team member working in isolation with a separate story? Remember to help with higher priority stories to get them across the line before shifting focus to the next one in line. As a team, you can work on multiple stories at the same time, as long as higher priority stories are kept on track.
  • Have you done the proper analysis and estimation for the stories? There’s no harm in having ballpark estimations. If there’s a big difference though, between the initial estimation and the actual effort done on a story, you might revisit how you estimate the effort it takes you to complete a story.
    • Underestimated stories – especially when this becomes a habit, can cause unnecessary ‘waste’.
    • Poor design can lead to incomplete tasks. Have you considered every aspect of the story including any dependencies or impacts?
  1. Extra features

Have you started working on a story and then found that by the time it was delivered, you’ve ended up with more than expected? Well, that would also be considered ‘waste’! The extra effort spent on developing those extra bits would require extra efforts for testing, from BA’s to capture those extra features – and probably extra time spent with the Product Owner reviewing what was delivered.

So, by looking at it, that wasted time could have been spent on stories already committed during the sprint. And even if there was any spare time left in the sprint, that time could have been used to pick up stories from the top of the backlog (if the team can manage to complete them by the end of the sprint). Of course, the team can always work on process improvements or upskilling themselves as well.

In the case when team members can see a value in the added features, they can always raise it with the Product Owner. It could then simply be added to the product backlog where it can be picked up and properly estimated for future sprints. That’s why constant feedback is a very good example of an Agile development method that could help eliminate waste. By doing development in small incremental steps, the feedback between the Product Owner and the team will occur more frequently.

Remember that the first step to solving a problem is identifying what it is and where it exists. So you can now go ahead and start identifying any waste around you and try to avoid generating any waste yourself!

In Part 2, I’ll cover the more types of waste and how to eliminate them.

*Stories: Product backlog items that are planned to be ‘Done’ in a sprint.

Share Article

Want to know more?

Want to be inspired?

Want to learn?

Want to get in touch?

Share on Facebook
Share on LinkedIn
Share on Instagram
Follow on YouTube