Advertisements
Posted by: jsonmez | 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 can not 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 can I 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!

Advertisements

Responses

  1. I think a bit of precision is needed here.
    Are you talking about the sprint backlog? I so, yes, by all means, cut the cake so you don’t choke in the big fat chunk.
    If you were referring to the product backlog, though, I will disagree with you. As you said: “You can not build what you do not understand.”. Which would mean that you have to analyse first and lose the iterativity.

    • Yes, you are absolutely correct. I am talking about a sprint backlog item here.
      For a product backlog I agree with you, you don’t want to define up front what can be deferred later, because your zoom in view of it may change in the future.
      I should have been more specific. There is nothing wrong with having a product backlog of huge scope that is a giant slice of the system or even a whole set of features.
      As the backlog item gets closer to being put into a sprint it should begin to be split up and be more defined.
      And once it is in the sprint it should be a very thin slice IMO.

  2. […] So often the most challenging problems can be resolved with very basic, pragmatic techniques. What do you do to organize your sprint backlogs? Enjoy John’s article. […]

  3. […] I first introduced the concept of a Fatlog a couple of months ago. […]

  4. […] you have a fatlog. […]

  5. […] don’t forget to get rid of all the Blue Whales.  You don’t want any of those on your board, […]

  6. […] Small is Better I’ve talked about large backlogs being fatlogs here and here before, but I’d like to apply that general thinking to more than just backlogs, and talk […]

  7. […] talked about why smaller is better and especially why this pertains to product backlogs, or rather fatlogs, but I wanted to zoom in for a second to one of the most valuable applications of the rule: writing […]

  8. […] too large.  If the smallest iteration of your software is a complete feature, you probably have fatlogs, and you are going to run into […]

  9. […] you have a fatlog. […]

  10. […] also want to look for indications that a backlog might be too large and actually might be a fatlog that will need to be broken down into smaller […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: