| Lines 1-40 were replaced by line 1 |
| - *their intent) - hogood 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__ |
| - ing 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 |
| - .......... |
| + technology, they just make a request - this seems to make them work better. |
| Line 42 was replaced by line 3 |
| - __Getting your story noticed__ |
| + - Maybe a suggested technology gets recorded as a note, however as you |
| Line 44 was replaced by line 5 |
| - OliBye has noticed that his customers have started putting little red stickers on their cards in a effort to get them noticed. It's nice to see that they see the stories as important. |
| + - refactor code or remove technologies, you want to keep the essence of the |
| Line 46 was replaced by line 7 |
| - __Using stickers for progress__ |
| + - stories alive. |
| Lines 48-49 were replaced by lines 9-101 |
| - At ConneXtra we use coloured stickers to indicate progress. All stories start out with a red sticker (tasks have blue stickers). Developers can make tasks finished by applying a green sticker. Developers can mark stories as "developer finished" by applying a yellow sticker. Only Customers can mark a UserStory as complete by applying a green sticker when it passes acceptance tests. The nice thing about this scheme is you can quickly see what's complete on the planning board. We used to tick with a marker pen but using stickers for marking progress is easy to reverse if a problem is spotted. - RachelD |
| - ³DoingGoodUserStorie |
| + - |
| + |
| + - __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 |
| + |
| + - .......... |
| + |
| + - |
| + |
| + - __Getting your story noticed__ |
| + |
| + - |
| + |
| + - OliBye has noticed that his customers have started putting little red stickers on their cards in a effort to get them noticed. It's nice to see that they see the stories as important. |
| + |
| + - |
| + |
| + - __Using stickers for progress__ |
| + |
| + - |
| + |
| + - At ConneXtra we use coloured stickers to indicate progress. All stories start out with a red sticker (tasks have blue stickers). Developers can make tasks finished by applying a green sticker. Developers can mark stories as "developer finished" by applying a yellow sticker. Only Customers can mark a UserStory as complete by applying a green sticker when it passes acceptance tests. The nice thing about this scheme is you can quickly see what's complete on the planning board. We used to tick with a marker pen but using stickers for marking progress is easy to reverse if a problem is spotted. - RachelD |
| + |
| + - ³DoingGoodUserStorie |
| + |
| + + technologTesting |