How To Give Constructive Feedback on User Stories

As a participant in an agile project I want to know how to give constructive feedback on User Stories so the team can continuously improve.

In many software development projects, the adoption of agile development principles has had a great start, but may be struggling when it comes to implementation. I’ve seen examples of that in the way features and requirements are broken down into programming tasks and further on into testing, deployment, and maintenance tasks. The best way to tie all these tasks together is to describe the end result as a User Story and reference the related tasks to that. That way, whoever does the related task will always have the expected end-result in mind and can without effort see what other tasks are planned for that story. As with many other things, starting can be difficult and may need a lot of collaboration so the best way to get started is to know how to give constructive feedback on User Stories.

  • What is a user story?
  • How can the team prevent feature- or scope-creep using acceptance criteria?
  • How can scenarios put the acceptance criteria back into the context of the user story to make it testable?
  • Who should give and take advice about writing user stories?
  • Who should decide on the level of quality for a story?
  • What makes feedback constructive?

The goal with this article is to describe one way to assess the quality of user stories and provide constructive feedback on how to improve them.

What is a user story?

A user story is a simple way to describe a feature, its target audience, and its merits in a single sentence. It is basically requirement specification in agile projects.

The simplest form is the strongest as the following:

  • As an [role],
  • I can [feature]
  • so that [reason] (optional)

For example:

  • As an [administrator],
  • I can [edit posts by any member]
  • so that [the post can meet the quality standard of the forum]

Check out this great article about writing user stories.

Set boundaries with acceptance criteria

The acceptance criteria are rules that define the user story. Without them, user stories are open-ended and ultimately suffering from feature creeps. Consider the following examples:

  • The post can only be changed by the author or an administrator.
  • Members can only use the products they have payed for.
  • The video will start when the page is loaded and the window has focus.

The acceptance criteria are clear, specific, and unambiguous.

This article has some nice practical examples of acceptance criteria.

Add context with scenarios

Scenarios are used to give context to the acceptance criteria of the user story. Some acceptance criteria can occur in multiple scenarios. The scenarios make the user stories testable.

Consider this simple form for using scenarios:

  • Scenario [#]
  • Given [context]
  • When [event]
  • Then [outcome]

Applying the example from the user story:

  • Scenario [1]
  • Given [an administrator is logged in]
  • and [has loaded another user’s post]
  • When [clicking the edit button]
  • Then [the content of the post is editable in a text field]

Adding a variant of the scenario:

  • Scenario [2]
  • Given [a user is logged in]
  • and [has loaded a post]
  • and [is the author of the post]
  • When [clicking the edit button]
  • Then [the content of the post is editable in a text field]

The team should agree on the criteria of a good user story. If a story does not meet the criteria, simply ask yourself and each other: “what is missing”, raise your concern and your preliminary answer with the team – even if your answer is so simple that you are almost embarrassed to say it out loud.

This article has a great example of Acceptance Criteria vs. Scenarios involving baby pets :)

How To Give Constructive feedback on User Stories

The team and yourself may not agree to the solution, but that’s okay.

The key is that you share your concern in a concise way and show the way to a solution by communicating a possible solution to the team.

Maybe your answer is really good and it solves the issue with the user story. Great, now move on. Your solution may also be really bad. Also great!, if you are part of a team that you trust and you all know that you simply suggested the solution in lack of a perfect solution to start a collaborative discussion on how to solve the problem. There are many degrees of perfect, especially in the context of a project where time, cost and quality are the determining factors. The perfect solution could be the dirty hack that moves the project forward.

The idea here is that the culture in your team has to support even the worst suggestions because they can start deep conversations that may lead to genius solutions.

Trust yourself and your team, lead the way to the solution, and know that your solution may not be the best.

Leave a comment: describe pitfalls when creating user stories and how to give constructive feedback in agile teams.

Simplify Game Development: Think of it as a Toy

The Toy is built through iterations of development, play and tweak using the technology that will be used to build the final game.

One of the basic and most important components of a computer game is how the player interacts with the game. Many games rely on characters or objects that are controlled by the player. Very few players are consciously aware of this interaction and this is often the way it should be if the engagement in the game should be maintained. Therefore the feel of the game should be a central part of the game and iterated upon throughout the production.

This is the second in a series of articles on how to simplify game development based on my master thesis on game production. I hope that game developers will be able to simplify game production with these ideas in mind.

I will not go into details about what the definition of a toy other than it is something that you can play with. There are certain similarities to game development that I find interesting: Toys are made for play, which is an essential part of most games. Toys can be played with for hours at a time. Toys are mere tools for play and immersion – suspension of disbelief. Likewise will people probably play your games as much as possible if the toy their tool of choice when it comes to play. This is why it is important to perfect the toy.

I read in a book about game feel that Shigeru Miyamoto, the creator of Super Mario, spent a lot of time iterating over the Super Mario 64 controls in what he referred to as a “garden” – a virtual test environment containing elements of the game that have an impact on the feel. I am sure that iteration on controls is time well spent. I myself will not play a game for long if the controls are annoying.

I am currently in the process of porting a prototype to tablets where the controls are giving me a hard time. The initial prototype was made for 2-4 players using keyboards or joypads for input and was a thrill chasing each other around in a maze with different speed and drag attributes. At some point we decided that the game format would be better for 2 players on a tablet where each player had to control their character with touch input. The entire feel that we worked hard to achieve was lost. It was a brilliant idea to use the tablet for the immediate face-to-face interaction between the players, but the controls could not be ported directly. Mainly because we had spent some time tweaking the controls to the natural haptic feedback that the joypads and keyboard give, where a touch screen with a rendered image of a joystick is nothing like it.

Thinking of your game as a toy is one of the fundamental things you can do for your game design. If the toy is not fun to play with, why would anyone ever play a game? Start early playing with the toy, make sure it is fun, discard unnecessary features, hone what makes you want to keep playing it. Above all, get other people to play with the toy and tell why they want to keep playing and what has no significance.

Simplify Game Development: Share a Simple Concept Early

Define a clear concept along with the level of quality that you want the game has to have for narrative, game and play.

There are many ways to get ideas. These range from getting a revelation while walking down the street or doing the dishes, to working structured with tools and methods in collaborative sessions. I like to capture as many ideas, tell as many people about them as possible, and formulate the ideas so your peers can easily understand them.

This is the first in a series of articles on how to simplify game development based on my master thesis on game production. I hope that game developers will be able to simplify game production with these ideas in mind.

Share the Concept Early and Often

Any notion can be made into a game, but the hard part is to conceptualize and develop the idea. Initially the idea don’t need to be formulated more than enough to remember it. However, if I leave my ideas too long in the notebook, I tend to forget what the essence of them was. So it is a good idea to soon start to collaborate with other people on the ideas, start formulating it and specify the little details that make the idea appealing and different from other ideas.

In my experience it is important to share the concept – the sooner the better. Some people are afraid of others “stealing” their idea, but in my world an idea cannot be stolen. It cannot be owned until there have been put work into it. I.e. time to develop the idea into something more than thoughts and words on a paper. An idea is a free entity until it has become a concept in the sense that it has been formalized and captured in a form that specify it enough to be differentiated from finished products. Anyway this is an issue for lawyers – not me, and the benefit from sharing an idea is far more worth than the work it takes to “steal” an idea. I guess the point is that execution is what gives value to the concept.

Set Boundaries for Your Game Concept

Once you have started collaborating your idea with others, you should start elaborating the little details makes it appealing. This is where catch phrases as KISS (Keep It Simple Stupid), “less is more”, etc., can be used actively to test the quality of the idea. There is a reason that these phrases are so popular. The exercise is to start simple, by formulating the idea with as few words as possible – in Reality Lag, we use a for we call Power Docs which has a simple and strict form for capturing an idea. The limit is one page describing the idea and it has to be playable in the mind of the reader.

Test the Concept With Players

Test the idea! Ask people if they would play the game. They may ask about or add to the idea, which is golden. Elaborate on your idea, draw the idea, build a simple prototype. If the idea is dependent on a story, write a simple plot outline, describe a part of the world and a few of the characters or their relation. Then test the idea again. Expose it to your peers and see if they get your point, think it is interesting etc. The goal is to get feedback.

The next is to start developing the toy and narrative of the game.

Simplify Game Development

I has been some time since I reflected closer on ways to simplify game development. This article is the kickstart to set of articles on my views on it. Since my graduation I’ve seen different software productions, mainly from a quality- and process oriented perspective. I’ve also experimented with different game development processes in smaller teams. This experience has given me some new takes on some of the initial ideas that I studied at the university.

The main idea with these articles on game production is to review the core topics of my master thesis on game production. I hope that with these ideas in mind game developers will be able to simplify game production.

First of all, I see these seven topics as the most important in game productions:

Each of the above topics are still the way I like to simplify game production and perhaps even any software production. The topics should not be seen as phases in a production but rather as elements that are iterated upon throughout the entire development of the game. At some point each of the topics will reach a mature state and more effort can be put into the other areas.

As I release the articles on the topics, I will add links to them in this article. Thus is this article better seen as an index or teaser to the following seven articles in this series.

Why are in-game tutorials important to some and not to other video games?

These are some of the questions about in-game tutorials that have always nagged me: Why are in-game tutorials important to some and not to other video games? How can in-game tutorials be made seamless to avoid breaking the player’s suspension of disbelief in a video game? When does a game need an in-game tutorial? Should the player learn the game by failing? What kinds of players will put up with the frustration of not being tutored? Which games can do without tutorials? What different types of in-game tutorials are there? How can in-game tutorials be made interesting and seem like an integrated part of the game?

In a way, there are three types of video games: the illogical, the intuitive, and those with in-game tutorials. The illogical game probably has the hardest time settling with the players. The intuitive game is a bit better off once the player knows what to do and where to go. Those with in-game tutorials give the player a head start in complex concepts. However, there is a fine balance to keep: do not underestimate and patronize your players. I have an opinion on some of the strengths and weaknesses that should be considered when talking about in-game tutorials.

Each of the types, illogical, intuitive, and with _in-game tutorial _are of course mixed and graduated in reality, but for the sake of the discussion, I’ve taken them to the extreme.

The Illogical Games

In these types of games, the controls are often hard to learn and the objectives in the game often don’t make sense unless the player knows about the game world. The controls and objectives doesn’t necessarily make sense even when they are learned. The games must be interesting for players before they learn the controls and objectives.

Games with illogical controls or objectives often have a steep learning curve. Some may categorize these as hardcore games. I remember sitting in front of my brother’s Amiga 500 immersed in a variety of games with great enthusiasm, but often after having been frustrated by having to figure out the controls by trial and error.

Practically no games were translated to our mother tongue and if they were, we wouldn’t waste precious gaming time reading the tome that came with the game. That meant that a hard judgement fell on the illogical games: discarded! (i.e. because the games simply fell outside of our zone) So, what made us grant the games our attention back then, was most likely the scarcity of videogames in general.

If games was as ubiquitous as they are today, I think that we’d been more demanding and the most illogical would not be granted a second.

The Intuitive Games

Intuitive game controls and objectives are easy to learn may not need to be taught to the player. Controls and objectives make sense the first time you’re learning them. The games does not rely on being overly interesting for players to learn to play. Intuitive games have a gradual learning curve. Some may categorize them as casual games. Some controls are so obvious and easy to learn that it does not really require much effort from the designer nor the user. Just play the game. However, varying complexity in games are often reflected in the controls and how the objectives of the games are given to the player.

Consider a player that has never played a first person shooter. To him, Doom is something that awaits and not one of the founding fathers of what evolved into a standard control scheme in subsequent 3d shooters.
This player need an incentive to play the game and learn the controls. Back in the day, it was fancy photorealism in VGA and the compelling story about… killing monsters. And that was more than enough for most of us. Frankly, I do not recall if the controls were taught in-game or only in the manual – some of the controls wasn’t event in the manual.

The point is that to the player that never played with these controls, they would not be illogical after some time getting used to them, perhaps even intuitive if using the wasd/mouse configuration that is pretty much standard these days.

The Games with In-Game Tutorials

Even though I named this the third type of game, it serves more like a transcendent category: In-game tutorials are both used in illogical and intuitive games because both may benefit from in-game tutorials or in some cases in-game tutorials are a disadvantage for the intentions of a game. First of all, in-game tutorials lets the players learn the controls and objectives fast and really get into the intended game play sooner. The downside is that there is a risk of patronizing the player if the controls are super intuitive  and still spelled out, so I guess there is a fine balance to keep depending on the players:

  1. Continuous throughout the game,
  2. once per game session, or
  3. once per player (stored in a user profile or the like).

In the end, remember that videogames are mostly entertainment and if the player ends up frustrated, the game fails its purpose.

Rolling box control scheme – The Floor is Lava!

The Floor is Lava / rolling box control scheme
Click the image to try the game.
I prototyped this simple physics based rolling box control scheme using Unity, in only a few hours.
To move the box, you add torque to roll it by pressing the arrow keys or swiping the screen (so far only android devices).
Try to keep the box on the floats and get to the safe platform. If you hit the floor, you’ll lose life.
It feels a bit heavy at first, but it might grow on you with a few other interesting game design dimensions.
Like the controls in Edge, I like the constraints to the three dimensions that it has – not to mention the bonus you’ll get for balancing the box on the edges.
Try out the rolling box control scheme and give me some feedback on it.

Medium Distance Relationship

Medium Distance Relationship is what my team and I named our contribution to Nordic Game Jam 2011.

Try the game, “Medium Distance Relationship”, here.

I came up with the interesting rolling control mechanism, which I experimented a bit on later in my prototype of a Rolling box control scheme – The Floor is Lava!.

The mechanic in MDR is simply to balance the distance to NPC agents running around after you. When they’re in your vicinity, you suck their life energy: good. If they are too close to you for too long, they die: bad.

The music was nicked from Kevin MacLeod at Really awesome stuff for the likes of us.

Inglorious Skater, NGJ2010

Right now I am totally exhausted after having designed and coded in audio in the NGJ game Inglorious Skater.
There has been a lot of very interesting and funny games here at the Nordic flagship of IGDA’s Global Game Jam in Copenhagen.

There where a number of games submitted this year of which twelve went to through the first voting round:

  1. Disco Donkey Slaughterhouse
  2. Chasing Dots
  3. You Say Jump, I Say How High
  4. Grapple Grapple
  5. Shadow Ninja Monkey
  6. Find Love
  7. Preschool Theater Director
  8. Honeymoon

There where also four juror industry / research representatives that had to pick their favourites (one of them got picked twice, I think… correct me if I’m wrong)

Finally the People’s Award went to the game Only One Can Ride The Donkey.

The theme of the Global Game Jam was  deception and the local constraints for GMT+1 (based on timezones) was that the games had to incorporate the words monkey, donkey, or key (I’m afraid the art of subtlety has been lost; if I hear of a game including any of those within the next year, my head is going to pop).

I’ve noticed a few using XNA or GameMaker, a bit more using Flash but by far, the majority of the games here where created with Unity.

QA Specialist in Unity Technologies

For a few months I have been working at Unity Technologies as QA Specialist, handling the publicly submitted bugs reports. I am very proud (even lucky as I have just graduated) of being a part of one of the worlds leading teams in game development.

Our issue tracker, FogBugz, is not feature loaded, but the FogBugz XML API has quite a few possibilities to it.

I am learning Perl to get an easy and versatile tool to work the API with. Once I am on top of that, I will look into how the API can be used to fill in some missing features of FogBugz. Then, in a near future when I have tweaked FogBugz to meet the needs of Unity Technologies, I will put my interests and experience into extending the product itself to make life even more easy for game developers.