How to manage to write first stories when applying scrum to a game? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 9 years ago.

Improve this question

I'm starting to add first user stories to my game backlog. My team has a rough idea of the game we want to create and we are ready to gather top level requirements. How do you do this? I mean, for example you can start with a mega epic (top level) that reads "As a publisher I want to create a game where player must feed a monster so that they spent a really fun time". Is this a correct starting point? Should we now split this epic into smaller user stories and split this user stories in smaller ones and finally in tasks? Is this "tree like" way of gathering requirements good or you usually use a "flatter" way?

Thanks in advance.

Answer 1

A good starting-point for writing good user stories is the book by Mike Cohn. There are also plenty of useful resources online how to write good user stories and how to work with the backlog as a Product Owner and how to involve the team to continuously keep the backlog in good shape so you can have effective sprint planning sessions, do reasonable forecasting of dates when features will be available etc.

It's always important to stay practical and experiment. Start with something and then inspect&adapt that so that you improve. This is the essence of any agile tool/framework.

If you want, start with the big epic and see how that goes.

Probably it's not worth having that epic, but rather discuss various things the player of he game can do that are more specific. These things are user stories, i.e. things that add user value throughout a whole product. A vertical slice of the system.

Some made-up examples to illustrate ideas around stories in a game setting:

• Player that gets 100k points will get rewarded with a golden medallion.
• Player must complete X and Y in order to open up the secret passage in Z.
• Player can use portal to teleport to any level he chooses.

Yes you can see it as a tree or more and more specific stories that are children of other stories or epics. Practically, you only care about the leaves as that is the product of working together as the team and PO to work on backlog items during sprint planning or other sessions.

Experiment and start with something and improve from there.

Answer 2

That is what we do. Start with epics that are fairly high level and the decompose them into more technical user stories. Generally we stop at one level, but sometimes a user story is just too big and it does need to be split into smaller chunks.

At the top level are epics, and right below are user stories, and that is it. It may help you to break down further as an exercise in decomposition - but building a massive tree of dependent stories might be a lot to track. We try and capture stakeholder needs AS epics (and yes, there can be some overlap, but that's ok.) We tend to want our user stories to be "lightweight requirements". The developer is free to create as many tasks as necessary to accomplish the story. And if the dev finds that there are just too many tasks, we go back and see if we can break the story up.

Our Product Owner manages a "feature backlog" which is just the fancy way of saying "epics". We link the feature stories to our team stories. There is not ONE top level epic, there are MANY top level epics representing feature needs. This way we can group features logically together for the sake of "releases".

Answer 3

You might want to take a look at a technique called "User Story Mapping", by Jeff Patton.

"As a publisher I want to create a game where player must feed a monster so that they spent a really fun time"

Something to keep in mind is that stories are written from the perspective of the users of the system. In the example you mention, it occurs to me that the Publisher is definitely a stakeholder for the project, but not a user (unless you're creating an app to generate games on the fly.)

Start by doing an analysis of users of your game. Probably "Player" will be the main role, but you can think of different kinds of players: advanced players vs. newbies, PC players vs game console players, players who want to explore vs just get through the game fast, etc. That will suggest you different features the game needs to support.