User Story: is • A user story is a very high-‐level deﬁni@on of a requirement, containing just enough informa@on so that the developers can produce a reasonable es@mate of the eﬀort to implement it.
User Story • Deﬁne 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!
User Story: is not • It is not a use case or a soIware requirement, i.e. a formal and long speciﬁca@on document • One of the biggest misunderstandings with user stories is how they diﬀer from tradi@onal requirements speciﬁca@ons
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 oﬃcial transcripts. Students can only enroll in seminars for which they have prerequisites. Transcripts will be available online via a standard browser.
#52 Students can purchase monthly parking passes online Priority: 8 Estimate: 4
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 insuﬃcient 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
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, ﬁnancial 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”
Beneﬁts • XP and other agile methodologies favor face-‐ to-‐face communica@on over comprehensive documenta@on and quick adapta@on to change instead of ﬁxa@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 reﬁnement process. • Making it easier to es@mate development eﬀort