How to Break the Requirements into User StoriesPresentation Transcript
How to Break the Requirements into User Stories - By ShriKant Vashishtha http://sampreshan.svashishtha.com
Why do we do this…• To have small and independent functional pieces which deliver business value so that we can deliver iteratively.• Makes it more manageable and easier to predict.• It’s easier to identify and eliminate waste (anything that does not provide immediate value to the customer.)• It lowers project risk by increasing accuracy of estimates and thus predictability
Why do we do this…• Completing small stories gives a better indicator of true progress• It creates better rhythm in the iteration• It gives the opportunity for the Product Owner to manage the priority of story functionality within a bigger story
Characteristics of Ideal small functional piece INVEST Principles• I – Independent – (Stories are easiest to work with if they are independent. That is, wed like them to not overlap in concept, and wed like to be able to schedule and implement them in any order)• N – Negotiable – (It is not an explicit contract for features; rather, details will be co-created by the customer and programmer during development. A good story captures the essence, not the details.)• V – Valuable – (We dont care about value to just anybody; it needs to be valuable to the customer. When we split a story, were serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers.)• E – Estimable – (We dont need an exact estimate, but just enough to help the customer rank and schedule the storys implementation. )• S – Small – (Good stories tend to be small. Stories typically represent at most a few person-days worth of work. Above this size, and it seems to be too hard to know whats in the storys scope. Smaller stories tend to get more accurate estimates.)• T – Testable – (If a customer doesnt know how to test something, this may indicate that the story isnt clear enough, or that it doesnt reflect something valuable to them, or that the customer just needs help in testing. )
Who is involved…• The core team which includes – Business Analysts – Product Owner – Iteration Manager
How to actually do it?
Pattern 1: Workflow Steps“As a content manager, I can publish a news story to thecorporate website.” can include the following independent stories• I can publish a news story directly to the corporate website.• I can publish a news story with editor review.• I can publish a news story with legal review.• I can view a news story on a staging site.• I can publish a news story from the staging site to production.
Pattern 3: Major Effort“As a user, I can pay for my flight with VISA, MasterCard,Diners Club, or American Express.” can include the following valuable and small stories• …I can pay with one credit card type (of VISA, MC, DC, AMEX).• …I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).
Pattern 4 : Break out with a Spike“As a user, I can pay by credit card.” can include the following estimable stories• Investigate credit card processing. (time boxed)• Implement credit card processing.
Pattern 5: Business Rule Variation“As a user, I can search for flights with flexibledates..” can include the following testable "business rules”• as “n days between x and y.”• as “a weekend in December.”• as “± n days of x and y.”
Pattern 6: Operations (e.g. CRUD)“As a user, I can manage my account.” can include the following independent user stories• …I can sign up for an account.• …I can edit my account settings.• …I can cancel my account.
Pattern 7: Defer fancy operations“As a user, I can search for flights between twodestinations.” can include the following valuable user-stories• …using simple date input.• …with a fancy calendar UI.
Pattern 8: Acceptance Criteria• Often it is possible to limit the user story to the happy day scenario only• And deal with exceptions, error cases or other special cases as different story.