• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
User Stories
 

User Stories

on

  • 1,982 views

 

Statistics

Views

Total Views
1,982
Views on SlideShare
1,982
Embed Views
0

Actions

Likes
2
Downloads
128
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

User Stories User Stories Presentation Transcript

  • User Stories James Peckham (Extracted from Mike Cohn’s Book “User Stories Applied”)
  • Customer Team
    • (Acceptance) Testers
    • Product manager
    • Real users
    • Interaction designers
  • Developer
    • DBA
    • Technical Writer (Documentation)
    • Programmer
    • Build master/wrangler
  • What is a user story?
    • Card
    • Conversation
    • Confirmation
  • Where are the details?
    • One thing to say, another to code and test…
      • I want to post jobs
    • Additional stories?
    • Confirmation through tests!
  • What do I write
    • Theme
      • I want a Job board
    • Epic
    • Story
  • Epic
      • A user can search for a job
      • A company can post job openings
  • Story
      • A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted
      • A user can view information about each job that is matched by a search
      • A user can view detailed information about a company that has posted a job
  • What do I Write?
    • Don’t have to go this far
      • A user can view a job description
      • A user can view jobs salary range
      • A user can view the location of a job
    • Don’t have to do requirements style
      • 4.6)A user can view information about each job that is matched by a search
        • 4.6.1) a user can view the job description
        • 4.6.2) a user can view a job’s salary range.
        • 4.6.3) a user can view the location of a job
  • What is the process like?
    • Not like waterfall
      • User/Proxy can’t just say what the stories are then go away.
      • Users/Proxy should Play active role in writing stories
        • Why wouldn’t you want to be involved with writing the stories?
        • Written in language of the business instead of tech jargon. (this will help with prioritization and choosing of stories for planning releases)
  • How long does it have to be?
    • On the back of the card a reminder for tests
      • Try with empty job description
      • Try with a really long job description
      • Try with missing salary
      • Try with six digit salary
  • When do we write them?
    • Story writing workshop
    • During demo
    • Any time you want!
      • Get business language! (easy to read, no technical jargon!)
  • Planning releases
    • Guess velocity for first iteration!
    • Choose iteration length 1-4 weeks
    • Arrange stories into releases.
  • What are acceptance tests?
    • Write tests early as possible
    • Communicate earlier such as
      • A user can pay for the items in her shopping cart with a credit card
        • Test with visa, MC, Amex (pass).
        • Test with diners club (fail)
        • Test with visa debit card (pass)
        • Test with good, bad and missing ID numbers from back of card
        • Test with expired cards
        • Test with different purchase amounts (including over limit)
  • Why?
    • Emphasize verbal rather than written communication (proven better!)
    • User stories comprehensible by both users and developers
    • Right size for planning and estimating
    • Work for iterative and incremental development
    • Encourage deferring the detail until you have the best understanding of what you really need.
  • Writing Stories Chapter 2
  • INVEST
    • Independent
    • Negotiable
    • Valuable to users or customers
    • Estimable
    • Small
    • Testable
  • Independent
    • Care taken to introduce as little dependencies as possible.
    • BAD
      • Company can pay for a job posting with a visa card
      • Company can pay for a job posting with a master card
      • Company can pay for a job posting with an American Express
    • Good
      • Company can pay for a job posting with a credit card
    • Also good
      • Company can pay for a job posting with one type of a credit card
      • Company can pay for a job posting with two additional types of credit cards
    • Last resort
      • Two estimates on the card i.e. 8/3
  • Negotiable
    • Not contracts
    • Tough to include Just enough detail
    • Putting note at the bottom of card, but leaving it open to be negotiable.
    • Mistake extra detail as extra precision and forget the conversation.
    • A phrase to remind for conversation
    • A note or two to remind for any further negotiation/issues.
  • Valuable to purchasers or users
    • Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit. -- purchaser
    • Not
      • All connections to the database are through a connection pool
      • All error handling and logging is done through a set of common classes.
    • If there’s a technical story put it in terms the business can understand
      • Up to fifty users should be able to use the application with a five-user database license
      • All errors are presented to the user and logged in a consistent manner.
  • Estimable
    • Common reasons why they’re not
      • Lack domain knowledge
        • Can discuss with business people and learn
      • Lack technical knowledge
        • Can spike on the story to learn more about it
          • Two stories, one for the spike one for the real work
      • Story is too big
        • Sometimes useful to write the epic to be a placeholder for some glossed over part of a system.
          • Pulled from thin air estimate!
        • Or break it down.
  • Small
    • Size does matter
      • A user can plan a vacation (EPIC)
    • Based on team and capabilities and technology in use.
    • Compound or complex Epic stories.
    • Too much for a slide… page 24
  • Testable
    • User must find the software easy to use.
      • A novice user is able to complete common workflows without training
    • A user must not have to wait long for a screen to appear.
      • New screens appear within two seconds in 95% of all cases.
    • Strive for 99% automation
    • Automate on the code not just the UI.
      • Fit is good
      • NUnit is good
  • User role Modeling Chapter 3
  • User Roles
    • Examples
      • Job Seeker
      • Employer
      • Administrator
      • Helpdesk agent
  • steps
    • Brainstorm initial set
    • Organize set
    • Consolidate the roles
    • Refine the roles
  • Brainstorming roles
    • Before any project (before any theme of stories)
    • Grab stack of cards
    • Timebox
    • Write as many names of people and their role in using the software.
    • 15min or less usually.
  • Organize cards
    • Find the description of a higher grouping and start filtering into those groups all the cards.
    • Arrange on a table.
  • Consolidate roles
    • Read any that sound similar. If it’s redundant find a common name and remove the extras.
    • If there’s no reason to distinguish, remove.
  • Refine roles
    • Attributes worth considering in distinguishing from one role to another
      • Frequency with which the user will use software
      • Users level of expertise with the domain
      • Users general level of proficiency with computers and software
      • Users level of proficiency with the software being developed
      • General goal for using the software
        • Rich experience,
        • Convenience
  • optional techniques for roles
    • Personas
      • Mario works as a recruiter in the personnel department of speedy networks, a manufacturer of high end …. etc
    • Extreme characters
      • Consider a PDA for:
        • BMW driving management consultant
        • The pope
        • Drug dealer
  • Gathering stories chapter4
  • Trawling
    • Big wide net, get all the big fish.
    • Then start casting smaller nets.
    • Why isn’t little enough?
      • Prescriptive process feel…
      • Can evolve from the epic to more stories later on!
  • techniques
    • User interviews
    • Questionnaires
    • Observation
    • Story-writing workshops
  • interviews
    • Real users when possible
    • You build what I asked for but that’s not what I want!
    • Just because they have the knowledge doesn’t mean they know the way to implement
      • Complex mini-language lesson-  visual designer instead.
  • Open ended and context free questions
    • Would you like that app to be in a browser?
    • Would you like our new app in a browser rather than a native windows application even if it means reduced performance, poorer overall user experience, and less interactivity?
    • How fast do searches need to be?
    • What performance is required? Is performance more important in some parts of the application?
  • Questionnaires
    • Gather info on stories from bigger user base
    • Large number of answers for a specific question
    • Bad
      • “What features would you like to see”
        • Miss things if you give them a multiple choice
        • Hard to tabulate if open text
  • Story Writing Workshops
    • Who
      • Developers
      • Users
      • Product customer
      • Other stakeholders
    • Low fidelity prototyping
      • whiteboard,
      • Note cards
      • Paper
    • Component layout
    • Throw away the low-fidelity prototype!
    • Access competitive products if you’re stuck!
  • Developer responsibilities
    • Understand and use multiple techniques while trawling
    • Make best use of open ended and context free questions
  • Customer responsibilities
    • Understand and use multiple techniques while trawling for stories
    • Writing as many stories as early as possible
    • Main representative of the software and responsible for options in communicating with them
    • If you need or want help responsible for scheduling and running story writing workshops
    • Responsible for making sure all roles are appropriately represented
  • Working with user proxies Chapter 5
  • Selecting user proxies
    • It’s difficult to get all the right real users
      • But important to try!
    • Can’t get our user because of their manager (a helpdesk, NOC, etc)
      • Bring manager in
      • Corroborate
    • Development manager = worst proxy possible! 
    • Sales Person = bad proxy but great way to get introduced to good users.
  • Domain experts
    • Great domain modelers
      • Can put definitions to unique domain language
      • Identify business rules
    • Real user better
      • For interactions with the software
  • Marketing group
    • Focus on quantity of features rather than the quality of those features
    • Might not have insight to provide detail about those stories*
  • Former Users
    • Experience will expire!
  • Customers
    • Buyers not necessarily users!
  • Trainers and tech support
    • Ease of training
    • Ease of supporting
    • Good goals, but what’s important?
  • Business or System analyst
    • One foot in tech one foot in the domain.
    • Tendency to be forced into thinking the problem out instead of getting the information from the users.
    • 3 weeks to figure out a story instead of a 2 hour session.*
  • What to do when working with proxy
    • When users exist but access is limited
      • User task force story writers under a proxy
    • When there is no user available
      • Use more than one
      • Competing products
      • Reviews of their products
    • Can you do it yourself?
      • Avoid it!
        • Developers won’t have the ‘closeness’ with user-base
        • Even if Developers are the users!
          • Especially if the Developers are the users! Cherry pick!
    • Constituting the Customer team
      • Put real users on the customer team!
  • Dev responsibilities
    • Organize and select appropriate customer
    • Understand how different user proxies can affect the system being built and influence the interactions.
  • Customer Responsibilities
    • If you’re not the user, know the proxy type that describes you!
    • Understand what biases you may bring to the table and work towards overcoming them.
  • Acceptance Testing User Stories Chapter 6
  • Write tests before coding
    • When?
      • Capture specific details when talking
      • At the start of the iteration before programming begins
      • When new tests are discovered after the programming of a story
    • Considerations
      • What else would a programmer need?
      • What am I assuming?
      • Are there circumstances where this story will be different?
      • What could go wrong?
  • Customer Team Specifies tests
    • Because it’s their vision!
    • They can work with a programmer to create the tests.
    • Testers can augment the tests of course to better suite the need.
  • Testing is part of the process
    • Not something you do “At the end”
    • Testers can’t learn of the system from the programmers.
    • In the process
      • Write a test
      • Write code to support the test
      • Think of more tests.
  • How many are too many?
    • Continue to write as long as they add value or clarity to the story.
    • Good programming teams will have Unit Tests in place that handle low level things.
      • i.e. feb 30 th not a real date
  • Framework Integrated Test
    • Spreadsheet/data table tests
    • Action tests
    • Requires test harness development (a programmer)
    • Requires decoupling from User interface
    • Fitnesse
      • Wiki based execution of FIT tests
  • Types of tests
    • Mike Cohn’s ‘reason’ list
      • User interface tests
      • Usability testing
      • Performance testing
      • Stress Testing
    • Crystal Clear ‘how’ List
      • GUI based acceptance (Expensive and slow)
      • GUI-less acceptance
      • Unit Tests
  • Developer responsibilities
    • Automating
    • Thinking of additional tests
    • Unit testing code so acceptance tests don’t need specified for low hanging fruit
  • Customer Team Responsibilities
    • Responsible for acceptance tests
    • Responsible for executing tests
  • Guidelines for good stories Chapter 7
  • Start with goal stories
    • Search for jobs
    • Automate search process so she doesn’t have to search manually each time
    • Make her resume available so that companies may search for her
    • Easily apply for any jobs she likes
  • Slice the cake
    • When there’s a large story
      • Developers will try to split it along technical lines
        • Job seeker will fill out resume form
        • Resume form will be submitted to database
      • Make sure to focus on business value
        • A job seeker can submit a resume that includes only basic information such as name, address, education history.
        • A job seeker can submit a resume that includes all information an employer needs to see.
      • This forces the developers to span the whole architecture earlier on in a simpler manner
        • Reduces risk
        • Focus on working software/shippable product!
  • Write closed stories
    • Have a clear goal being met with the story
      • Bad
        • A recruiter can manage the ad she has placed
      • Good
        • A recruiter can review resumes from applicants to one of her ads
        • A recruiter can change the recruiter date of an ad
        • A recruiter can delete an application that is not a good match for a job
  • Put constraints on cards
    • Something that must be observed, not implemented.
      • The system must support peak usage of up to 50 concurrent users
      • Do not make it hard to internationalize the software if needed later
      • The new system must use our existing order database
  • Size stories to the horizon
    • A job seeker can post a resume
    • A job seeker can search job openings
    • A recruiter can post a job opening
    • A recruiter can search resumes
    • Focus on posting resumes first!
      • Add resume, edit resume, remove resume, mark inactive, mark hidden, see how many views.
  • Keep the UI out as long as possible
    • Mixing requirements with solution specification!
  • Some things aren’t stories
    • In a few cases, such as external vendor
      • Screen mock
      • Use case
      • UML Diagram
      • Specification
      • etc
  • Include user roles in stories
    • as a (role) I want (function) because (business value)
  • Write for one user
    • Job seeker can remove a resume
    • Job seeker can remove her own resume
  • Write in active voice
    • Bad
      • A resume can be posted by a job seeker
    • Good
      • A job seeker can post a resume
  • Customer writes
    • Not developer
      • But they can suggest
        • Which maybe is write them then get signoff
      • Offer advice
    • In the end the customer has to prioritize them so they need to know the language on the card fully.
  • Don’t number the cards
    • Pointless over head
    • You’ll be shredding cards and creating cards often
  • Don’t forget the purpose
    • Reminder about the requirements not the document of the requirements.
    • Don’t replace the conversation by adding the detail.
  • Estimating and Planning PART II
  • Estimating stories Chapter 8
  • Story points
    • Relative to eachother
    • Nebulous units of time (NUTs)
    • Ideal days
    • Easier than estimating time.
      • How many centimeters are in this line
      • How ‘big’ is this line
      • Where is halfway on this line
      • Where is 1 quarter on this line
  • Estimate as a team
    • Who is ‘the team’
      • Everyone who’s going to do the work.
    • Collective ownership
      • Won’t know who will do the work
    • Less chance for sandbagging or low-balling
    • Customer does not interfere with estimate, but can contribute**
  • Estimating
    • Hear about the story
    • Ask as many questions as needed to know what is needed
    • Write estimate on on cards or use existing cards
    • All show estimate
    • Talk about why the low and the high
    • Re-bid
    • If the team cannot come to consensus then “Do something”**
  • Everything takes 4 hours
    • Keep in mind everything that has to happen to complete the story.
      • Unit test
      • Refactoring
      • Talking to the customer
      • Enterprise specific “stuff”
      • Code review
      • <Your organization/team/customers definition of “DONE”>
  • Triangulate
    • Refer to other stories you’ve already estimated.
  • Using points as team velocity
    • Check ‘yesterdays weather’
    • Don’t take more than that
      • Maybe stretch tasks**
  • What if we’re pair programming?
    • Ideal pair days
    • “I feel” this is no different than “done”. If we’re suppose to pair program it’s assumed in our estimate of done. (code review)
  • Precision decreases as size increases
    • ½,1,2,3,5,8,13,20,40,80
      • Don’t have to think about is it a 79 or 80
  • confusions
    • Not equivalent to any other team’s points
    • Sum of smaller stories will not equal the theme or epic they came from
    • Sum of tasks will not be equal to the estimate of the initial story.
  • Customer responsibillities
    • Answer questions
    • Don’t estimate
    • Don’t urge lower/higher estimates
  • Developer responsibilities
    • Define story points in a manner that are relavent and sticking with that definition
    • Give honest estimates. Don’t give into pressure to be lower. Don’t sandbag because it won’t help the situation it just increases your velocity and sets you up for failure later.
    • Pair programming doesn’t affect points only affects team velocity.
  • Planning a release Chapter 9
  • When do we want to release?
    • Setup the buckets to put stories in for a release and then put dates on them.
      • In scrumworks as you begin to burn down you’ll see how you faire with that date.
      • You can plan based on team velocity (if established)
        • You can guess a team velocity.
  • What would you like it in
    • Must have
    • Should have
    • Could have
    • Won’t have this time
  • Prioritizing stories
    • But they’re all #1 priority! 
    • The risk
    • Impact to other stories
    • Desirability to broad base of users
    • Desirability to small but important base of users!
    • Cohesiveness of a story to another story (not dependency, see INVEST)
    • Developers will have a preference of implementation path. Customer wins these.
  • Cost Changes Priority
    • Enter key to move between fields because of DOS**
    • So: customer can choose and we have to give them visibility into what will happen with their choices.
  • Risky Stories
    • Juicy bits first!
    • Visibility into the risks.
      • If you develop this story before this other story then there is “this” risk.
  • Prioritizing Infrastructure
    • Be able to generate 50 stock images per second.
    • If something like this is lower priority talk about the infrastructure need and how hard it is to refactor.
  • Iteration Length
    • Avoid random changes to iteration length
    • Longer = less over head
    • Shorter = less chance for development to go off the rails.
    • No longer than a month
    • No shorter than a week.
    • Scrum = 30 days
    • XP = 1-2 weeks
    • It’s good to sync up with other teams in the organization.
      • Evolve a culture that supports planning meetings, standups, and demo-days
  • From points to duration
    • 100 points
    • Iteration of 1 week was 10 pnts
    • 10 weeks
  • Initial velocity
    • Do an initial iteration and use that as velocity
      • Iteration 0
    • Use historical values
    • Take a guess!
      • Hopefully stories are small enough to guess how much time they’ll take.
  • Creating the release plan
    • Pin to the wall
    • Spreadsheet
    • Photocopied stories
    • Gannt charts
      • Iteration 1
        • Story 1
        • Story 2
      • Iteration 2
        • Story 3
        • Story 4
  • Warning
    • Be careful of saying “we’ll be done june 4 th ”
    • Say we’ll be done in 7-9 iterations.
    • Especially during first few releases
    • Especially if the team composition changes alot
  • Developer responsibilities
    • Provide info to prioritize
      • Risks
      • Infrastructure
    • Create release plan based on realistic estimates
      • Appropriate project buffer (deployment concerns, etc)
  • Customer Responsibilities
    • Prioritize stories into precise order you value them.
      • Not just stacks of high, medium, low.
    • Expressing honest deadlines
      • Don’t say june 15 th to be safe if august 15 th is ok
    • Understand difference between ideal time and calendar time
    • Split stories that contain components you want to prioritize differently.
    • Understand when a single developer has less velocity than another.
  • Planning an iteration Chapter 10
  • Iteration plan overview
    • Discuss a story
    • Disaggregate the story into tasks (decompose)
    • One developer accepts responsibility for each task
    • Estimate the tasks, ensure they’re not overcommitted.
  • Discuss the story
    • Customer start with highest priority story
    • Ask questions until they understand enough to break it into tasks (don’t need the complete detail of everything in the world!)
      • Not everyone needs the gross detail
      • The dev can work with the customer to get the detail once they’re on the task
    • Changing priorities
      • Implementations of database**
  • Decompose to tasks
    • No art, but stuff imagine this story: “A user can search for a hotel on various fields”
      • Code basic search screen
      • Code advanced search screen
      • Code results screen
      • Write and tune sql to query for basic searches
      • Write and tune sql to query for advanced searches
      • Document new functionality in help system and users guide
  • Guidelines
    • If something is hard to estimate, don’t have it in the story. Have it live without a story. (scrumworks won’t support this, so add a backlog item for ‘sprint 2 homeless tasks’)
    • Separate tasks by developers
    • If there’s need to know that a section of the story is done, break that out as a task (i.e. screen and some code behind)
  • Accepting Responsibility
    • Write them up, someone accepts and owns.
    • Everyone’s responsibility to make sure the tasks gets done “we’re all in this together”
    • No one should say “well I finished my work but Tom has tasks left”
  • Estimate and confirm
    • By this point tasks should be small enough to be reliable
    • If not, don’t worry, guess and move on.
    • Add up the ideal hours and see if it’s realistic.
      • Let someone take something
      • Hope for the best
      • Drop a story
  • Developer responsibilities
    • Participate in iteration planning
    • Responsible for decomposing into tasks, NOT just the stories you’re going to work on.
    • Accepting responsibility for tasks you will work on
    • Ensuring you take the appropriate amount of work
    • Monitoring the amount of work you have left and your teammates work. If you’re likely to finish early, help your teammate.
  • Customer responsibilities
    • Prioritize stories
    • Directing developers toward best business value you can. If higher values have come to light since. Adjust priority.
    • Participate in iteration planning to field questions.
  • Measuring and monitoring velocity
    • Measuring
      • Planned vs actual
      • Burndown charts
      • Hours remaining NOT expended
    • Monitoring
      • Information Radiators**
      • Task board
      • Burn board
      • Impediment Board
  • Developer responsibilities
    • Complete a story before moving onto the next.
    • Understand impact any decision you make on the velocity of the project
    • Understand how to read the charts
    • If manager/tracker understand when to produce the charts and how.
  • Customer Responsibilities
    • Understand how to read and interpret the charts shown in this chapter
    • Know the velocity of the team
    • Know the actual velocity and how it compares to planned velocity and whether to correct.
    • Add or remove stories from the release to ensure objectives are met.
  • Part III FAQ
  • Stories aren’t IEEE830
    • The system shall
      • The system shall
      • The system shall
      • The system shall
    • Focus on the user and interactions!
  • Stories aren’t use cases
    • Use case is generally larger scope
    • Stories differ in level of completeness.
      • A use case has the tests before it’s finished
      • A story delays the acceptance until the last possible moment before implementation saving time.
  • Stories aren’t scenarios
    • Scenario
      • Setting
      • Actors
      • Goals/objectives
      • Actions/events
    • Story
      • A role
      • An objective/goal
      • A value
      • C C C (card conversation complete)
  • Why use?
    • Emphasize verbal communication
    • Comprehensible by everyone
    • Right size for planning
    • Work for IID
    • Encourage deferring detail (less waste)
    • Support opportunistic design
      • Know it when I see it!
    • Participatory design
    • Build tacit knowledge (explicit, tacit, externalize, combine, internalize)
      • Face it, who really reads the requirements? 
  • Developer responsibilities
    • Understand why we choose a technique
    • Understand advantages of other requirements techniques and when to apply them.
      • Use case
      • Diagrams
      • Uml models
      • Domain models
  • Catalog of story smells
    • Too small
      • Need to revise estimates
    • Interdependent
      • Hard to plan because of dependencies
    • Goldplating
      • Adding unplanned features or interpreting stories
    • Too many details
      • Too much time spent on gathering befor eimplementing Something!
    • Including UI too soon
      • Details about specific ui things (dropdowns, tabs)
    • Thinking too far ahead
      • Hard to fit on cards
    • Splitting too many stories during planning to ‘fit’
    • Trouble prioritizing
      • Missing biz value?
      • Too big?
      • A little of this and of that?
    • Customer won’t write/prioritize
      • Let them off the hook somehow
  • Using stories with Scrum
    • 30 day iteration
    • Scrum team
      • 4-7
      • Cross functional (dev, test, business, other)
    • Product Backlog (uncommitted)
      • List of stories prioritized and estimated
    • Sprint planning
      • Select top priority subset and COMMIT
    • Sprint Review
      • Show off the completed functionality
      • Define DONE first
      • Review completed stories for completeness
      • Review uncompleted stories to verify they’re NOT in the demo
    • Daily Scrum (standup)
      • What did you do since last scrum?
      • What are you working on after this scrum?
      • What’s in your way?
  • Additional topics
    • Paper or software?
    • Stories and interface?
      • If important make a UI constraint
      • Write two 
    • Retaining stories
    • Stories for bugs
    • Colored cards?