How would I word this feature and user story?

Question

I am learning to create features and user stories and was reading this thread:

http://stackoverflow.com/questions/1707820/what-is-the-difference-between-a-user-story-and-a-feature-in-agile-terminology

But I'm not sure how it helps here. Say I'm writing a tetris game and I want it to be in color. How would I write that?

Feature: game must be in color

User Story: As a user I want the game to be in color so I can tell blocks apart and see them easily

User Story: As a user I want the game to be in color so that I can view my score and round clearly

that may not be perfect but is this something like how I would write this with something as basic as this? Should I have just taken for granted things like this and not worried about it (my thought is no)?

Thank you.

EDIT: maybe tetris isn't the best example. I was pretending it was brand new and something that no one knew what it should really be or look like. Is this really just artistic license that shouldn't be captured? If this were the stories for the very first tetris game ever would you really capture this about the color feature and then break up that into separate user stories of value?

EDIT: I guess my real problem is that I don't know basic to get when gathering requirements and didn't want to miss anything in my learning.

EDIT: Are user stories not part of scrum and not agile? I thought agile was a philosophy and various implementations created what we call user stories. I put scrum as a tag because that was what I was trying to learn.

Answer 1

"Susie opens up the tetris application and is dazzled by the blue, red, and yellow block shapes falling down the screen. She notices that the blue, l-shaped block might fit right next to the red, t-shaped block. She glances at the bright red score and ..."

People are naturally equipped to listen to stories, and remember the details, probably an evolutionary talent inherited from the days when people told tales around the campfire. The ones who remembered the details about the sabre-tooth tiger and how it pounces from behind survived, and the ones who couldn't remember the tale were eaten.

So, a tale provides an easy way to remember things, and because we have complex visual processing apparatus in our brains, we can remember a lot of information if we can forma visual picture in our mind to accompany the tale.

Answer 2

I think feature stories are supposed to be focused on active interactions, either between the user and the system, or between systems. At least all the ones I've seen have been like that.

Something as simple as the color of the blocks is probably not worth writing a user story for. However, something like this would be a valid story: "When the user presses the spacebar, the piece will instantly fall to the bottom of the area."

Answer 3

I wouldn't normally make "being in colour" a user story. These days "being in colour" is an implicit assumption desktop and web software.

... but if you were let's say a developer for some specialized piece of hardware that normally has a monochrome display, deciding to use hardware and software that supports colours would be a big deal - and would consume resources in the hardware and software worlds. You'd want breakdowns and estimates of colour-related stories... the costs of these stories might influence what colour system you use and how many colours you need to support. Breaking down the themes into stories would give you an idea of how many colours you need to display at once and probably lots of other details of your graphics system.

"Be in colour" is probably too vague. It sounds more like a marketing requirement than a user story. I can imagine these colour-related user stories though:

• "As a UX designer I want to display a London Tube Map with each line displayed in the correct London Transport colours so that users intuitively recognize lines by colour."
• "As a UX designer I want emergency messages displayed in red so that they're clearly distinguished from all the other messages and so that they're clearly associated with danger."
• "As a salesman I want the system to be skinnable in the colour schemes of our three major clients to increase our sales volume."

Answer 4

I look at this particular example as acceptance criteria to another story. Specifically, one that would define the blocks.

Now, if this was a change to an existing piece of functionality (ie your blocks are currently all white), it is a stand alone story.

Answer 5

Personally, I don't make any difference between a feature and a story, stories should be MMF (Minimal Marketable Features). And even if some people will or may disagree, I wouldn't spend to much time on that difference and go ahead with writing stories.

About them, the template you are using seems ok ("As a <role>, I want to <action> so that <business value>"). However...

First, I'd really recommend to use the <role> (a "user" may have multiple roles), this is helpful to discover stories. In your case, this may not make a big difference as I'm not sure that a Tetris user has many roles but still, I'd write "As a player..." instead of "As a user...". Now that I've written this, I can think of different roles: noob player, pro player, etc which may have different expectations.

Second, you seem to have troubles with the "business value" part. One very helpful tool for this part is the 5 Whys (which is used for root cause analysis, i.e. finding the root cause of a problem), it is a very powerful technique. The cucumber documentation explains very well how to use it to find some "good" business value and has a very good sample, so, instead of paraphrasing it, I'm quoting the explanation below:

Business value and MMF

You should discuss the "In order to" part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost
• Increase brand value
• Make the product remarkable
• Provide more value to your customers

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

Here is an example taken from an IRC chat session in [#cucumber][6]:

[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature 
                         "login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login 
                         in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy:  Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why? 
[5:12pm] aslakhellesoy:  I'm asking you
[5:13pm] aslakhellesoy:  Why have you decided login is needed? 
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy:  Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is 
                         publishing what
[5:15pm] aslakhellesoy:  Why would anyone want to know who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs 
                         to someone, then the content is trustworthy
[5:17pm] aslakhellesoy:  Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and 
                         consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy:  :-) 
[5:21pm] aslakhellesoy:  Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy:  There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase 
                         de revenues.
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy:  In order to drive more people to the website and earn more admoney, 
                         authors should have to login, 
                         so that the content can be displayed with the author and appear 
                         more trustworthy.
[5:23pm] aslakhellesoy:  Does that make any sense? 
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy:  It's easier when you have someone clueless (like me) to ask the 
                         stupid why questions
[5:26pm] aslakhellesoy:  Now I know why you want login
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy:  And if I was the customer I am in better shape to prioritise this 
                         feature among others
[5:29pm] Luis_Byclosure: true!

Let me play the clueless guy and ask the first why question: Why do you want the game to be in color?

Good luck!

Answer 6

While I could see an initial card or epic being that the game has to be in color, there are a lot of little details that would come out as finer details are explored such as:

1) Scope - Are were merely talking about the blocks that are falling and not the rest of the screen or does this cover those other parts like where the score is kept, level number, and other details on the screen.

2) Breadth - Are you using 16, 256, or more colors in the palette to do this? Who decides which colors are used where?

3) Display details - Would this be for a standard monitor or is it a specialized display that emulates say a Nintendo Game Boy that has 4 shades of gray to it? How big is the screen intended to be?

Some of these details aren't supposed to be wrapped in the overview of the story but found out by whoever works on the story.

To summarize, the details in the 3 points would likely be artifacts generated as the task is done, but as for the story itself, "Add color to the game," is a heading/title/summary with more detail available if someone wants it and can specify if they want a paragraph, page, or novel length elaboration. Don't load too much detail upfront so that making the cards does 90% of the work and there is so much paperwork that the work is done at a lethargic speed is the caution I'd add. The initial card is just a starting point that may cause a few spikes as unknowns are resolved and so don't worry too much about wording the initial card unless everyone follows them exactly to the letter rather than following the spirit of, "This is enough to get us started and there may be new things found as the work gets done."