One of my loyal supporters last week requested I write an article about “sprint slop” and I am very happy to accommodate any requests. Before I could begin it was important that to understand the request because this particular term is not ubiquitous. A Google search for “sprint slop” returned few links and those returned were associated with skiing and not Agile or Scrum. Nevertheless, I had a good idea of what was meant by the term “sprint slop” and was able to isolate the meaning to refer to those stories that move from sprint to sprint and are not completed. I have also referred to such stories in my agile coaching practice as “zombie stories” since the never seem to “die”.
“Zombie stories” are a great indicator of team maturity, the origin of which is mostly related to either stories that are too large, poorly written and poorly refined or teams that are pressured to plan more in a sprint than is possible or are victims of “false” dependencies. In most cases, the root cause of the above is related to poor understanding of Agile Scrum from the business, particularly in relation to expectations of the product owner and the amount of time that is necessary to devote to the processes associated with the scrum framework.
The scrum framework consists of ceremonies for each sprint – daily standup, planning, review, retrospective and refinement (new term – originally referred to as grooming), which can be broken into backlog refinement and story refinement. If we were to look at the time that is necessary for all of the these ceremonies for a two week sprint (which seems to be the most popular timeframe), we would have something similar to the table below, with the total time between 9.5 and roughly 12 hours:
| Ceremony | Time (in Minutes) |
| Daily Standup | 150 |
| Planning | 60 |
| Review | 60 |
| Retrospective | 60 |
| Refinement | 240 – 400 |
| TOTAL | 570 – 730 |
Refinement of the backlog (and stories) for future iterations is estimated to be between 5 and 10 percent of the current sprint. It is during this time that we gain a greater understanding of the work that we are going to do in the future. In my agile coaching I break the refinement into backlog refinement and story refinement. Backlog refinement consists primarily in story identification, effort and value estimation, and sequencing of the stories – basically understanding the work that will be done in the next iteration. This happens as the beginning of the sprint in anticipation of the future sprint. The story refinement happens after the sequence of the stories is understood and consists of a deeper dive into the stories, one at a time in backlog order, generating a good story description (As a..Iwant..So that), generally understood acceptance criteria (my teams use BDD) and preliminary implementation tasks and estimates that are used for Sprint Planning ceremony.
When I have witnessed “zombie stories” and “sprint slop” it has been generally the teams inability to take the proper amount of time to refine the stories for future work and by not using tasks and hours to better understand the implementation of the stories. I know my particular way may be somewhat controversial since the trend these days is to not do estimates, either for tasks or stories, but in my experience the ability for teams to become predictive (ie complete 90% or greater of planned work) is something for mature teams and tasks and hours are a necessary step to help the team truly understand what they are capable of accomplishing. The detail work forces the team to consider how they will implement and will give the team more information on the true size of stories and places they might be able to break the story into smaller pieces.
In some cases, where the detailed work is done and the team still is unable to complete high percentages of the work, then the problem can be related to pressure from the business. Sprint Planning should be based in reality, but when timeline expectations are placed on a team, their natural inclination is no longer to make estimates and predictions based on their best understanding of the work, but based on the expectations of how much work “needs” to be completed.
The last reason I see for work moving from sprint to sprint is dependencies. Again, this is more an indicator of maturity level and an inability to write proper stories, than actual “hard-stop” dependencies. A “hard-stop” dependency is one where no work can be accomplished unless some other work is completed first. In software development I usually find that these are the more hardware-dependent stories. It is really difficult to deliver working software if I do not have the servers with which to deliver the software to.
However, my experience has taught me that most of the stories teams think are dependencies are, in many cases, not. These I call false dependencies and proper utilization of an INVEST acronym in writing stories will go a along way to breaking these “false” dependencies. For example, if there are two different team working on the same feature, one that is doing the backend services and one that is doing the front end UI work, then there appears to be a dependency of one team waiting for output from another team. This is a “false” dependency. There are two ways to address this issue. First, I can change the teams so that they follow the guidance that all members necessary for software functionality are on one team. Second, I can create three different stories that would allow the teams to operate somewhat independently – one for the service mocking the front end, one for the front end mocking the service and one for integrating the two stories. While not ideal, it allows for much quicker feedback on the work and allows the teams to schedule a chunk of work that they can accomplish in a single sprint. This can even work sometimes with hardware dependencies. I currently have a team that did their integration locally to a laptop while they waited for the real hardware to be delivered. Again, no optimal, but it did represent a way for the team to deliver into an environment that allowed for faster feedback and it is particularly this feedback that is missing from “sprint slop” and “zombie stories.”
One word of caution about team commitment and expectations. When I received my CSM training all those many years ago, I was taught that every story (100% of the work) should be completed by the end of each sprint. I remember the instructor saying something about developers “chopping off their arms” and “banging them on the keyboard” if it was necessary to get the work done. I did then, and still do not, believe that this is what is meant by commitment and have railed against the 100% expectation ever since. As with all things in life there is the ideal and the acceptable. My three boys are all still in various years in school, but my expectation from all is that they try their best to get 100% on every test, but I find that 90% or greater (an “A” these days) is acceptable. I preach the same with my scrum teams. Of course, we plan each sprint so that we can complete 100% of our work, but I find that 90% or greater on a consistent basis is acceptable because it shows maturity in planning and predictability in implementation so that longer term planning is possible.
The thing to always keep in mind is that Scrum is a framework that will shine a light on those things in your current environment and system that are not optimal. Scrum also gives you the framework to continually improve and solve underlying issues. “Sprint slop” and “zombie stories” are merely another example of the systemic symptoms Scrum will shine a light on. If you follow the framework properly it will also give you the ability to fix the underlying system so that you can be “sprint slop” and “zombie” free.
