In this session we’ll talk mainly about user stories and not the overall methodology. Some of that will creep in along the way, but we won’t focus on it.

All you really need to know about agile for today is: Communicate more, Cut out waste by questioning the process, and work in smaller increments.

what is a user story: a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

Typical formatsAs a, I want to becauseAs a temporary library employee, I want to check in these books, so they can be reshelved.

Given, when, then – enables more contexts (givens) & outcomes (thens.)Given that I am new here, when a patron returns a book, then enable me to check it in and tell me where it goes.

Remember Personas – think about the motivation of the subject of the story. E.g. "As a library patron, I want to log in because ….. why?" A user doesn't want to log in ever. The story may be "As the system owner, I want users to log in so we can ensure proper authorization / use of our data/ system /// .. " Or what else? WHY do we want people to log in? be clear about it.

•How user stories are different from requirements - The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the customer and receive a detailed description of the requirements face to face. Focus on user needs. Avoid details of specific technology, data base layout, and algorithms.

•How user stories are different from Use Cases – What the user wants to do versus specific ways in which the user may do it. ** User stories should typically address only ONE, happy-path scenario for how the system will be used. ***Details usually found in a use case should not be part of the user story. User stories should be one sentence. (Use cases or other dialog about specific use/intention comes later, during development – as a conversation.)

•What is acceptance criteria? - define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. Essentially – what grade/level of quality is acceptable for the story? (e.g. is a confirmation necessary? Is data validated before saving? Don't just state the story in reverse. "As a patron, I want to find a book in your library." Acceptance: (perhaps) Tell user whether or not we own the book. Tell user whether the book is available. Tell user shelving location. Tell user about other formats.)

Iterative Design & Refactoring> We don’t want to end up with this…

… nor design for this….

User Story: Just get across the chasm - To find out if that’s the place we want to goOne person at a time

Build in flexibility:>NOT so you can add specific features later>But so you can address UNKNOWN change with minimal impactBuild in Quality:>Appropriate architecture and completeness ONLY for the requirements given.>Quality – make sure the rope isn’t frayed and is tied tightly Iteration zero –

needed or not?

User Story: Just get across the chasm - To find out if that’s the place we want to goOne person at a time

The best way to build in flexibility and quality is to remain SIMPLE as long as possible.

You *might* assume that the bridge will need to be bigger/ heartier in time .. but the requirement TODAY is to get one person across. Will you still use the wire when this becomes a highway bridge? Probably not – but don't sink enormous pilings to string up a wire just because it'll probably need to be replaced in the future. Today, just get it across as quickly and cheaply as possible – BUT, make sure the structure is sound & safe to use. (i.e. use appropriate architecture that will be easy to modify IF needed.)

Story: I want to get there faster and with less effortDesign a pulley systemQuality - Can it still hold the weight? Do the pulleys turn freely?

Negotiable quality – is there a secondary safety line? Should the rider have a helmet?

Story: More stable & user friendlyHolds more weightMost people can get acrossQuality: strong lashings. (NOT easily removed later when if you want to upgrade the bridge!)

Story: More durable – more trafficHolds more weightAverage vehicles can get acrossQuality: Solid architecture to hold a car, but not meant to hold two cars or support high speed traffic.

>Rope bridge is a sunk cost.>How much will it cost to refactor the rope bridge?>Is it worth it?

Story: More scalable – able to support a tank …Holds more weightAny vehicle can get across, many at onceQuality: This is the mature product that meets the vision. ..until ……

Story: Support ancillary value propositionsQuality: Is the existing structure capable of supporting additional functions? Or is it a significant change that requires cost justification?

Sell More Sell/Implement Sooner/ Faster

Sustained Growth &

Reduce Cost

Business Drivers

Workflow Efficiency Reuse Data System Stability

& SecuritySystem

Scalability

Integrate other tools ImportLess reliance

on experts Export SecurityFix existing records

Macros and

templates

Batch operations

Process FasterRecord Quality

Measure Performance

Improve Performance

QA new records

Categories

SuperEpics

Exciters Basic/Core Nonfunctional

How to handle iteration zero & infrastructure stories

Consider the *other* personas involved in the system:1. As an architect, I want to reduce the time we currently spent on design reviews - so we can get them done earlier in the process.2. As a product owner, I want to use automated tests to ensure quality.3. As a developer, I want to version control my code because I expect to make frequent, incremental changes.

INVESTIndependent Negotiable

Valuable Estimable

SmallTestable

A few good practices:•INVEST•Keep stories small , do the simplest thing possible•Keep stories singular - no 'if/else' or 'what if' conditions (Use cases –vs- user stories.) "I want to borrow a book." .. Assume the book is available. Assume I don't have $600 in fines, …

Refactoring: In order to add these requirements later, we'll have to create stories & develop them – LATER. Will that mean rework? Probably. Accept it – that's OK. Costs less to rework later than to develop functionality that won't be used or will delay release. When you do refactor: 1) Do it right for the requirements in front of you. 2) Assess the cost of adding the requirement – do you really want it?

Early stories – focus on delivering value – get the product right first & focus on the inner workings after getting some user feedback. “Go ugly, early.”

Exercise – write user stories for : creating a vending machine for drinks

Start with the basic story: As a thirsty person, I want to buy a drink from your vending machine What would the acceptance be? Remember – thin slices and do the simplest thing.:Machine will take my money Machine will have a drink selection mechanism (eg select product by position on shelf, or by drink name, etc) Machine will deliver drink Negotiable criteria: (Maybe these are specified or maybe they are not required to address yet.)

Will give me change back  Won't take money if sold out Won't let me get two drinks, ensures I paid first, ...