Dependencies in the Product Backlog

A backlog item should be big enough that it's not dependent on any other backlog item to be completed.

photo source

Hopefully, you already know that, and in a perfect world, that's how we'd all live, but the fact of the matter that every new feature is dependent in at least one small way. You can't add in a nifty planning board into OnTime if it didn't already do work item tracking right?

So if dependencies are part of our day to day reality then how do we deal with them? I'll answer that by rephrasing the first bit of wisdom in this post.

A product backlog item should be big enough that it's not dependent on any other incomplete backlog item to be completed.

"But Sean" you'll say "Story #231 is too big to accomplish in a single sprint and it's the next story in the backlog!"

"Then break it down into smaller pieces" I'll reply

"Didn't you just contradict yourself?"

"A bit but here's what I mean straw man"

Once you decide to commit to a very large backlog item you'll probably work on it for the next couple of sprints but you need working, tested software at the end of the iteration, what's more you'll probably want to break it down to make it easier for the team accomplish. Here's my thoughts on the matter.

We decide on Story #231 which is Big, we think we'll need roughly about 3 sprints to get it done so we break it up into smaller logical pieces (ideally 3 pieces, but common sense is the best rule here), all three pieces can be accomplished with a single sprint each and they all get thrown to the top of the priority list since that's where they sat before we broke them up. If they're dependent on each other, then the first one will be prioritized highest, the second is next and so on and so on.

Now we've got one big story in the first sprint, which isn't very helpful at all when we begin working, so we'll break it up into smaller pieces again for the development team. Generally speaking, you should be breaking things up at this point to be small enough for a team member (or paired team) to tackle from beginning to end by themselves within the sprint. From there, the individual developers should start thinking about breaking their own work items down into logical steps (or tasks) which should be small enough for us to see daily progress on the steps completed.

You'll repeat this again until the Big backlog item is completed, then dip back into the backlog for the next item.

The tendency with new Scrum Masters and Product Owners (and even experienced ones) is to look at the backlog and break everything down as soon as we get it. The problem is that now we need to maintain backwards traceability to the parent story (software can help with this but it'd be better to not need it), we have to educate customers on the breakdown of their feature request or bug (they think of them as Features and Bugs no matter how many times you use the word "Story" or "Backlog Item") and we end up making more work for ourselves in the long run (which makes my teeth itch) since the parent item will inevitably change right up until the last second. The solution is to decompose your backlog items at the last possible moment before the sprint.