user stories writing - bettersoftware 2012
DESCRIPTION
These are the slides of the workshop on "User Story Writing" I held with Stefano Leli @Bettersoftware 2012.TRANSCRIPT
What is a User Story?
User Story: is
• A user story is a very high-‐level defini@on of a requirement, containing just enough informa@on so that the developers can produce a reasonable es@mate of the effort to implement it.
User Story
• Define a valuable user value story • implement and test it in a short itera5on • demonstrate/and or deliver it to the user • capture feedback • learn • repeat forever!
What a "User Story" is not
User Story: is not
• It is not a use case or a soIware requirement, i.e. a formal and long specifica@on document
• One of the biggest misunderstandings with user stories is how they differ from tradi@onal requirements specifica@ons
Ini@al User Stories (informal)
Example User Stories Students can purchase monthly parking passes online. Parking passes can be paid via credit cards. Parking passes can be paid via PayPal ™. Professors can input student marks. Students can obtain their current seminar schedule. Students can order official transcripts. Students can only enroll in seminars for which they have prerequisites. Transcripts will be available online via a standard browser.
Students can purchase monthly
parking passes online
#52
Priority: 8 Estimate: 4
Ini@al User Stories (formal)
As <type of user>, <func5on> so that I can achieve <some-‐goal>
Purchase Monthly Parking Pass As a student I want to purchase an online monthly parking pass so that I can drive to school.
#52
Priority: Must Estimate: 5
3 C
3 C Card, conversa@on & confirma@on
Card
Card user stories need to be short and concise enough so that they can fit on
a single card
Conversa@on
Conversa@on the conversa@on is much much more important than the story itself
Confirma@on
Confirma@on by defini@on, user stories must be testable
INVEST in your User Stories
INVEST in User Stories • Independent
Avoid dependencies with other stories Write stories to establish founda@on Combine stories if possible to deliver in a single itera@on
• Nego+able Stories are not a contract Too much detail up front gives the impression that more discussion on the story is not necessary
Not every story must be nego@able, constraints may exist that prevent it
• Valuable Each story should show value to the Users, Customers, and Stakeholders
INVEST in User Stories • Es+mable
Enough detail should be listed to allow the team to es@mate The team will encounter problems es@ma@ng if the story is too big, if insufficient informa@on is provided, or if there is a lack of domain knowledge
• Sized Appropriately Each story should be small enough to be completed in a single itera@on Stories that may be worked on in the near future should be smaller and more detailed
Larger stories are acceptable if planned further out (Epics)
• Testable Acceptance criteria should be stated in customer terms Tests should be automated whenever possible All team members should demand clear acceptance criteria
User Stories (planning)
Epics
Epics
• Epics are large user stories, typically ones which are too big to implement in a single itera@on and therefore they need to be disaggregated into smaller user stories at some point.
Themes
Themes
• A theme is a collec@on of related user stories. • For example, for a university registra@on system there might be themes around students, course management, transcript genera@on, grade administra@on, financial processing.
• Themes are oIen used to organize stories into releases or to organize them so that various sub-‐teams can work on them.
Kano Model According to Kano, there are 3 classes of features: • Prerequisites -‐ If your product doesn’t have these features, it will immediately be removed from considera@on. Who wants a house without a bathroom?
• Linear Features -‐ The more the be]er, but their higher the cost. A family that wants three bedrooms will not consider a house with one, but they might consider a house with 2 or 4 bedrooms.
• Exciters -‐ Unique features which only this product has and which convince the customer to say “Yes! I want it! This one and no other”
CMS 1.0 (Hands-‐On)
User Story (spligng)
CMS 1.1 (Hands-‐On)
Benefits
Benefits
• XP and other agile methodologies favor face-‐to-‐face communica@on over comprehensive documenta@on and quick adapta@on to change instead of fixa@on on the problem.
User stories achieve this by: • Being very short. They represent small chunks of business value that can
be implemented in a period of days to weeks.
• Allowing developer and the client representa@ve to discuss requirements throughout the project life@me
• Needing very li]le maintenance
• Only being considered at the @me of use
• Maintaining a close customer contact
• Allowing projects to be broken into small increments
• Being suited to projects where the requirements are vola@le or poorly understood. Itera@ons of discovery drive the refinement process.
• Making it easier to es@mate development effort
Limita@ons
Limita@ons
Some of the limita@ons of user stories in agile methodologies: • They can be difficult to scale to large projects • They are regarded as conversa@on starters
