Your SlideShare is downloading. ×
User Stories
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

User Stories

1,814
views

Published on


0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,814
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Stories should instead be written so that the benefits to the customers or the user are apparent.
  • Transcript

    • 1. User Stories For Agile Software Development CHET RATHOD MBA, CSM
    • 2. Content
      • Two Sections:
      • User Stories
      • Frequently Discussed Topics
    • 3. 1. User Stories
    • 4. Overview
      • A story captured on a card or sticky contains a short description of the user- or customer- valued functionality.
      • A story should initiate conversations between the customer and developers about the story.
      • The user stories emphasizes verbal communication and encourages deferring of details.
      • The stories are prioritized based on their value to the organization.
      • The acceptance tests validate that a story has been developed with the functionality the customer team had expected.
      • The customer team should include testers, product managers, real users, and interaction designers.
    • 5. Writing Stories
      • A good story is:
        • I ndependent
          • Avoid introducing dependencies between stories, so that stories can be developed in any order.
        • N egotiable
          • Not a written contract but a negotiation between the user and the developers.
        • V aluable to users or customers
          • Avoid stories that are only valued by developers.
        • E stimatable
          • If story is not estimatable, increase domain knowledge.
          • Gain knowledge by creating two stories; a quick spike to gather information and then a story do the real work
        • S mall
          • Split stories or combine stories
        • T estable
          • Capture completion (done) criteria.
          • Especially non-functional requirements.
    • 6. User Role Modeling
      • User Roles
        • Typically stories are written keeping one user type in mind. Re-evaluate this.
      • Role Modeling Steps
        • Brainstorm an initial set of user roles
        • Organize the initial set
        • Consolidate roles
        • Refine the roles
      • Additional techniques
        • Defining Personas – imaginary representation
        • Defining Extreme Characters – for otherwise missed stories.
    • 7. Gathering Stories
      • Assumption : There are different sizes of requirements, requirements do change overtime
      • Techniques
        • User interviews
          • A lot more than asking, “what do you need?”
        • Questionnaires
          • Effective technique for gathering information from large user base
        • Observation
          • Effective way to pick up on insights
        • Story-Writing workshops
          • Definition of low-fidelity prototype
        • Recommended a combination of the above methods
    • 8. User Proxies
      • Understand their backgrounds and motives
        • User’s Manager – might have different role compared to user
        • Development Manager – different corporate goals
        • Salespersons – focuses on anything that makes a sale
        • Domain Experts – might develop too complex system
        • Marketing group – has focus on quantity of features and not on quality
        • Trainers and Support - will avoid advanced features
        • Analysts – intuits what users want, extended time on project upfront activities.
      • Ways to work with User proxies
        • Start a user task force, guidelines provided by users and day to day decisions made by proxies. Identify a ‘champion’.
        • Combination of user proxies
        • Release beta version as early as possible to engage users
        • Avoid making developers as user proxies
    • 9. Acceptance Testing
      • Tests are written at these times:
        • When developers and customers capture explicit details
        • Start of an iteration or before programming begins
        • Whenever new tests are discovered during or after development of the story
      • Customer specifies the tests
      • Viewing testing as part of the development process, not something that happens “after coding is done.”
      • Write tests as long as they add value and clarification to the story.
    • 10. Acceptance Testing cont’d…
      • Framework for Integrated Test
        • Customer team should be the one to execute the acceptance tests
        • Minimally executed at the end of each iteration
        • Look into automating some or all of the acceptance tests
        • FitNesse – extension of FIT, a popular approach for writing acceptance tests on Agile projects. (fit.c2.com, fitnesse.org)
      • Types of Testing
        • Customer and development team should work together to determine the different types of testing.
    • 11. Guidelines For Writing Good Stories
      • Be aware of the Purpose
        • To act as a reminder to discuss the feature, not to replace the conversation by adding more detail to the story card
      • Start with Goal Stories
        • Based on user roles
      • Splitting stories (slicing a cake)
        • Provides some level of end-to-end functionality.
      • Write Closed Stories
        • That finishes with the achievement of a meaningful goal
      • Put Constraints on Cards
      • Size the Story to the Horizon
        • Writing stories based on the implementation horizon
      • Keep the User Interface out as long as possible
    • 12. Guidelines For Writing Good Stories cont’d…
      • Some things aren’t stories
        • Guidelines are expressed in different format
      • Include User Roles in the stories
      • Avoid interpretation confusion, increase clarity by using active voice.
      • Customer writes the stories.
        • Developers should help out.
      • Don’t number story cards
        • Use short titles.
    • 13. 2. Frequently Discussed Topics
    • 14. Why User Stories?
      • Verbal Communication
        • Solves interpretation gaps, what was written down vs. what was expected.
        • Rapid feedback cycles, leading to greater understanding.
      • Comprehensible
        • Since they are terse, discussed, and easily remembered.
      • Right size for Planning
        • Ease of prioritizing
      • Iterative Development
        • Varying progressive level of detail instead of completism .
      • Deferring Details
      • Opportunistic Development
        • Allows a team to shift between high- and low-levels of thinking
      • Participatory Design
        • Encourages users to become participants in the design
      • Build up of knowledge
        • Stories promote the accumulation of tacit knowledge across the team
    • 15. Why User Stories? Cont’d…
      • Challenges with Stories
        • In a very large project, it is difficult to understand the hierarchies and relationships between stories.
          • Keeping stories at a higher level till the team is ready to work on it
        • Requirements traceability is mandated
          • Create a document at the start of the iteration to capture the stories and corresponding test cases.
        • Sharing of tacit knowledge in large teams
          • Some communication on large teams must be written down.
    • 16. Story Smells Smell Symptom Impact Action Interdependent stories Particular story is added to an iteration if another story is also added. Difficulty planning iterations Try to combine or evaluate the separating criteria Goldplating Developers are adding features or interpreting stories liberally
      • - Developers always looking for “wow” factor.
      • A false sense of accomplishment
      • need to put their own mark
      Greater visibility of tasks, discuss it in retrospectives.
    • 17. Story Smells cont’d… Smell Symptom Impact Action Too Many Details
      • Too much time spent in gathering details in advance
      • Too much time spent in writing about stories than talking about them
      Emphasizes on documentation over conversation - Encourage story writers to be very conscious, include fewer details Thinking Too Far Ahead
      • Stories are hard to fit on note cards
      • Proposes a template to capture all of the details
      • Finer estimates are expected
      Large upfront “requirements engineering” efforts. - Refresher course on the strengths of stories Frequently Splitting Too Many Stories - Trying to fit right amount of work in an iteration - Tendency to fill up 100% of the team’s capacity. - Look for stories that make sense to be split.
    • 18. Story Smells cont’d… Smell Symptom Impact Action Customer Has Trouble Prioritizing Customer wants bits and pieces of the stories to be delivered. Delivered stories are not completely valuable.
      • Split stories
      • Clearly express business values
      • Request customer to write stories
      Customer Won’t Write And Prioritize Stories
      • Customer will not accept the responsibility
      Difficult to develop “ we’re all in this together” attitude.
      • Find a way to let the customer off the hook
      • Create an environment for the customers to express their opinions
      • takes full responsibility.
    • 19. Additional Topics
      • Handling Non-functional requirements
        • Additional nonfunctional requirements can be captured in any appropriate form.
      • Paper or Software?
        • Paper – imprecise, limited details, easy to sort
        • Software – tendency to be precise, allows to capture test cases, distributed team, certification that requires traceability
        • Recommended to start with paper and then switch to software if compelled.
      • User Interface
        • Iterative process can lead to iterative changes in the UI
        • Consider adding some practices from Agile Usage-Centered Design to avoid iterating the user interface.
      • Retaining Stories
        • Err on the safe side and retain the stories
      • Stories for Bugs
        • Each bug report its own story, or combine bugs into one story.