Over my career I’ve seen more projects fail due to misuse of user stories than any other practice commonly used on agile teams.

You probably already know that user stories are just a simple format for writing requirements on scrum or agile teams.

Today I want to help you avoid some bad advice I see out there about what user stories are and how they can help (or hurt) you.

Why User Stories Were Created

Before agile methods for development, teams wrote big documents describing the design of a software product before building it.

Since the project was designed up front, it was also funded up front.

The more detailed the documents, the better the estimate of costs.

But companies were finding that by the time software was done, customers wanted something different.

Early leaders in the agile community came up with a great idea to only build and release a little bit of a software product at a time.

This would let the team change their mind about what to build once the project started.

Since it takes a long time to document something you might not build, the industry began using user stories to describe requirements.

The thought was to describe just enough about what value a feature offered to the customer that it could be prioritized.

The Pressure For Traditional Budgeting

But some leaders and business owners still wanted to know exactly what they were getting before approving budget.

They forced people to estimate and scope every idea anyway because they were too scared to fund a team without knowing exactly what they were getting.

Many agile coaches tell teams that a user story is just a placeholder for a conversation.

Once the team starts working on it, they’ll talk with the customer or Product Manager and get the full details.

The problem is, once this conversation was held, many additional details emerged.

And this caused the estimate to go way up.

With Non-Agile Leaders, You Need More Than User Stories

If your stakeholders (product managers, customers etc.) are focused on cost, you are much better off creating detailed acceptance criteria that describes a user story in detail before you give out any estimates.

Acceptance criteria reads like a test script and describes exactly how someone can use the software, or write an automated test, to verify it’s done and works right.

If you don’t have acceptance criteria, the rough estimate you give out for a user story will change.

And every time it does, you’ll lose trust with your stakeholders because you’ll look like you estimated wrong.

So match the level of detail in your design and requirements on your project with your stakeholder's tolerance for uncertainty.

If they are focused on costs, certainty, and predictable deadlines - writing only user stories and committing to estimates without acceptance criteria is foolish.

It’s like committing to a waterfall project with 10% of the documentation necessary to really estimate it.

Visit my site to watch the full video (or listen as a podcast):

📺 Watch or 🎧 Listen