By January 26, 2010

Scrum Sprint Backlogs That Cover too Much and Are Not Thinly Sliced Enough and Have Spreadsheets Attached and Have Non-Specific Things Like Fix Everything On This Page

One of the common scrum smells I have noticed are sprint backlogs that are too big and not specific enough.  When we use the slicing of a cake analogy, these backlogs are the pieces of cake so large you can't eat them in one sitting.

Identifying the Fatlog

So how do you identify a fatlog?  Here are some methods of identification.

  • If your backlog has any kind of spreadsheet attached, it might be a fatlog.
  • If your backlog item uses the words “and” or “but” more than twice, it might be a fatlog.
  • If your backlog item requires you to scroll to read it all, it might be a fatlog.
  • If your product owner has to summarize the backlog for you, it might be a fatlog.
  • If your backlog item contains non specific or encompassing words like “all”, “any”, “every”, it might be a fatlog.

Basically fatlogs are entire features masquerading as iterative slices of functionality.  You'll know when you see a fatlog, because you will not feel like you have a clear idea of what is needed to call it done.

This only applied to backlogs that are in a sprint.  When they are in the product backlog, it is actually a benefit for them to be large and not well defined, because it prevents wasting time defining something that may change.

Why are fatlogs bad?

Fatlogs are the opposite of iterative development, fatlogs are in essence mini-waterfalls.  One of the main purposes of Scrum or Agile in general is to break things up into small slices of functionality which can be iteratively developed.  The benefits for doing this are many, such as better estimation, adapting to change faster, and biting off pieces of the system than can be easily chewed.  The inability to truly think in an agile mindset usually results in the creation of fatlogs, which are attempts to take the waterfall process and miniaturize it instead of building incrementally.

The problem is we lose all the benefits of incremental development when we create and try to implement a fatlog.  Details are very important to the iterative process, as is feedback.  When we try to design and build an entire feature up front, without iterations, we are missing out on both.  Sometimes we get it right, but more often than not, the customer has not even had a chance to think in detail enough about what they want, so we inevitably get it wrong.

The most compelling reason why fatlogs are bad, in my opinion, has to do with the central theme of this blog: complexity.

You can not build what you do not understand.

Exercising the fatlogs into shape

So what do you do when you see a fatlog?  There are many different approaches that work, and they depend on the situation and the backlog itself, but the key idea is to break it down.  I am of the camp believing that the smallest piece of actual business functionality possible is the right size of a backlog.  I would rather have my backlog items too small than too big, since the team can at least achieve progress and gain momentum when they are completing small backlogs which are part of a central theme of functionality.

Let me give you a little example, let's say you have a backlog that says:

As a person setting up my workout I need the workout screen to only display the choices indoor or outdoor instead of the 20 choices it currently displays.  Also the indoor selection should cause a page to come up where the user can enter the type of indoor workout and start their workout.  When selecting the outdoor selection, a screen to pick their current location on a map should come up and allow them to start their outdoor workout.  This needs to be done so that I don't have to select from 20 different selections that I don't want, and that I can select the right workout and start my workout.

We can easily break this into 3 distinct vertical slices through the system.

  1. Changing the drop down on the workout screen to only have 2 choices, indoor or outdoor instead of 20.
  2. Making the indoor functionality work correctly.
  3. Making the outdoor functionality work correctly.

It is easy to see how much easier each backlog item becomes when broken down this way.  Estimation is more accurate and the feeling of making progress is greater.  Some people may argue that the business functionality is worthless until all 3 are done, and that each one individually does not represent something that can be released to the user.  That is a fair statement, but if you were going to get the backlog done as, say, 5 effort points, and individually it breaks down to 1, 2 and 2, then keep them in the same sprint and what difference does it make?  But if you break it apart and now the estimate is 2, 3 and 3, you have just increased the accuracy of the estimate because you made it easier to estimate the smaller pieces to give you a more accurate estimate of 8 effort points.  My point here is that it shouldn't matter if you break a backlog apart into smaller slices, so long as the slices are true vertical slices. The decision to keep a portion of functionality together as a releasable item is different from the decision of how to break apart backlog items.  Tying these two details together prematurely is a major cause of fatlogs.

Breaking down complex things into smaller simpler things is what software engineering is all about.  Whenever I see a fatlog I try to think how I can break this into a smaller obtainable goal that still is a complete slice of the system.  If you can answer that question you can whip your fatlogs into shape!

About the author

John Sonmez

John Sonmez is the founder of Simple Programmer and a life coach for software developers. He is the best selling author of the book "Soft Skills: The Software Developer's Life Manual."