Use Cases or User Stories? - The Diigo Meta page

• 12 Nov 08
  

  synesthesia UK

  UserStories UseCases agile_requirements

• 18 Sep 08
  

  jmbeas
  • *schedulable*
  • Alistair Cockburn,
  • 12 more annotations...
  • • still uses use cases
    • I keep hearing this complaint, "We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role." No, they don't have the wrong person, they have a broken process – certain types of questions take a long time to research,
    • User stories and backlog items are not set out in that granularity early enough on for that assessment - the extension conditions are usually detected mid-sprint, when it is too late.
    • The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
    • The problem with Use Cases is the attempt to capture *everything* in ceremonial detail so that the project team can go back to their cave and work in waterfall mode.
    • the user has to be continuously available and ideally "looking over your shoulder".
    • Any questions from the development team about "context" or "completeness" that come up during development have to be answered.
    • "RUP was never intended to be waterfall - it just often gets practiced like that."
    • Then she told me about an article Craig Larman wrote in 2002, "How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering".
      
      
      
      The article is an excellent read, and explains what many do wrong, and how to use RUP and Use Cases more agile. I highly recommend reading it!.
    • If the requirements are huge, I would argue that you have a bigger problem with Use Cases. I've seen too many projects where just updating the Use Case documents to reflect the changing requirements was a tiresome affair.
    • And if the customer does not remember the reason for the story at a later date, it probably wasnt such an important story in the first place.
    • 
      
      Yes, Alistair is right when he says the user story lack the "how" that allows the user to understand the actual effort it will required, but that how is useless to most of clients that want to see (or only understand) the "what".

Would you like to comment?

Join Diigo for a free account, or sign in if you are already a member.