I am unfamiliar with the ideas behind creating user stories for Agile projects, as well as acceptance criteria.

I was wondering how I could turn any MVP design, like the Basket MVP, into tested user stories.

enter image description here

What, by my assumption, are below-stories?

  • Remove Design
  • Update QTY
  • Edit Design
  • Secure Checkout
  • Chat
  • Promo Apply
  • Product Section

For each ticket, how to add requirements, for example:

  • What are the interactions on the page (e.g. what happens when you click this button?)
  • What would different types of users see?
  • Are there any validations needed?
  • Are there any error messages / edge cases that need to be catered for?
  • Can we break this ticket into smaller pieces?
  • Actually, you are asking the right questions. When you get the answers, you will be building the user stories with those answers. Aug 26, 2022 at 4:48
  • 2
    My first question is: how is it that you have a design, but not requirements? Shouldn't the design be based on requirements? You don't make stories from a design. That is backwards. You make stories. And then, if neccessary, a design.
    – nvoigt
    Aug 26, 2022 at 11:19
  • An MVP is a form of validated learning, not necessarily a salable product. So, you need to turn a lot of this around and ask "Does anyone in the target market want these things? Or do we need to build something else, or target a different market based on what we're prepared to build?"
    – Todd A. Jacobs
    Aug 29, 2022 at 23:10

2 Answers 2


User stories are not implementation-based. Instead, they focus on the user's needs.

For example:

As a new user I want to register for the site so that I can make purchases

As a registered user I want to view the products available for me to buy so that I can decide on my purchases

As a registered user I want to apply a promotion to my purchase so that I get a discount

For each user story we look to add detail as we get ready to start doing the development work. This detail might include acceptance criteria and you may decide to create implementation sub-tasks under each story.

A good guide to the creation of user stories is to follow the INVEST mnemonic.

  • 1
    I like the answer, but I highly doubt that any user wants to register to make a purchase. This is definitely not a user's need. Apr 13, 2023 at 20:47

I think this is great question and one that many people are actually faced with. It's actually a product management question and I agree that a lot of times an example of a user interface is where it all starts. But we have to be careful that that is not where it ends.

Vision Before you start, there needs to exist a vision for the website, and that needs to be communicated with the development team. You might already have this but its worth mentioning as it gives the stories context. For example, is the website B2C or B2B, what do you sell? are you a reseller or marketplace website ? Some essential domain knowledge is important too, so things like what product variations are there ? Include something about your buyers, are they trade ( in which case prices might be ex-VAT ) or general public ? Also talk about how the business makes money, your pricing and marketing strategy, etc.

Users You also need to decide on the types of users you are serving. You might have, first time users, members, admins, high-value, low-value, any buyer, trader etc. This is normally done with the product manager, but the product owner or UX person can do it too.

Features So, assuming you already have all that in place, the first thing to do is to think about the types of stories, you will have business stories ( stuff that the end user sees ) and technical stories ( stuff that needs to be built to support the business stories ). The trick is to start with the business stories. You can organise these stories into features remembering business features can have business and technical stories whereas technical features contain mostly technical stories.

Business Stories So in the business stories, there are some obvious things like "add to basket" and that is another trap, what is obvious and what is not!! I don't know what your role is but you should really encourage the product manager to decide that and write it down.

Now, you can facilitate your PO in writing out some requirements such as

Story: Add product to basket As a [user type], given I have chosen [variation] of product, then I can see the price and add it to my basket.

Depending on your particular domain this story might actually need to be broken out into smaller chunks, for example.

Story: Select product variation to see price As a "general public user", when I am on a product information page, given I have selected a product variation, then I can see the price.

Story: Select quantity after product variation As a "general public user", when I am on a product information page, given I have selected a product variation, then I can select a quantity.

Story: Product in stock As a "general public user", when I am on a product information page, given that the product is in stock, then I can add it to my basket.

Story: Add product to basket As a "general public user", when I am on a product information page, given I can see a price, then I can add it to my basket.

MVP You will end up with a massive list of stories so organising by feature is important. At that point, the product owner will prioritise and define the potential MVP. So for, example, you might not include the "in stock" story in the MVP. This is the first sweep, because we don't have any technical stories.

Technical Stories I normally recommend that technical stories are added after you have a vague outline of a MVP. So now the PO gets together with the development team and technical stories are added. There may well be research stories needed or architecture decisions that need to be captured at this stage depending on the maturity of your system.

Estimates Now all the the stories which are potentially in the MVP can be estimated.

Final MVP This will naturally mean there is an iteration of what can be accomplished in the MVP, so the team decide together, given the constraints in time and skills available what should be the target for the MVP.

et voila, you have an MVP with prioritised stories. Depending on current state of team and backlog, this process can take up to 2 weeks.

  • I don't see anything at all in this listicle about validated learning. It seems to boil down to a bunch of specs; what is the Product Owner or development team supposed to learn from this laundry list of stuff?
    – Todd A. Jacobs
    Aug 29, 2022 at 23:13
  • Hi Todd, yes I agree that there is much more to product management and agile delivery. I was just trying to provide general guidance and some pointers. Didn't intend to come across as a listicle, more a sequence :) and yes this is a team effort and requires support from people trained in the right disciplines.
    – Jack Leon
    Aug 30, 2022 at 6:41
  • It is a very high level question but yes you are right that the emphasis of an MVP must be to learn what the customer wants and not necessarily generate revenue. My response focusses more on how to get to that first iteration starting from an example.
    – Jack Leon
    Aug 30, 2022 at 6:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.