Agile development focuses on delivering working software frequently through short iterations. However, ensuring user needs are met can be challenging in Agile. Phase 0 involves upfront user research, concept development, and validation before sprint planning to provide high-level direction. User stories represent functionality providing user value but must avoid becoming technical requirements. UX designers collaborate closely with developers, designing for each story and testing implementations with users. Maintaining a coherent experience across sprints requires ongoing UX work like user interviews and UI documentation. The UX role is to integrate user-centered practices into each Agile activity and keep the customer experience a top team priority.

1. Adopting Agile:
Successful UX in an Agile World
Hugh R. Beyer
CTO
InContext Design
Concord, Massachusetts, USA
hugh.beyer@incontextdesign.com
Hugh Beyer, CTO 978.823.0100 www.incontextdesign.com
beyer@incontextdesign.com www.innovationincool.com
Twitter: @hughrbeyer

2. UX and Agile: The promise
Agile says development in steps – and iterate
UX says work with users to create value – and iterate
The “ideal” product
User Test
What users really
need

3. What is Agile development?
Agile principles
 Satisfy the customer with early and continuous delivery of value
 Welcome changing requirements
 Deliver working software frequently
 Communicate through face-to-face conversation, not heavy
documentation
 Reflect on process regularly
Agile in practice
 Goal is to deliver working software quickly
 Short iterations permit management visibility into team progress
 Up-front planning is minimized or nonexistent
 Any work that doesn’t involve coding is downplayed

4. Core Agile processes
Processes Development Practices
 Short sprints  Co-located teams
 Plan each sprint at the start  No code ownership
 Plans based on story cards  Test-driven design
 Each sprint delivers useful  Continuous build
value  Pair programming
 Daily standup meetings
 Validation of sprint and
re-evaluation of direction at
end of sprint
 Reflection on process at the
end of sprint

5. Phase 0

6. Driving Phase 0
Issue: Getting trustworthy user insight
 Customers, stakeholders, surrogates, product owners are not users
• They can’t tell you what users need
 Even users can’t tell you what users need
 Even with a demo, users can’t tell you what they need or what to change
 Users are hard to get to and rarely can be put on the team
 User-centered techniques to find out how users work, invent appropriate
solutions, validate and iterate those solutions
 UX people on the team
Issue: figuring out what’s useful
 The frame for a design comes from somewhere
 Significant new functionality needs “think time”
 The release planning session is not the right place for design
 Even the customer/user doesn’t know what the right thing is
 Even a concept needs to be tested

7. Key skill: Driving Phase 0
Phase 0 brings it together
 User research, visioning, conceptual design with iteration
Phase 0
Build Iterate
concept with Iterate SW
understanding with users
with users users
User Research Concept Iteration Agile Development

8. Example schedule of CD Agile Phase 0
User-centered Agile
Week 1 – Gather data from 8-10 users  Compressed into a short
Sprint
Phase 0
• For constrained project
Week 2 – Consolidate data
focus only!
Week 3 – Vision and storyboard
Phase 0 sprints
Sprint
using Scrum as a
process framework
Week 4 – UED and UI
Week 5 – Release planning & validation
(2-4 users)
Sprint
Week 6 – Validation & redesign
Sprint
Development Sprint 1

9. User Stories

10. User stories
Why user stories
 Convenient structuring technique for development
 Small stories enable short iterations
 ―User value‖ as opposed to features – fights feature creep
What they are
 Short descriptions of functionality
 Each provides user value
 Rated by business value
 Business value incorporates user value from Phase 0
But…
 Chopping the design into small stories makes it easy to lose coherence

11. Writing user stories
Each story captures one element of user value
 Written to describe what is done for the user by the system
 Collects features that aren’t useful on their own into one story
 Splits features that can be partially or more simply implemented
• Build up complex functionality over several stories
• Break large stories – ―epics‖ – into smaller stories
A guide for story format
 As a <role or persona> I want to <do something supported by the
system> so that I <achieve something of value>
 ―So that‖ clause may not be needed if working from a design
Engineering tasks are not user stories
 Keep the focus on value to the user

12. Examples of good user stories
Good
 As a traveler, I want to see all the trips I have scheduled so I can orient to
the upcoming weeks
• No indication of UI at this point
 As a traveler, I want to see key flight information at a glance so I can
glance at it while in a hurry
• Including what? Airline, flight number, departure time? Gate? Details may not be
captured in the story.
 As a traveler, I want to see if the flight is delayed and the current
departure time so I can tell if I’m going to miss a connection
• Implies lots of back-end work, so it’s split into its own story
 As an admin or spouse I want to see the traveler’s itinerary so I can
coordinate with them
• Stories can support different user types

13. Common errors in user stories
Bad
 As a traveler, I want to see upcoming trips so I can know my upcoming
trips
• Rewritten functional requirement – do you understand the user need?
 As a traveler, I want a list of all the events in my trip with an icon showing
what the event is, the title of the event, its location, and key information
specific to the event
• Writing the design into the story
 As the system, I want to collect flight information from airlines so I can
present it to the user
• Technical requirement masquerading as a user story
 As a traveler, I want the app to be highly usable so I don’t waste my time
• Non-functional requirement with no tangible deliverable

14. Fitting stories into sprints
Traditional division by layer
UI Step 3
Presentation
layer Step 2
DB access
layer Step 1

15. Fitting stories into sprints
Completed UI
Story 1 (TripIt)
Chicago, IL
UI
As a traveler Wed, Sep 7
I can see the 7:45am London to Chicago
main events 11:00am The Drake Hotel
of my Presentation Thu, Sep 8
itinerary to
8:30am Meeting
give an
overview of
the trip
DB access
Sprint1: Minimal
UI, get data to the
screen

16. Fitting stories into sprints
Completed UI
Story 2 (TripIt)
Chicago, IL
UI
As a traveler Wed, Sep 7
the main 7:45am London to Chicago
(air, AA 99)
events of my 11:00am Directions to the
Drake Hotel
itinerary are Presentation 11:00am The Drake Hotel
shown in a
Thu, Sep 8
collapsible
view so I can 8:30am Meeting
focus on the
part of the DB access
trip that
matters
Story 1: Minimal Story 2: UI structures
UI, get data to the information, provides
screen more info

17. Fitting stories into sprints
Completed UI
Story 3 (TripIt)
UI
As a traveler
the main
events of my
itinerary are Presentation
shown with
icons and
key
information
so I get DB access
quick details
Story 1: Minimal UI, Story 2: UI structures Story 3: Fully
get data to the information, provides rendered UI, full
screen more info data access

18. Fitting into a sprint

19. Integrating UX and development
Work out the interface for a story before development starts
 Detailed UI design
 Final iteration with users
Work with development during the iteration
 Communicate design to developer
 Consult on detailed behavior
Test implementation with users in the following iteration
Sprint 1 Sprint 2 Sprint 3 Sprint 4
UX team UX team UX team
designs designs designs
story 1 story 2 story 3
UX team UX team UX team
consults consults consults
on story 1 on story 2 on story 3
UX team UX team
tests tests
story 1 story 2
Dev team Dev team Dev team
builds builds builds
story 1 story 2 story 3

20. Kanban view of work-in-progress
Work Step 1 Buffer Work Step 2 Buffer
Max size = n Max size = m
 Buffers mediate between work steps
 Buffers control flow—maximum size limits work in progress

21. Kanban view of 1-ahead/1behind
Sprint n-1 Sprint n Sprint n+1
UX Design Development Test
Limit = velocity
In progress In progress In progress
Buffer
(Release Development
Test Buffer
backlog) Buffer
• Release backlog acts • Stories ready to start • No need to
as initial buffer development wait for next
• Stories defined but • Number must be = velocity by sprint to start
not in progress = start of sprint testing
waste • UX works 1 ahead to fill buffer

22. In-sprint user feedback
User-centered techniques within the sprint
 Targeted interviews to understand specific tasks
 Paper prototypes to work out designs and alternatives
• Use rough prototypes in situ to explore options and define low-level
requirements
 Online prototypes and skeleton code to test user interaction
• Remote testing with screen sharing can be used
• Test details of appearance, layout, and behavior
 User tests of running builds
All supporting
 Fast iteration of design before coding starts
 Quick check of design as implemented
 Close collaboration between UX designers and developers

23. Maintain a coherent UI

24. Maintain a coherent UI
Engineering breaks everything into parts
 Short timeframe of a sprint
 Small functionality of a story
Design has to keep things coherent
 One large view of the user experience
 UI and behavior consistency across the interface
 Tasks supported coherently, end-to-end
UX activities maintain coherence
 Start with a real Phase 0
 User interviews focused on work practice
 UI track to look across sprints and teams
 UI representations to show the coherence
• User Environment Design from Contextual Design
• Site maps from web development

25. Maintain a coherent UI
Phase 0 for Release
Sprint Sprint Sprint
component planning
Scope
Strategic design: Initial development
user effort; Phase 0 for Release
Sprint Sprint Sprint
research, ideation, conc plan parallel component planning
ept testing streams;
define roadmap
Interaction
Architecture Ongoing UX stream for cross-system coherence
planning
Strategic design phase to define roadmap
Parallel development streams for each component
 Each stream starts with a Phase 0 for that component
Parallel UX stream to maintain system coherence

26. Be a team member

27. UX as a team member
You are a part of the team
 Your problems are the team’s problems
• Borrow and co-opt people
 The team’s problems are your problems
• Support team priorities. Be there at team meetings.
 Your tasks are the team’s tasks
• Track them as team tasks

28. The UX roles on an Agile project
Agile activity UX role
User research: field interviews
Phase 0: Set
direction & project Concepting: high-level design
goals Validation: prototyping
Prioritization: customer value for release
Release planning
User story generation
Prioritization: customer value for the sprint
Sprint planning
UX task generation and estimation
UI design and detailed behavior for each user story
Sprint Prototyping with users for detailed behavior and look
implementation
Validation testing of completed code

29. Put the customer at the center
of Agile
Karen Holtzblatt, CEO Hugh Beyer, CTO
karen@incontextdesign.com hugh.beyer@incontextdesign.com