DealingWithSmallUserStories

- Last edited January 18, 2000

Here are examples of situations PaulS has found with SmallUserStories:

They often represent an idea of the customer which has little association with other stories. So they were not explored in any depth beyond the initial statement. Here is a small story from my current project:

"Archive and Purge" Always have available 6 months of instrument prices. Purge instrument prices beyond 6 months, but keep month-end prices only for up to 2 years so that they are still available for purchase.

Customers seem happy to group small stories together. The customer is always right. My belief is that the customer will add more detail to the really important stories so they then grow bigger!

Sometimes, two small stories are closely related. PaulS finds it useful to refactor these into one story with the customer present. Often this begins with stapling the cards, but ends in writing a new card. This sometimes happens with more than one customer expressing the same idea in different words.

Here is an example of two stories that were refactored, based on my current project, with some changes to protect the customer:

"Purchase Instrument Prices" I want to purchase any of the instrument prices displayed, so that my balance is reduced accordingly

"Enter Cost of Instruments" The adminstrator enters the cost for each instrument. Each is assigned to one fee-group such that monthly subscriptions are made for all things in one fee-group

The ability to enter costs fits well with the ability to purchase using that cost. The customer is happy to combine these stories as they would always want both or none in an iteration.

- Last edited January 18, 2000

https://casino-brain.com/