Misc notes (please refactor):

---

Use Cases are difficult for customers to understand/comprehend/create.

A User Story is something of value to a user or customer.

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

User Stories replace requirements.

Simple (traditional) functional requirements are too small to describe/represent value.

User Stories describe end to end use/value.

With just a few User Stories, it's easy to get started developing.

User Stories are small, easy to write and understand.

With User Stories, you don't have to teach the user/customer how to write a (traditional, detailed) requirements document.

You still have to guide customers on writing good User Stories.

User Stories serve as a starting point for further conversation.

A User Story serves as a base for creating an Acceptance Test.

Discuss testing the User Story, while developing the User Story.

New User Stories emerge when developing Acceptance Tests.

("How will I know when I'm done.")

(Orthogonal conversation on convincing management to move to XP.)

---

Who writes User Stories?

Customers, System Analysts, Developers, Testers, QA, Project Managers, Product Managers

---

Ideas on Organizing User Stories

Collect User Stories into themes, with 3 to 20 stories per theme.

(Poker chip example, related to customer choosing what to implement.)

---

How do you prove that you've met the requirements?

Write testable User Stories.

What about when outsourcing?

---

Splitting Stories - When does a new User Story emerge from an existing User Story?

As soon as you become uncomfortable estimating the story.

Prefer smaller User Stories.

High performance versus Low performance

Different inputs

Base case versus Special case (Happy Path versus Exceptions and Errors)

---