What itch is there to scratch? Software requirements are a communication problem People who want the software must communicate with those who will build it
Balance is paramount If either side dominates, the business loses If the business side dominates ... ... functionality and dates are mandated with little regard for reality or whether the developers understand the requirements If the developers dominate ... ... technical jargon replaces the language of the business and developers lose the opportunity to learn from listening
Domination leads to ...If developers are responsible ...• May trade quality for additional features• May only partially implement a feature• May solely make decisions that should involve the business sideIf the business is responsible ...• Lengthy upfont requirements negotiation and signoff• Features are progressively dropped as deadline nears• Features are continuously changed w/o understanding of impact
Imperfect schedules We cannot perfectly predict a software schedule As users see the software, they come up with new ideas Too many intangibles Developers have a notoriously hard time estimating If we can’t perfectly predict a schedule, we can’t perfectly say what will be delivered
So what do we do? We make decision based on the ... but do it often information we have Rather than making ... we spread decision- one all-encompassing making across the set of decisions project This is were I come in!
What are user stories?Card• Stories are traditionally written on note cards• Cards may be annotated with estimates, notes, etc.Conversation• Details behind the story come out during conversations with the product ownerConfirmation• Acceptance tests confirm whether the story was coded correctly
Anatomy of a user storiesAs a <role>,I want <action that needs to be achieved>so that <goal the completed action achieves or contributes to>.Example:As an individual fundraiser,I want to be able to download the MacMillan logoso that I can use it to print all my fundraising material in high quality.
Stakeholder user storiesIn order to <achieve some outcome which contributes to the vision>As a <stakeholder>I want <some other stakeholder> <to do, use or be restricted by something>Example:In order to be in a position to launch phase 1 of SSOAs the head of digital mediaI want users to be able to login on Be.MacMillan using their My.MacMillan credentials well.
Examples As a user, I want As a photographer, I want to see a preview to order prints of of the photo book my photos before I order As a frequent flyer, I As a user, I want to rebook a past want to cancel trip so that I save my order time booking trips I take often
But ... where are the details? As a user, I want to cancel my order Does the user get a full or partial refund? Is the refund to user’s credit card or is it site credit? How far ahead must the or der be cancelled? Is that the same for all orders? For all customers? Different requirements by market? Is a confirmation provided to the user? On-screen? Email? Letter?
a) Details as conditions of satisfation • The product owner’s conditions of satisfaction can be added to a story • These are essentially tests / acceptance criteria As a user, I Verify that a VIP member can cancel the same day without a fee want to cancel Verify that a non-VIP member is charged 10% for a same-day cancellation Verify that any refunds are in site credits only my order Verify that an email confirmation is sent Verify that the factory is notified of any cancellation
b) Details added in smaller sub-stories As a VIP member, I want to cancel an order up to the last As a user, I minute want to cancel my order As a non-VIP member, I want to cancel my order within 24h of placing
Techniques can be combined Both approaches are not mutually exclusive Write stories at an appropriate level By the time it’s implemented, each story will have conditions of satisfaction associated with it
Product backlog pyramid User Stories Sprint Theme Collection of Release related user stories Epic Future A large user Releases story
Exercise 1 See how many user stories you can write about logging in Use this template “As a <user role>, I wan <goal> so that <reason>.” Examples: As a registered user, I am required to log in so that I can access the system As a forgetful user, I can request a password reminder to that I can log in if I forget mine
Writing good stories I ndependent N egotiable V aluable E stimable S mall / appropriately sized T estable
Independent As a user, I want As a user, I want to pay for my to pay for my order with VISA order with one type of credit card As a user, I want to As a user, I want pay for my order with to pay for my an additional type of order with credit card Mastercard
Negotiable As a user, I want to pay for my order with my credit card Note: Accept Visa, MasterCard and American Express. Consider Discover As a user, I want to pay for my order with my credit card Note: Accept Visa, MasterCard and American Express. Consider Discover. On purchases over £100, ask for card ID number from back of card. The system can tell what type of card it is from the 1st two digits of the card number. The system can store a card number for future use. Collect the expiration month and date of the card
Why negotiable? Main course comes with soup or salad and bread (Soup or Salad) and Bread Soup or (Salad and Bread)
Estimable It is important for developers to be able to estimate or at least take a guess at the size of a story 3 common failures 1. Developers lack technical knowledge 2. Developers lack domain knowledge 3. Story is too big
Small / Sized appropriately2 kind of epics1. Compound epic2. Complex epic Compound epic • Comprises of multiple shorter stories Complex epic • Cannot be easily disaggregated into smaller stories -> use spikes to find out how to split epics
Testable A user must find the software easy to use A user must never have to wait long for any screen to appear
Who writes them? The Product Owner!!!! Developers can help and write technical user stories if needed However, ultimate responsibility lies with the PO The PO is also responsible for prioritisation of stories
Story-writing workshops Include the whole team plus the product owner and possibly some more external stakeholders Typically not done every sprint Brainstorm to generate stories Goal is to write as many stories as possible Some will be “implementation ready” Others will be epics Start with epics and iterate NO PRIORITISATION at this point
Slicing Epics Goal: Develop slices of the problem that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end- users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software.
Slicing considerations DTSTTCPW principle (=Do The Simplest Thing That Could Possibly Work) What are the different ways that you can handle input/output data ? • You can make a story per input screen. • You can make a story per enabled elements of an input screen. • You can make a simple (not pretty) UI prototype. What scenarios are in scope for acceptance criteria? • You can work with a subset of the input data. • You can defer conditional steps to other stories. • You can defer data validation. • You can defer error handling.
Slicing considerations What architecture decisions can be deferred? • You can defer optimisation of performance. • You can defer internationalisation • You can defer handling large volumes of data Worklow steps Performance Spikes Quality Things you know / don’t know
Horizontal slicing & sizing Try not to slice stories along technical lines Slice them horizontally for as long as you possibly can 1) Exercising every layer reduces risk of finding last minute problems in one of the layers 2) Application with reduced functionality can still be released Example: “A job user can post a CV” (epic) -> “A job seeker can fill out a CV form” -> “Information on a resume form is written to the db” Correct: -> “A job seeker can submit a CV that includes only basic information such as name, address and work history” -> “A job seeker can submit a CV with all information an employer may want to see”
Exercise 2 Remember: 1. Who writes user stories? Employees can purchase 2. User role parking passes 3. User story format 4. Aim / goal / business value As an employee I want to Buyer is charged fee for 1 month only time One pass for one month is issues at a purchase a parking pass No pass is issued if payment is insufficient so that I can drive to work Buyer must be can only buy one pass per a current employee Any employee month
Exercise 3 Remember: 1. Who writes user stories? Users can sort cards by 2. User role popularity 3. User story format 4. Aim / goal / business value User can sort by most popular 1st As a customer I want to Timeframe for popularity is last 2 sort available cards by weeks popularity so that I can Sorting mechanism works will all filters easily access the Sorting takes no longer than 2 seconds bestsellers User can un-sort without losing applied filters
Non-functional requirements For some requirements it’s inefficient to be captured in user stories because they apply to all of them Example 1: “The system must support peak usage of up to 50 concurrent users” Example 2: “Do not make it hard to i18n the software later if needed” Constraint Write constraint cards and The software must keep them visible run on all versions of Windows 2k +
Closed stories When breaking down stories aim for closed stories Closed stories end with the achievement of a meaningful goal Example: “A user can reprint previous orders”
Keep UI out as long as possible Agile is about conversations and discussions Eventually inevitable Keep stories with UI elements until a later sprint when stories shift from being new functionality to being modification of existing functionality Example: “A user can select dates from a date widget on the search screen”
This smells Too many interdependent stories -> make stories larger or slice them differently Goldplating -> increase visibility of tasks & workload Too many details -> if you run out of room, use smaller cards Thinking too far ahead -> stop Splitting too many stories PO can’t prioritise -> close look at value
Recognising smells Developer responsibilities You share a responsibility with the PO to be aware of these smells as well as any others you may detect. Work and correct any that affect the project PO responsibilities You share a responsibility with the PO to be aware of these smells as well as any others you may detect. Work and correct any that affect the project