Snow Plowing in Agile and How To Prevent It

Just like snow plowing is not a fun thing to do, snow plowing in agile isn’t as well. In fact, it can feel like a complete disaster. It’s really a challenge in software project management.

Snowplowing works in a way that the snowplows blow the snow on the side of the street. However, if you are at the end of the street or if there is a lot of snow, they are pushing the snow forward. Doing that, when taking more and more snow, the truck needs to do even harder to remove the snow from the street. 

In this article, we are going to clean some snow and make your roads (projects) cleaner. 

What the heck is snow plowing in agile?

Snow Plowing in agile is a heritage from the waterfall principle that refers to the buildup of work that has not been completed in a timely manner. It is continuously pushing the future work forward to make room for ongoing work. Snow Plowing in agile happens because delivery dates are fixed and predictable which often cannot come true. In fact, it results in delays in project management.

Even though traditional project management offered new ways of managing the projects, the problem with backlog stayed the same. That is a reason why some find agile insufficient. Plowing in agile, therefore, has an impact on deliveries in time, project costs and can present the organization as unable to meet the demand. 

What is actually going on? 

Snow Plowing in agile is not happening on the streets, but in your Product Backlog. After the first sprint, there is no or very little hidden work and it is easy to mark work as done. However, after a couple of sprints, there are more dependencies and complex work. As a result of that, there are more “Hidden Stories” and hidden work that has to be done. 

Since it’s more complex and heavier, you leave them for future iterations. 

Eventually, sooner or later you are going to need to work on that hidden work. When you are about to solve these hidden user stories, you will need to move planned stories forward. You postpone them in order to deal with leftovers. This is making the effect of snow plowing or making room for a backlog.

Further, even if you don’t have any leftovers but you keep checking the backlog to make sure it matches the plan can also cause snowplowing in agile. 

How to prevent snow plowing in agile?

Start with small steps

When you are planning sprints, try to keep expectations small for the first sprints. Instead of expecting a lot of work to be done in the first sprint, focus on understanding the big picture. In the beginning, it is more important to understand the common goal and practice new skills needed for the project. 

Learning from each other about the business domains and different technical and interpersonal skills can also be helpful. Eventually, the end of the sprint may not bring much of a finished work but you will learn the significant capacity to continue good work. 

Keep backlog flexible 

The amount of work that is left is not fixed. Have in mind that it is not a fixed amount of tasks but just a direction of what has to be done. It is more like a group of planned experiments that can be easily presented in the WBS chart.

At the same time, it is not answering the question of how it should be done. Also, it is very probable that you will add some new things to the backlog as the project is developing. Another possible scenario is that you will delete some things from the backlog as the project is changing. 

While developing and learning about the product, you can realize that the value can be delivered with a few of the backlog items. Then you will want to prioritize these items to deliver the biggest bang for the buck. 

All things said, the product can be finished much sooner or much later than in initial planning. 

Make it DEEP

Leaving the possibility to change the backlog makes it emergent. Emergent backlog is one of the four characteristics that a good backlog should have according to Roman Pichler. He uses the acronym DEEP to explain key attributes for your product backlog. They are the following: 

• Detailed Appropriately. Parts of the product backlog that have to be finished should be easy to understand. Everyone in the team should understand what their assignment means and what is required from them. Stories in ongoing sprints should be explained detailly, white stories in far future can be described with less detail. 
  
• Estimated. The product backlog is not just a list of future work. It is more like a tool for planning future tasks and understanding them in the process.
  
• Emergent. A product backlog is not fixed and static. While developing, it is normal to change the backlog. During the process, you will add, delete or prioritize some stories and requirements in the backlog.
  
• Prioritized. User stories and requirements should be organized in a way that the most valuable chunks of work are on the top of project hierarchy. By creating hierarchy, the team is able to maximize the value of the product that is developing.

Get ready for a change

Even though it seems like there is not much to change after a couple of sprints, it is not true. You can always learn some more things, new skills or technology to make something. Also, a customer can always ask for scope creep.

It’s a good practice to leave room in one of 6 sprints. Graphically, the planned workload might look like this for 6 sprints when planning, even for an experienced team.

Replan project using real data 

One more way to avoid snow plowing in agile is to plan further project phases with the data from previous sprints. Relying on old data was one of the problems with the waterfall model. After you plan your sprints, it is important to replan them after you have relevant data.

Once your team has completed one sprint, they can measure their sprint velocity and forecast upcoming sprints. That will also help to make a better estimation of their backlog. To make it even more relevant, if possible, they should re-forecast the remaining backlog after they complete every sprint. 

Don’t misinterpret agile as an easy way 

Many developers mistake agile as an easy way to make things. Step by step doesn’t mean you will go a shorter way. It means you will be focused on each task separately. Agile doesn’t help you to finish projects faster. In fact, if you don’t pay attention to written project requirements, it can even make your development longer. 

To Wrap Up (The Snowman) 

For all the mentioned advice on how to prevent snow plowing, you need a project management tool that will make it easier for you. Most project management software can help with that, but the question is – how much time does it take to do it? 

JadeALM helps you to streamline the development process in a simple way and quickly. It is one of the most developer-friendly project management software that also offers WBS. With WBS you can track project hierarchy and have an overview of total backlog and prevent snow plowing in agile. 

Make sure you don’t slowly plow but instead use that snow to make a snowman! 

Try to do it with JadeALM. Or sign up for a demo to learn more about our tool. No strings attached, we promise. 🙂