Stop the Sprint Slop and Shot Your Zombie Stories in the Head


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”.

zombies“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.

slopHowever, 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.

When it Comes to Software Development – Size Matters

size matters

Sorry for the tongue-in-check title, but when it comes to software development the size of the teams does matter. When I talk to people about good Agile teams, especially good scrum teams, I talk about five attributes – size, co-location, dedication, stability and cross functionality. I also tell them that if we have to make compromises my preference is to make them in reverse order (ie compromise on cross functionality first, then stability, etc. – not that we want compromise). This means that optimal size (7 +- 2) is the most important attribute. Why is this so important?

One reason is that studies have shown that small teams are much more productive than large teams. One such study was conducted by QSM on 564 projects (from their database of over 4000) titled Top Performing Projects Use Small Teams. I urge folks to check out the entire study, but what is most telling is their conclusion:

To complete projects of 100,000 equivalent source lines of code… they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

In this study small teams were 5 or fewer and large teams were 20 or more so basically you can pay for 4X the number of people, but you won’t get 4X the productivity.

Tug of WarOther studies have shown that as the size of teams increase that the effort for each individual decreases, even when the people are engaged in physical tasks such as tug of war. This curious phenomenon has a name, the Ringelmann Effect. In addition to other things:

Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.

According to Ringelmann, there are two main reasons for this effect – Loss of Motivation and Coordination Problems.

Two Pizza TeamsThe antiquated notion, borrowed from a physical and mechanistic view of software development, that adding people to knowledge work will increase productivity and result in faster software development is still prevalent in many companies, but there are a few software development companies who understand the importance of team size. Amazon, for example, has the concept of two pizza teams. If you cannot feed a team on two pizzas then it is time to split into smaller teams.

The issue of communication (Ringelmann’s Coordination Problems) is alleviated by the two pizza team rule because the number of communication channels increases exponentially as more people are added to a team. This is often described by the equation n(n-1)/2 where n is he number of people on a team. So for teams of 5 (like in the QSM Study) there are 10 communication channels (which is easily manageable) while for the large teams of 20 there are 190! Obviously 190 communication channels is very difficult to manage.

Communication channels would not be a problem is software development was merely a mechanistic activity (as it is all too often mistaken to be), but because software development is a knowledge activity that relies heavily on communication and collaboration, large teams are no a good idea since all the productivity that each new member would bring is easily cancelled out by the additional communication channels (not to mention the attendant loss of motivation).

In my own consulting I have suggested that the simplest way to double productivity of large teams is merely to break it into two smaller teams. My own experience in employing this technique has resulted in a large increase in overall productivity and quality.

As one begins to understand that software development is a complex, knowledge worker activity, one begins to understand that the most important aspect of producing high quality software is communication and collaboration. Communication (and motivation) is optimal when teams are small – so in the end, size does matter.

Predictability and The Gold Standard

I am often asked as an Agile Coach when I know that I have been effective at my job. The answer is simple- my work as a coach is done when the team in question is capable of being predictable.

And what, you may ask is predictable? For me it is a team that is capable of consistently delivering 90% or greater of points that have been planned for an iteration. I have given this capability a name. I call it the Gold Standard.

Continue reading “Predictability and The Gold Standard”

Larry’s Top Ten Agile and Scrum Myths

Top ten agile myths - Larry Apke

Top ten agile myths - Larry Apke

I gave the Larry’s Top Ten Agile and Scrum Myths talk to the Java Users’ Group in Phoenix recently and people have asked me what the top 10 myths are. I have posted a copy of the powerpoint, but for quick reference, I have listed below.

  • Myth #1 – Agile is a Framework/Methodology
  • Myth#2 – Agile Means No Documentation
  • Myth#3 – Agile is Less Disciplined / Easy
  • Myth#4 – You Can Achieve Agility Without Organizational Change
  • Myth#5 – Agile is Scrum
  • Myth#6 – Scrum Will Lead to “Hyperperforming” Teams
  • Myth #7 – You Must Get 100% of all Stories Complete or You’ve Failed
  • Myth #8 – Scrum Master = Project Manager
  • Myth #9 – We Can Do Scrum Without a Product Owner or Many P.O.s
  • Myth #10 – With Scrum We Can Make Changes Whenever We Feel Like It

Now feel free to rip into these as you wish!

Larry Apke

Larry’s Presentation to Java Users Group

Last night I had a wonderful experience presenting to the Phoenix Scrum Users Group on Larry’s Top Ten Agile and Scrum Myths. It was a very friendly audience and there were a great number of comments and questions from folks representing the whole Agile spectrum.

I have uploaded my PowerPoint file of the presentation for those who are interested.

What Agile Processes and Diets Have in Common

I have spent a great deal of time lately reading blogs predicting the end of Agile. There are a lot of good people making a lot of good points but I think that there are some major problems the arguments predicting the end of Agile.

There is a very real tendency for people to confuse Agile (the philosophy) with Scrum (a process created to achieve the principles of Agile). Agile is only 16 statements – 4 values and 12 principles – nothing more. Of those 16 statements I am sure that there are some who would argue against them, but these would be a fringe element. Don’t believe me? Follow the links above and see which, if any, a rational software developer or business person would disagree with. You can disagree with them, but principles, in and of themselves, cannot fail.

Continue reading “What Agile Processes and Diets Have in Common”