User stories when starting from scratch

Question

A user story is defined in quite a few ways, but roughly always like this:

User Story is a small (actually, the smallest) piece of work that represents some value to an end user and can be delivered during a sprint.

For some features, this is obvious. It could be something like a new filter or the ability to sort a product list. But what when it's less obvious - particularly what if you are building something from scratch?

For a new application (no matter if it's a mobile app, web app, or anything else) the smallest piece of work that represents some value to the end user, is still quite a large piece of work. You need to setup a UI (even if only basic), create a new database, add the most basic functionality, etc. Way larger than what I would consider a user story.

So how do you use user stories in the very first stages of developing something new?

Answer 1

One user story will not give you a releasable product

that represents some value to an end user

This clause is added to get over the mindset of previous Waterfall practices. Doing analysis alone or doing design alone is not a valid user story. The story must result in some shippable code, which is what represents value to the user.

can be delivered during a sprint

This clause is added to keep stories small so that they can be fully completed within a sprint.

What you are looking for is what is popularly known as a Minimum Viable Product (MVP). MVP is a product with just enough features to attract early-adopter customers and validate a product idea early in the product development cycle. There are many examples of MVPs such as this one about Zappos.

So, go ahead and formulate your MVP and write as many user stories as you need for that. You can read more about splitting user stories into smaller ones, writing conditions of satisfaction... etc here.

Answer 2

Don't get hung up on writing the perfect user story. Instead, if this is a new product that you are building from scratch, focus instead on:

• defining a big picture of what the product should do;
• split that vision into pieces, actions, and actors (you can use a technique called User Story Mapping for that, and create epics and user stories);
• place these epics and stories in a backlog and prioritize and order them based on what would bring the biggest value first;
• do a refinement meeting to split the top of the backlog in finer pieces;
• figure out how many of those pieces from the top of the backlog you could fit in a sprint (if you are doing iterations) or in some reasonable amount of time. This is the real reason for why you want to split user stories in the "smallest amount of work" or for them to have the INVEST property, so that you deliver working things at a fast and constant pace.
• at first, the user stories you identified might have to be something built with mock data, or wireframes instead of a fully functional UI, or just a minimally working user flow, etc. The idea is to have something that works and can be shown to stakeholders in order to collect some feedback so that you learn and use the learning to figure out what to build next. As the accepted answer mentions, the purpose is not necessarily to build a releasable product from the beginning. If you have a complex product which requires some features to exist to be usable, you might not get something fully functional in the first couple of sprints, but you can build something nonetheless.
• rinse and repeat to incrementally add functionality on top of that and get some versions that you can release to users.

Answer 3

Some examples of "sprint 1" stories for an e-commerce site:

• As a new customer I want the ability to sign-up for an account so that I can purchase
• As a potential customer I want to browse a catalogue of products

Some examples for an HR application:

• As an HR user I want the ability to login
• As an HR user I want to retrieve an employee's details by employee number

To create some basic tables to support these stories only takes an hour or two. To create a UI takes a little longer but certainly something perfectly usable can be achieved in a 2-week sprint. These are very small increments of value but are nevertheless essential to the product.

Another relevant point is that starting completely from scratch is fairly unusual. Typically you have existing data, services, code libraries and other technical assets that you can build on.

Answer 4

Part of the problem is defining what "delivered" means. Does it mean integrated and demonstrated? Does it mean deployed? Does it mean that a feature flag has been enabled? Depending on the context the team is working in, it could mean any of these. The definition could also shift over time as the team refines its capability to design, develop, test, deploy, and operate the system.

There are also ways to slice the work in different ways that can better enable demonstration and rapid feedback. You don't necessarily need an end-to-end experience to get feedback. Using the example of "sort a product list", you can demonstrate a user interface on a particular screen or page that has data pre-populated in the front-end. You could take it a step further and have the front-end load data from a backend, but use an easier-to-read data source like a text file to stub out the API between a front-end and back-end component. Or you could take in another step further and have pre-seeded data in a database. Anything else could require the ability to add and/or edit data in the database, which would likely be other stories.

I wouldn't recommend using stories any differently early than later. I would realize that there may be other types of stories than user stories, like different kinds of technical enablement stories. A story, fundamentally, is just a placeholder for a conversation. User stories focus on the customer or end-user, but there's no reason why you can't have placeholders for technical conversations about creating databases, APIs, and performance. I would also recommend focusing on tightening the feedback loop, whether that's getting feedback from users on the user interface or developers on the technical decisions to ensure you're on the right path.

Answer 5

I think that it's also fair to say that – "sometimes user stories (and scrum in general) live up to those ideals, and sometimes they just don't." The concept of a "user story" is really just a guide to help you break down the work into small units, and to tie those units very closely to things that the end-user will actually observe. But, especially in the early stages of a substantial project that's being started from scratch, sometimes that doesn't make much sense. And, that's okay.

For instance: building a house. What's the "user story" of all those carefully-placed blocks and pieces of PVC piping that are sticking up all over the place? Well, there are carefully-made house plans, but not too much of a "story." All of the work that you see will have an eventual purpose and absolutely must be placed there now, and very-precisely where they are. But "user stories, alone" would not be a good way to plan or execute that project in these early, foundational stages. Instead, you very much have a "waterfall," planned well in advance by a licensed architect. Because that's what makes the most sense at this point.

The metaphor of "user stories" is still very useful and important, even in early stages, but they can't strictly guide the project until the foundations have been laid.

Answer 6

The problem you are encountering is that you are starting with a solution in mind. Then you are breaking down that solution into its pieces. The problem you are raising is not really one with user stories. It is: how do you solve a piece of a user need quickly so you can learn more about that need.

Last week, I finished a market poll app in 5 hours. I didn't use a User Story, but if I did, it would look something like this:

As an analyst, I would like to present potential customers with 2 statements about product capability and have them select the one that resonates most with them so that I can see what capabilities are most important to my market.

This was database, logic, UI, deployment.

We used it for an internal demonstration the next morning and it is potentially shippable in the sense that if I chose to really use it with read customers, I could.

I've worked with multiple teams that deliver new apps in as little as a day or two. Now, there may be many things in your environment that keep you from achieving that and you have to decide if being able to deliver that fast gives you benefit that is worth the cost of enabling that in your context. But it absolutely can be done.