The Importance of User Story Communication

1
The Importance of User Story Communication

• Agile Development Conference Feb 2008
• David Sammut

2
MediaCatalyst

• Amsterdam (HQ)
• New York
• Los Angeles
• Malta

3
User Story

• Definition
• One thing the customer wants the system to do

4
The Team

• Multi-site organization
• Malta -Technical
• Amsterdam -Business Analysis, Information
  Architecture
• Stockholm Framework Team, Stakeholders

5

• Communication

6
The Experience

• Long/complex user stories
• Incorrect use of Terminology
• Business rules embedded in user stories
• Redundant/overlapping user stories

7
Addressing the Issues

• Issue Long/complex user stories
• As a user I want to access the overview page and
  select a phone so that I am presented with a list
  of subjects, topics and user guides organized by
  category.
• Mitigation Keep user stories short
• "As a type of user I want to perform some
  task so that I can achieve some goal
• Too much detail can lead to decay
• Separating what's really valuable from what's
  just merely interesting
• Easier to plan, prioritize, scoping
• Smaller stories imply we know what we are going
  to build, there's less unknown, less risk of
  'hidden' functionality not present during
  estimating
• Gain focus by breaking-down user stories

8
Breakdown

• Theme
• Product Selector
• Epic
• Phone
• Accessory
• PC Card
• User Story
• As a user I want to select from a list of phones
  so that I can see phone specific information
• Task
• Create business logic
• Create entity bean
• Create front-end template

9
Addressing the Issues

• Issue Incorrect use of Terminology
• As a user I select a song from a list so that I
  can play it
• As a user I select a track from an RSS feed so
  that I can view track info
• As a registered user I select a media item from a
  list so that I can cast a vote
• Mitigation Discipline/Commitment to establish a
  common vocabulary
• Acceptance test cases help identify incorrect use
  of terms
• Establish a noun-list
• Create a domain model based on noun-list and
  conversations with domain experts

10
Domain Diagram
11
Addressing the Issues

• Issues Business rules embedded in user stories
• As a user I can select from a list of
  accessories if the selected mobile phone
  supports accessories, so that I can view the
  accessory details
• Mitigation Keep business rules out of the user
  story
• Acceptance test cases aid in defining the user
  story specifications
• Create a business rule matrix
• Create a list of business rules that can be
  referenced - Re-use of common business rules
  coupled with Information Architecture

12
Business Rule Matrix
13
Addressing the Issues

• Issue Redundant/overlapping user stories
• As a registered user I want to log in, so I can
  access subscriber content
• As a user I want to enter my user name and
  password, so I can access a page containing
  private information
• Mitigation Analysis of user stories through the
  application of acceptance test cases
• Acceptance test cases take the user stories for
  a ride prior to entering the development phase
• Less expensive to correct user story at
  acceptance test case phase rather than during
  development

14
Multi-site Development

• Challenges
• No face-to-face communication
• Issues not resolved as they are discovered
• Incorrect assumptions
• Location of documentation repository
• Sharing of documents
• Domain insight not shared

15
Multi-site Development

• Practices
• Daily conference calls
• Use of issue tracking application
• Use of IM with accurate status
• Ambassadors
• Seeding and maturing visits
• Desktop sharing applications
• Document sharing applications

16
At its Core

• Commitment to good communication
• Collective ownership
• Knowing where to find information
• Understanding expectations
• Transparency

17

• Thank you for your attention