1

I'm working on an application to help create a grocery list based on the meals (and their ingredients and quantity) that the user provides. So far, the epics that I've come up with are:

1.) Research (units of measure, popular food items and categories, etc.)

2.) Login

3.) Scenarios (have food and possible recipe, need meals etc.)

4.) My Fridge (feature that allows user to store what they already have in the fridge)

5.) Units of measure (locale detection? how do we allow the user to switch between imperial and metric systems)

6.) Grocery list (how to display, best way to display, email/sms grocery list to self, email/sms to others, etc.)

7.) Food (need to find the most common way each food is measured, display est calories, etc.)

I'm creating epics off major components of the application. Is this the right way to frame them?

0

According to the information you provided, it seems to be ok. I would not create an epic called research but use spikes instead.

1

"I'm creating epics off major components of the application. Is this the right way to frame them?"

I would suggest framing the epics as functionality that can be delivered and tested in semi-isolation.

Out of those you have mentioned :

Research & Scenarios dont feel like epics to me: Research is a spike and documenting scenarios is part of the work to document epics

Login Capability, My Fridge & Units of measure - These make sense to me as their own epics

Food - Food research goes under the research spike. Assuming there's separate display/storage for Food (not the same as Fridge) I could see this being its own epic.

Grocery list - This one feels like multiple epics. Storing & Displaying the Grocery list could be one, but sending the actual list could be a separate epic.

I haven't gone into MVP, but as part of listing out your epics you should have a clear idea of what is absolutely necessary. If your goal is just storing groceries then login and sharing dont sound like MVP.

0

This is not in line with the Agile methodology and product management principles; this means that you will not be satisfied with the result at the end.

Remember, at the end of an Epic, you want the user to at least be able to do something.

Before you create Epics, you should decide what is your MVP, your minimum viable product. For example: if your goal is to create a grocery list based on the meals the user provides.

Then your MVP:

  • should not include login, because the user can use your app even if there's no login and can get instant satisfaction.
  • should be simple. Let's take a user story: Bob is able to open the app and put in meals he likes to eat: Spaghetti, hamburgers and pizza for the entire week. He wants to see a list of groceries: pasta noodles, pasta sauce, ground meat,...

Then you want to decide how long this is going to take to make: let's say 3 Sprints (e.g. 6 weeks). So maybe the first Sprint will be to create the user input page, the next Sprint will be the output page, then the next Sprint will be the logic layer.

This is only after you have done the design and research into a user story and market fit.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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