DoingGoodUserStories

This is not the final words on story writing, and some of the ideas aren't yet supported by the C2Wiki, however our aim is to try them out and report on what we learn -- Sand

Index Cards

Writing on real IndexCards seems to help the process. It sounds crazy, but when we actually brought some cards to one of our planning games it made a huge difference. Notebooks and torn up scraps of paper are just not as good.

Unfortunately the C2Wiki only has a few limited examples[1] of UserStories, and we found them hard to use as examples when writing our own stories. The

I want to... so that ....

We have noticed that stories that start out with "I want to..." seem to work best. This is probably due to the fact that it expresses a user's opinion on something. We can then attempt to measure that feeling. Peter Marks suggested the phrase "so that" which PaulS rather likes in this context. Thanks Peter.

We also have noticed that good stories don't seem to mention any specific technology, they just make a request - this seems to make them work better. Maybe a suggested technology gets recorded as a note, however as you refactor code or remove technologies, you want to keep the essence of the stories alive.

Attached Tests

Really good stories can make reference to some tests (we have tried attaching these a secondary card stapled to the story). You don't always get the tests up-front like this (but once in a while you do - and thats great, and should be encouraged). If you don't get some tests up-front don't worry they can be developed with a user over the course of an iteration and incorporated when you are DoingFunctionalTests.

Capturing the Intent

Capturing the true intent of a story also seems very important. We are experimenting with the idea of making sure that we record the true intent of a Story: I want to query the trades in a system by specifying the counterparty and instrument "vs." making assumptions that can be used to fit the intent into a deliverable time frame (I will enter the query details into a file). If we capture the intent, then the story can move with the changes in the system and not prevent unnecessary code from being carried around.

Granularity

Half of the purpose of a UserStory is to capture requirements, the other half is to schedule it, so there must be enough detail for the developers to have a go at guessing its cost and, if you follow the C3 line, that cost should be 1, 2 or 3 ideal weeks. One issue we've come across is in DealingWithSmallUserStories that don't seem to fit elsewhere, other than by stapling some together. --SteveFreeman

Structured Or Not?

I think that it's better for a real development to structure in a better way the specification about the requirements about a software products. We must to be on the right way to produced a real software that meet user expectation. --IAP

Please help me..... I do not understand the last statement above.... rcf ..........