Example epics for an mobile game

Question

I want to define epics for the following project: "a mobile application which makes you discover a city through a detective game".

The game basically needs to display your position on a map to get you from one key point to another; when you arrive at a key point, you have to solve some kind of riddle to unlock the next key point. The fact that the game can be played offline is required.

I am new to Agile and project management (as it is a university project) and I tried to gather some epics. I found plenty of example of epics for Web projects, but nothing for mobile game development.

So far, I have the following epics:

1. As a user, I want to be able to know where to go next
2. As a user, I want to be able to store my progression in the game
3. As a user, I want to be able to share my progression in the game
4. As a user, I want to use the application offline

My questions are:

1. Which "who" should I put: only "user", or should "developer", "tester", "admin", etc. be included?
2. From which point of view should we see things?
   For instance, should it be "As a user, I want to use the application offline" or "As a developer, I want the application to work offline"?
3. Are epics 2 and 3 not user stories instead? Should they not be part of a same epic "As a user, I want to store and share my progression"?
4. Do you have any examples from your experience or ideas of epics which could fit this project?

Answer 1

Since you've marked your question as Scrum, my advice to you is to have your Product Owner talk to the stakeholders. Both the ones sponsoring the project (in your case, the teacher), and the ones who (hypothetically or otherwise) would actually use the system. If you don't have any users, go out and find some! Interview random people (or, failing that, friends and family), asking them what they would like the product to do if they were to actually use it. Market research!

With that done, epics should evolve naturally as you compile all the requirements (both feasible and not) that the Product Owner has gathered. In the end, the point of Epics is essentially to group Stories, after all. Doesn't make much sense to have Epics if you don't even have any Stories.

Now, to actually answer your listed questions...

1 and 2):
Stories should be written from the perspective of the person who actually wants the requirement. 'User' fits fairly well for all of the above. A typical developer won't really care if an application they're never going to use can be used offline or not.

If you had something along, say, the lines of security, though... 'As a user, I want to make sure all the SQL is sanitized so I cannot break through into the database and steal all the company's information' doesn't really jive.

In some cases you can/should get more specific, such as 'As an experienced user, I want hotkeys for (feature), so I can complete it more quickly', or 'As a novice user, I want the usability of (feature) to be simple enough that I can figure it out without needing to check documentation.'

3 and 4):
It seems to me that all of the ones you've provided there are more 'stories' than 'epics'. As a general guideline, each story will have one requirement, while each epic will have many requirements.

Epics I've seen are more along the lines of 'User Interface Design', 'Integration with Order Management System', or 'Image Attachments'.

Answer 2

I'm yet to see a clear standard on what epics are. However, in real-life situations, epics are often used to define a macro requirement that is too big to fit into a sprint and delivered as a single user story. From this standpoint, your four entries look good. For example, the As a user, I want to be able to know where to go next epic could be comprised of stories along these lines:

• As a level designer, I want to be able to define which cities one can go from a given city.
• As a level designer, I'd like to define conditions which open a new link from city X to city Y for a given user.
• As a tester, I'd like an ability to provide mock map data that defines links between cities.

etc. etc.

So, coming back to your questions:

1) At the epic level, I'd usually talk about the end-user, as macro requirements tend to provide a requirement that's of use to the customer. However, at the story level, it might be quite different as you saw from my examples.

2) Same answer as for the question above.

3) I think they make sense in their own right. It's possible to release version 1.1 of the game with saving, and 1.2 with sharing: they don't have to be bundled together. Also, most likely either won't fit into a single sprint and would require a similar breakdown to the one in the first epic.

4) Here are a few examples that come to mind:

• As a user, I would like to be able to register to the game
• As the game developer, I would like the ability to gather statistics about game's usage, so I can focus my future roadmap (I realize I contradicted my answer to 1 here a bit)
• As a user, I would like to choose and solve a riddles in a given city
• As an Android user, I would like to play the game on Android 4.0 and newer devices.

The disclaimers are that I have not done full project planning for a mobile game, and that this is not an exhaustive list.

Answer 3

How do you interpret the term epic?

As others have mentioned, you don't have epics, you have user stories. It's all in the name: user story, which quite literally means the story of the user. You can think of an epic, on the other hand, as a collection of user stories under a particular context. The Scrum Alliance itself has a good breakdown of Stories vs Epics vs Themes, which is well worth a read:

Epics resemble themes in the sense that they are made up of multiple stories. They may also resemble stories in the sense that, at first, many appear to simply be a "big story." As opposed to themes, however, these stories often comprise a complete work flow for a user.

That said, it must be noted that Mike Cohn, co-creator of the Scrum process, disagrees slightly with this, stating that:

A user story is simply something a user wants [...] A Scrum epic is a large user story. There's no magic threshold at which we call a particular story an epic. It just means “big user story.” [...] Finally, “theme” is a collection of user stories.

Personally, I've always treated an epic as a high-level category for a collection of related stories, and used it interchangeably with Cohn's definition of theme. For example, one epic can simply be about login with a dozen user stories under it:

• logging in as different user types
• first-time login and flow
• repeat login
• concurrent logins from different devices
• failed login attempts, and so on.

So, to give a generalised answer to your questions:

The clue is in the name; the point of view in your user story is a user of the system. Let's say we're building a database-driven sales interface. Some typical users will probably include:

• a sales person (who needs access to the UI for entering and saving sales data)
• a sales manager (who needs global access to all sales person data, as well as user management access)
• a system administrator (who needs user emulation rights, and direct database access)

So depending on your system's functionality, you will phrase your user stories based on who the functionality is for, such as:

• As an administrator, I need to be able to login as another user, so that I can troubleshoot in the user's context.
• As a sales manager, I need to be able to see cumulative statistics from all sales agents, so that I can form comparative views.