Atm User Stories And Tasks

(From UseCaseToUserTask)

I'll have a stab at it. Some UserStories might be :

• "Display welcome screen until user is logged in"
• "Display login screen"
• "Verify login data according to protocol X"
• "Display the main menu. (Text and layout of menu attached)"
• "Display appropriate screen when keys 1-4 are pressed"
• "Output log data to file when switching screens"
• "Display an error message if balance is insufficient, rather than give cash"
• "Output log data to file when amount is keyed in"
• "Activate cash hardware with withdrawal amount upon OK being pressed"
• "Debit account after withdrawal"
• "Print receipt upon END being pressed, if a transaction has been effected"

This isn't necessarily a complete list. It already suggests some questions I might want to ask the Customer. The next important step isn't so much a breakdown into tasks as a drilling down into what the customer tests will be, and how to write them.

---

This is just the sort of thing I was looking for - it gives me a guess about correct level of detail and abstraction. I suspect that if the UseCases were more fully fleshed out (data structures, business rules, extensions, interfaces, etc all linked in) then each of these stories would map nicely to a portion of a particular use case (or something hanging off of it). Do you agree?

In particular, we have guidance from AlistairCockburn that UseCases should have from 3-9 steps in the MainSuccessScenario?, and from 1-3 extensions per step. This would imply that there could be a couple dozen things to do (depending on how you count). Is it reasonable to guess that we would then have a ratio of 5-30 UserStorys per UseCase?

--DanRawsthorne

To both questions : I dunno. I've never seen real live UseCases in a project. I was just picking out stuff from the UseCases you wrote up and asking myself what the UserStories behind them might have been.

It's entirely possible that there could be bigger or smaller stories for the same UseCases, though. Compared to a UseCase, a UserStory derives its granularity from the level of effort involved, not the level of abstraction. If we were coding on the bare metal, just the first of the above stories might have to be split; if we had a a largish library of ATM classes, with their tests, ready for reuse - all of the above might be just a couple stories. Does that help ? -- LaurentBossavit

---

Yes, it does. My take on this is that UseCases are for the User/Customer interaction, while the UserStorys are for the Customer/Developer interaction. That is, the granularity of UseCases is based on the granularity of the goals that can be validated with the user, while the granularity of the UserStorys is based on work-units.

So, if I had a project where I had to do some significant requirements gathering up-front, I could get a collection of use cases going, at various levels of precision. Then I develop UserStorys to actually work on. My belief is that each UserStory will fit inside a UseCase quite nicely (perhaps into more than one, actually), so that I can measure the "doneness" of my UseCases - which is probably a more useful metric (in some cases) than measuring UserStorys and AcceptanceTests.

--DanRawsthorne