3 C’s of a User Story Card Characteristics of a User Story Confirmati Conversatio on n
Card User stories are written on Cards It‟s used as a token for planning, analysis and tracking What a Story Card IS: It‟s a placeholder which contains just enough text to identify the requirement and to remind everyone what the story is. What a Story Card IS NOT: It‟s not a requirement document which contains all the information which makes up the requirement. Tools such as Mingle can be used to record these electronically and to track them on a shared environment.
Conversation A story is a placeholder for a Conversation and not a written contract. Customer communicates requirements to the Analyst This is largely Verbal and takes place over a period of time. These are all captured in documents called „Story Narratives‟ Face-to-face discussions are valuable, but as we get closer to an Iteration, these discussions, implementation details get committed on these narratives.
Confirmation Although a Story Card is a placeholder for discussion, we still need to know what we want to achieve with a story i.e. what the customer would want to see in order to sign-off the story. These are captured in Acceptance Criteria in the story These Acceptance Criteria are narrowed down through conversations with the customer. The developers then complete the story using the Acceptance Criteria as guidance.
Role, Process, Goal Stories are written in Simple Business language and are represented in the Role, Process, Goal format. RoleProcess Goal
Role The Role in a User Story defines who wants this requirement to be fulfilled. We mention this so that we speak to the right people and understand the story better. Role The Role is indicated by “As an administrator….” ORProcess “As a Banker….” Goal As an Internet Shopper….
Process The Process part of the story indicates what the “Role” would like to do. This is basically the set of steps they would like to perform. Role Example: As an Administrator, I want to see who is logged onto the system… ”Process Goal I want to shop using my iPhone….
Goal The „Goal‟ indicates the business value the user will get from the „Process‟. It‟s important to collect this information since it helps the customer prioritize this story against others depending on Role the value gained. Example:Process As a customer I want to withdraw money from the ATM So that I can shop using cash Goal So that I can order my package anytime, from anywhere
Characteristics of a Good Story (INVEST) Independe nt Negotia Testable ble INVEST Principle Valuabl Small e Estimabl e
Characteristics of Good Stories Independent A user story should be as independent of other stories as possible. It should be able to be developed on its own Avoids dependencies on other cards We can reduce dependencies by either combining stories or splitting the stories differently. Stories which are not independent makes planning, prioritization and estimation much more difficult. Negotiable A user story is negotiable; Its not a written contract. A good story captures the essence of whats needed but doesn‟t include details. Details are worked on during the Conversation phase. Cards with too much detail limits conversation with the customer.
Characteristics of Good Stories… Valuable When possible, stories should be vertical slices of real functionality (think of slicing a cake - you want all the layers, but a thin enough slice so you can eat it all) Valuable to the role (actor) (As an X) Valuable to the business (I want to Y) Has clear and valid business value (So I can Z) Estimable Stories are elements of planning and must be estimable If we can‟t estimate a story then it might be too large OR developers might need more domain/technical knowledge to understand it.
Characteristics of Good Stories… Small Large stories are hard to estimate and hence to plan They often hide big ticket work Should fit within one iteration Testable Stories should be testable. If you can‟t, then you will not know when you are done. They should be testable through the UI