Itty-Bitty Pieces: Working with Really Small User Stories

Previously, I said that one way for teams to get better quickly is to make their User Stories smaller. 3-5 points, half a sprint or less. This is a great way to improve your team’s overall output, quality, and flexibility.

But sometimes, User Stories can get too small.

When I was still very new to Agile, I attended a workshop where they talked about writing your User Stories super small. Their team had shifted from counting Story Points each Sprint to the counting the number of completed User Stories implemented. I thought this was super cool! It reminds me of how Henrik Kniberg talks about User Stories in his popular video Agile Product Ownership in a Nutshell – this is a fantastic video, but the way. Check it out of if you haven’t seen it.

As a new Product Owner, I was completely enamored with this idea of making my User Stories super small. As tiny as possible. My goal was that every User Story that my team worked on could be implement and demoed in three days or less. So I broke each of my work items down into the smallest pieces I could manage before presenting them to the team for sprint planning.

We were working on a web site portal. Here’s what some of these stories, specifically around user login, looked like:

• Add a login button: As a portal user, I want a way to login onto the web site, so that I can access my content.

• Add usernames to the database: As a portal admin, I want to see the list of users on the web site, so that I can administer them.

• Connect the Login button to the Username database: As a portal user, I want the login to connect to my username, so I can reach my information.

Et cetera.

Each of these “User Stories” could be implemented and demonstrated, but none of them actually told a complete story, and more importantly, none of them on their own offered any value. Yes, there are “so I can” parts to all those value statements, but they’re barely connected to the work items. A portal user needs more than just a login button to access their content. An admin needs more than just a list of usernames to administer users.

There is a reason Agilists chose the term User Stories. They should tell a story about what the user wants, linking the description of the work with the description of who it’s for and how and why they will use it. It should be just big enough to be worth demonstrating when it’s done, but it must also tell at least a piece of the user’s journey with the product. A vital part of a product’s business value is what users can do with it.

My team complained when they saw my tiny “User Stories.” Some would have taken less than an hour to do, including TDD! I thought that was great – it meant we could get a bunch done in a sprint, right? They also complained they were too specific – did it have to be a button? Could it be a link? I didn’t especially care, I said, as long as the user could log in and we could control who had access to the information on the web site.

Okay, they said, and all that was fine. They understood the need for login functionality. But why this specific implementation?

That was the start of a great conversation. It led me to shift my focus from what the team needed to build (button, database, etc.) to what it would be used for: why the work was needed. It led my thinking about “small” to shift from physical things (a button on a web site) to the first step of the user’s journey (accessing the web site). I also ceded control of the implementation to the team, since at this stage I didn’t care how it was implemented. Which was me accidentally learning another wise User Story practice: let your team decide the implementation and refine it later if you need to.

It had become a real User Story. Not as itty-bitty small as I’d originally envisioned, but still tiny enough to complete in an afternoon.

• Create a user access point on the web site. As a portal user, I want the ability to access the portal, so I can see any of my information that’s stored there.

The “information” didn’t even need to be complicated yet, just their username. But from there we could easily expand from that initial step and continue the user’s journey with our product.

There are other challenges to writing very small User Stories, like trying to apply the popular INVEST model. INVEST stands for Independent, Negotiable, Valuable, Estimate-able, Small enough to fit within a Sprint, and Testable. INVEST is a great way to make sure you’re including everything important in your User Stories, but it’s also often a challenge to cover every element. And some elements of that model are really difficult to fit into very small stories, particularly “independent” and “valuable.”

But that challenge is also a good safeguard. If every time you make a User Story smaller, you’re losing some element from INVEST, then add more scope to the story until it does match INVEST. Then try slicing it up a different way and see if you get better results. (Here's a great article on ways to split User Stories: How to Split User Stories | Agile For All)

It can be very hard to match INVEST on every story until you’ve had a lot of practice. So focus on getting as many as you can, where you can, and practicing. But there’s no value in spending all your time writing absolutely perfect User Stories. The value is in delivering your product! Get your User Stories just good enough for your team to implement them quickly and at high quality.

So, to sum up, to write the shortest possible User Stories that still are User Stories:

1. Make your User Stories as little as you can, so long as they explain at least a small part of the user’s journey, and no smaller.

2. Apply as much of the INVEST model as you can in each one.

3. Don’t stay up all night perfecting them.

#agilesoftwaredevelopment #userstory #backlog #productowner #fishingwithdynamite