Now we’re getting down to the nitty-gritty. In this post, we’ll talk about debugging your user stories by making sure they’re just the right size.

Getting Your Stories to the Right Size

From our first post, we learned that creating truly independent stories is a hard skill that takes time to get the hang of, but done right, it opens up the team for fast execution.

Getting stories to the right size makes them easy to understand and easy to estimate, which is agile gold for the team. Small stories are great because they let the team deliver value fast and avoid context switching by packaging requirements in achievable chunks of work. Stories that are small also create predictability in estimation results, which project managers love.

So how do you know if your story is too small or too big?

Too Big?

If your story is too big, the team will tell you. Really.

That’s the first and easiest tip-off, but if you’re still having trouble figuring out how much is too much and you’d rather finesse things first before presenting to the team, here are several tells:

Your requirements span more than half a page of whatever requirements management tool you use.

Your requirements have a lot of qualifiers

— e.g., IF a AND b AND c, then… OTHERWISE IF x AND y AND z, then…

— e.g., IF a AND b AND c, then… OTHERWISE IF x AND y AND z, then… Your story addresses more than one step in the user workflow.

Your story contains all the workflows! Happy path, alternate workflows, all the exceptions… (your user story will be running off the page!).

Your story addresses all CRUD operations for a process.

Your story addresses more than one user role.

Your story addresses more than one or is overloaded with many data types.

Your story addresses more than one business rule.

Your story addresses more than one form factor and/or device.

Your story contains too many unknowns for the team to estimate.

Your story’s going to take a long time to get to “Ready” on the board.

Split those puppies up.