User stories when starting from scratch
inna last edited by
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?
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.