1. Waterfall v.s. Agile
2. SCRUM
   1. Product Backlog
   2. Product Backlog Item
      1. Place holder for req
   3. User Story
      1. Format
         1. Template
            1. As a <user type>
            2. End user
            3. Customer
            4. Other system
            5. I want <benefit/opportunities/function>
            6. So that <benefit>
         2. Example
            1. Content of a typical US
            2. 1. User story desc
            3. 2. Acceptance criterai
            4. 3. Supporting materials
            5. Mock up/WF
            6. Model
            7. Image
      2. 3C
         1. Card
            1. Short
            2. Avoid detail
            3. Defer detail later
            4. just ahead when the piece need to be delivered
         2. Conversation
         3. Confirmation
            1. Via Acceptance criteria
            2. Screen
            3. Technical notes
            4. Model
            5. Whatever the team needs
            6. Ensure the right thing is built
            7. Agile vs Waterfall
            8. When to produce the detail
      3. Evolving
         1. Just in time - just enough(JIT - JE)
         2. Many levels
            1. Epics
            2. Features = Theme
            3. USer Story
            4. Task
      4. INVEST criteria
         1. Independent
            1. Goal
            2. Not to eliminate all dependencies, but to minimize dependencies
            3. Image
         2. Negotiable
            1. Good US will captures essential biz func and why it is desired
            2. But they leave room for PO, Stakeholders, Dev to negotiate the details
            3. DONT: PO should not tell the team HOW to team
            4. Cos chance for team to be innovative are diminished
         3. Valuable
            1. Technical stories is important to dev but not value to PO
            2. So the PO need to understand why he is paying for it and what value it will ultimately deliver
            3. In practice, technical stories are not in PBLog
            4. It should be task associated with getting biz-valuable stories done
            5. The crux of valuable criteria is that all stories in PBlog must be valuable from the PO's perspective which represents the customer and user's perspective
            6. Ex
            7. Image
         4. Estimatable
            1. Indication of size and cost-effort
            2. Scrum team determines from the size of the story whether additional refinement or disaggregation is required
         5. Small( sized appropriately)
            1. Several-week sprint, we want to work on several stories that are each a few days in size
         6. Testable
            1. Being testable means having good acceptance criteria (related to conditions of satisfaction)
      5. Meaning
         1. Not to provide detail up front
         2. Just provide the framework(skeleton)
            1. Details can be added JIT and JE
      6. How to gather US
         1. Identify all main workflows
            1. Decompose to multiple US
            2. Story map
         2. Identify all user types
            1. User
            2. Customer
            3. Other systems
         3. Business Data Diagram (similar to ERD)
3. User Story vs. Use case
   1. Use case is BDUF - Big Design Up Front which is the antithesis of Agile
      1. Time-consuming and overly detail
         1. biz rules
         2. alternative
         3. interaction in detail
   2. User story
      1. The key to writing good User Stories is to understand that the intent is not to provide the detail early on in a project, but to provide a framework where the detail can be added as it is needed, just enough and just in time