In this tutorial for experienced practitioners you will learn how to manage work and make great experiences one sprint at a time. We'll look at common Agile methodologies such as Scrum and Kanban and what opportunities and risks are inherent for UX teams. We will look at team makeup, balancing longer-term research with production needs and strategies for making the most of design spikes. We'll also go through the pros and cons of a Sprint Zero and alternatives. We'll look at how Lean Startup practices are changing business development, and how your UX skills can be a key part in making that successful. Participants will come away with the tools they need to be successful in their Agile/Lean environment
4. Agile is
• Small teams
• Making small pieces of work - “shippable increments”
• Effective communication
• Ideally co-located
Original Via Spotify (original presentation not available).
More at: http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14 and https://labs.spotify.com/
5. Photo by Federico Bierti - https://www.flickr.com/photos/53318225@N00/
We all need to be in the same boat…
Test
Developers
Product Owner
Sales
Service Engineering
Globalization
User Experience
Content
Operations
Marketing
8. Agile History
• February 2001: The Agile Manifesto written
at Snowbird Ski Resort in Utah
• Authors:14 male software engineers
• Agile, as originally conceived, understood nothing
of UCD or UX processes
9. Agile Manifesto
We have come to value the items in the dark boxes more.
Full version: http://agilemanifesto.org/
Individuals and Interactions Customer Collaboration
over processes and tools over contract negotiation
Working Software Responding to Change
over comprehensive documentation over following a plan
10. Individuals and Interactions
• Individuals and interactions over processes and tools
• Communication
• Working together
• Creating opportunities to learn and share
• Not doing activities just to check a box
• Not allowing tools to get in the way
• Finding faster/better ways to work
12. Working Software
• Working software over comprehensive
documentation
• Working software is the measure of work
• Documentation doesn’t improve a system
• Complex systems
• Documentation is sometimes necessary to make “self
serve”
• System should be clear and well designed
13. Customer Collaboration
• Customer collaboration over contract negotiation
• Software was built for a client (not broad sets of users)
• We interpret as Users
14. Responding to Change
• Responding to change over following a plan
• Planning is short-term and flexible
• Change is a constant – embrace it and prepare
• When things change, so does the plan
15. Benefits of being Incremental
• When development runs out of time/resources,
the shipped solution
• Delivers maximum value
• Has a complete design without holes
• Has much higher quality
• Has no wasted design work
18. Scaling Agile at Spotify via Slideshare of Vlad Mysla
http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
Squads, Tribes, Chapters and Guilds
19. Scrum
• Daily Ceremonies - Standup
• 15 minute standing meeting
• What you did, what you are doing, blockers
• Sprints
• 2 – 4 weeks of work
• Culminate in a potentially shippable product increment
22. Kanban
• Finite number of “tickets”
• Cannot put more work in until previous work is done
• Team members pull work as work is completed
• Time-boxing is optional
• All work is a collaboration
• Information radiators
28. Estimating Stories
• T-shirts, Fibonacci, days work, etc.
• Minimal effort to guess
• If cannot guess, further define story
29. UX Activity Estimation
• Should UX activities be estimated towards team
velocity?
• A hotly debated topic
• No. They UX stories should be tracked separately, in parallel
• Yes. UX stories should be tracked with other work,
especially when part of active work
• “Working software is the primary measure of
progress”
30. Velocity
• Measure amount of work done
• Determine our velocity or “burn down”
• Estimates and velocity tell us what we can get done
• Longer term, squads can improve velocity
31.
32. Parking Lot
• Used to get to a firm estimate and clarify questions
• Able to respond Go/No Go
• Problems that can be solved in a single conversation
33. Design Spikes
• Used to get to a firm estimate when not enough
information to determine in a parking lot
• Intense focus on issue with multiple resources
• Done by a few while other work continues
• Multiple resources (not just design)
• Must continue to support ongoing development
34. User Acceptance Testing
• Customer/client feedback in traditional Agile
• Clients (not users):
• Are shown a demo by team
• Do not touch or interact with system
• Not typically a member of the Agile team
• Are rarely the users of the system being designed
• When feedback is collected in traditional Agile – after
iteration/sprint
35. Demos and Retros
• Demos are “playing back” what was done during the
sprint
• Matches the Epics/Stories from the Sprint
• Celebrate progress
• Retrospective
• Looking at what went well (continue doing)
• What could be improved
• What we should stop doing
37. Customer Feedback – in traditional Agile
• Fails to find most learnability and usability issues
• Misses opportunity to inform future design
• Misses opportunity to gain better user insight with
prototypes, observation, etc.
38. Bring Users into Agile
• UX brings the end-user into Agile and expands the
meaning of “Customer” to extend to the end-user
39. Lean Startup
• Lean is a business development method,
popularized
by Eric Ries.
• It’s like Agile for the business side of things
• Uses the same build – test – learn cycle
for business models and product development
• Only measure of success is market behavior
40. Lean UX
• Agile is the perfect product delivery method for Lean
businesses
• Same adaptations that make UX practices work in
Agile also make them work in Lean
• Lean UX = Agile UX
• Rely on early research and usability testing (learn as you
go)
• Less time to conduct research and think through
problems
• Handled as a spike if needed
41. Eric Ries @ericries via @MelBugai on Twitter at
LeanStartupMI in 2011
"The biggest waste of all
is building something
no one wants“
- Eric Ries @ericries
43. We Come from Different Places
By Jeff Patton as interpreted by Jim Laing – Source: http://www.agileproductdesign.com/blog/user_experience_relevance.html
44. Agile
• Agile is a philosophy, not a specific set of tools
• Principles are not mandates
• UX was not deliberately excluded
• Software development methods
• Scrum, Kanban, XP, etc. meet the criteria for Agile
• “Waterfall” does not
45. Agile Frustrations
Scaling Agile at Spotify via Slideshare of Vlad Mysla
http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
team member
46. Agile UX: The Good
• Most important features are done first
• Working together – not “over the wall”
• Keep up with technology and environmental changes
• Enables iteration of requirements
• Less “design drift” and less wasted design
47. Agile UX: The Good (continued)
• Issues get fixed
• “Done” includes design
• Satisfying to see designs in real use
• Learn from actual product use
• User data has effect on current release
48. So Now What?
• If Agile doesn’t care about UX, why should my Agile
team care about what I do?
49. Getting Developers to Care
• UX Fail strategies:
• “I’m just going to keep doing my job the way I always
have and telling the team what they need to do.”
• “I’m just going to let them go ahead and fail. Then they’ll
come to me begging and let me do my job.”
50. Be Part of the Team
• They’re not going to “stop the train” for you
• Make UX processes Agile
• Build trust by providing value of work
• Attend daily standups/scrums
51. Get Ahead of the Train
• Design one iteration ahead if necessary, so you have
designs ready to go when they are needed
• Regular usability testing (iteration-aligned)
• Test whatever is ready that day
• Plus your look-ahead designs
• Plus user research for existing issues and potential future
work
• Test designs before developers build them – saves
arguments
52. Welcome the Team to your World
• Invite developers to observe tests of features they
wrote
• Seeing someone struggle is strongly motivating to them
• Even more so for product managers
• Engage developers in helping you to figure out
solutions
• Their knowledge of code and systems provides ability to
come up with innovative solutions
• Credit developers when features they wrote work
well (even if you designed it)
53. Bring Your World to Them
• No time or inclination to watch your testing?
• Record the tests
• Bring key clips to the next meeting(s)
• Provide easy access to sessions (always consider ethics)
• Information radiators
• Share info on the walls
• Use online tools
• Get it in the backlog
Photo: https://medium.com/@FBResearch/beyond-bullet-points-
four-creative-ways-to-share-research-c10fa047f025#.cdauyngei
54. Fit into the Process
• Time product testing: results ready when most useful
• Track usability metrics on the team dashboard
• Ensure they are reported upwards
• Help prioritize usability problems to simplify backlog
grooming
• Add preemptive cards to the schedule for “problems
we will find while testing”
55. Design Adapts to Agile
• Falling short of end goals is a constant
• Focus on meeting user’s primary needs
• Constant Improvement is key
• Widen the Design family
• Distribute the work
• Empower entire squad to inform design
• Agile is reactive – no time for predictive work
• Prepare to react
Adapted from Jim Laing’s presentation at UX Pittsburgh, May 2014
56. Participate in Retrospectives
• Encourage retrospectives if they aren’t happening
• Information provided enough/too much?
• Questions still open?
• Still confusing/frustrating?
• More effectively communicate user needs?
Image: http://intland.com/blog/project-management-en/tips-and-tricks-to-make-the-
most-of-your-retrospectives/
58. Let’s Get to Know Each Other
• Who has had agile training?
• Reading, no formal training
• Other team members trained
• No training
• Some training
• How long have you been doing Agile?
59. Who’s Here?
• Roles?
• UX practitioner, UX manager -- is this who we all are?
• Resources?
• Single UX resource on a single Agile team/project
• Single UX resource on 2+ Agile teams/projects
• Part of a UX team on a single Agile team/project
• Part of a UX team on 2+ Agile teams/projects
• Maturity of UX Practice?
60. What’s Your Team Like?
• Distributed/remote?
• Large/small?
• Who else is on the team?
• How long have you been together?
61. Balancing Team Work
• Within UX team
• Research
• Wires/clickable prototypes
• Usability testing preparation
• Usability test facilitation
• UX Issue wrangling
• Visual design
• What else?
• Split team up on different items or attack together
62. Marketing, Sales and Business Analysts
• Have customer access
• Knowledge
• Business rules
• Usage patterns, what other tools customer has
• Can support
• Research (users/stakeholders)
• Wires
• Demos/Clickable prototypes
63. Developers and UX
• Trust is key
• FED (front end developers) and UI Developers
• Can provide
• Clickable prototypes
• Coded “prototypes”
66. Scaling Agile at Spotify via Slideshare of Vlad Mysla
http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-4383-9673-9e715ff47a75&v=default&b=&from_search=14
Squads, Tribes, Chapters and Guilds
68. Agile Design Timing: Parallel Tracks
• Developer track: Focus is on production code
• Interaction designers track: Focus is on user contact
69. Iteration 1: Developer Track
• Underlying architecture work
• Critical features with little user interface design
required
70. Iteration 1: Interaction Designers
• Design, create prototypes, usability test (UTest),
and iterate (RITE method)
• Field studies to understand user needs (contextual
inquiry)
72. Iteration 2: Interaction Designers
• UTest completed code for integration and implementation issues
73. Iteration 2: Interaction Designers
• UTest completed code for integration and implementation issues
• Use data gathered in the last iteration to create designs for next
iteration
74. Iteration 2: Interaction Designers
• UTest completed code for integration and implementation issues
• Use data gathered in the last iteration to create designs for next
iteration
• Field studies for detailed information needed for upcoming iterations
75. And so on…
• Constant communication between the two tracks is essential for
success
• These are not just hand-offs
76. We repeat:
• Constant communication between the two tracks
is essential for success
• These are not just hand-offs
• This is the most misunderstood thing about
staggered sprints.
81. Agile Roles and Parallel Tracks
• UX Takes Time
• Having multiple roles (e.g. UX + product owner,
UX + scrum master) leads to overload
• Working on multiple teams is a bad idea
84. Story Myths
• Story = feature
• Story = specification
• Story must fit in one iteration
• Stories are time limited
• All stories have firm estimates and specs in Iteration
Zero (or even Iteration One)
• These are NOT true.
85. Story Examples
Advantages of the “As a user, I want” user story
template. By Mike Cohn
http://www.mountaingoatsoftware.com/blog/adv
antages-of-the-as-a-user-i-want-user-story-
template
86. To make a story INVEST
• A good story is:
• Independent
• Negotiable
• Valuable to users or customers
• Estimate-able
• Small
• Testable
User Stories Applied for Agile Software Development, By Mike Cohn
87. What if your story is too big?
• If work can’t be completed in one iteration
• Where are the break lines?
• How do you prioritize the feature cards?
88. Big Design - Waterfall
• Everyone signs off before Dev begins
• One big design document contains everything
• Dev builds it until they run out of time
• QA doesn’t test until Dev has run out of time
• Result
• Whatever is built first is completed
• Details are left out, quality issues identified too late
• Holes are left in the design
• Much of your design effort is wasted
89. Big Design - Agile
• Deliver incremental value quickly
• Break the story into small pieces
• What is the smallest piece that can be built?
• Delivers value to the user
• Incremental
• Something to learn from
• Minimum Viable/Valuable Product (MVP) – from Lean
Startup
90. Big Design – Agile (continued)
• Schedule the pieces in order of importance
• Design incrementally, as if the each piece were the
final one
• Change your future plans between iterations if you
have learned new things
91. Original via Spotify (original presentation not available). More at: http://www.slideshare.net/vmysla/scrum-at-spotify?qid=2345c3ad-7e68-
4383-9673-9e715ff47a75&v=default&b=&from_search=14 and https://labs.spotify.com/
92. Story Card Progress
• Is UX Needed?
• What is the story?
• What do we know?
• What do we need to know?
• Conduct Lean UX to answer outstanding questions
• Interviews, observations, prototype testing, etc.
• Work with Dev to respond to questions as needed
92
Kanban
Do Review Done
93. Benefits of being incremental
• When development runs out of time/resources, the
shipped solution
• Delivers maximum value
• Has a complete design without holes
• Has much higher quality
• Has no wasted design work
94. Mistakes to avoid
• Designing all the detail up front
• Not thinking about the full experience up front
• Not breaking things down far enough
• Not delivering a complete (sub) story each iteration
– “now the user can…”
95. Incremental Example: Doorway
• User story: The user can get in and out of her house
easily.
• Completion Criteria:
- Secure
- Insulated
- Lets light in
- Allows large furniture items to pass
- Fits with house décor
- Works even without keys
96. Incremental Example: Doorway
• Initial Rough Design:
- Beautiful Colonial Door
- Unbreakable translucent window
- Programmable digital lock
- Steel deadbolt
- Metal-clad on the outside
- High R-Value
97. Incremental Example: Doorway
• What is the minimum work that will give the user
incremental value towards their goal?
• What needs to be designed for that?
• What is the next smallest item that will give the user
an added capability?
• What needs to be designed for that?
99. Activity: Early Story Selection
• Select the first 10 stories that should be done.
• How many do you have to complete before you
would be willing to try it with real customers?
• See handout
101. Fitting This to Your Process
• The purpose of incremental implementation is to get
feedback early and often
• After each iteration, gather feedback
• Questions that can affect your breakdown:
• Who evaluates your product?
• Is it always the same people?
• Are your target users internal or external?
102. Gather feedback from
• Internal ‘expert users’
• Beta/Usability testers under NDA
• The general public (after release or open beta)
• Internal users in a protected ‘sandbox’
• Internal users after general deployment
103. Before releasing, consider
• Are you getting the feedback you need?
• Is there enough completed for an external
user to evaluate?
• Sometimes you may want to hold back certain work
until more is done.
104. Make it Easier for the Team
• Write staged specifications
• Best guess at breaking the design into 1-iteration Story
increments
• “Break” the Stories with developers into Tasks
• Remember: they own the Tasks
• You need to know how to map those back to Stories &
Capabilities (See story mapping)
105. Ways to Break a Story Down
• Workflows
• Stories with many “mini-workflows”
• e.g., Channel changer
• Allowed inputs
• Story that applies across different data types
• e.g., Image file reader
• Capacity
• Completion criteria involve extreme size or speed
• e.g., File transfer of large files
113. Activity: Story Breakdown
• Chandra needs all the application functions available
to him in his native language or another language he
understands well.
• Which of these breakdowns is/are Agile? Why?
• What factors would determine which breakdown you
should choose?
• See handout
114. What if no breakdown is possible?
• You can have a story with one single capability that
takes more than a sprint to build.
• For example, a calculation with a difficult algorithm.
• This is an engineering problem, not a UX problem.
• If possible, see if the work-in-progress can be
validated using partial results.
121. User Story Mapping
• Organizing user stories
into a map that
communicates experience
Book: User Story Mapping, Discover the
whole story, build the right product. By Jeff
Patton (with Peter Economy)
122. Visible Depiction of Available User Stories
• Frame questions such as
• What is needed?
• When is it needed?
• Where is there value?
• What is really important?
124. Represents Complexity and Size of Work
time
Refine the map and test for
completeness with the entire
team - developers, designers,
BA’s etc.
125. Conversations to Understand
• Relationships between stories
• Structure and hierarchy of related stories
• Functionality that is being built
• Conversations to share knowledge and clarify
assumptions
126. Clarity of What is to be Built
• Organizes stories
• Context of use for product
• Clear understanding of use makes prioritization
easier
• Backlog completeness can be verified
• Can be overwhelming to see entire product
• Important to know information now rather than later
127. Enables Better Releases
• Select relevant, high priority stories in releases
• Valuable functionality
• Complete sets of functionality
• Plan, at a high level
• What would come next
• What is for “later”
134. Prioritizing Problems
• It’s better to fix the few most important issues than
to find every issue because:
• Big problems can mask other problems
• Every fix changes user behavior
138. “If a user can’t find or use feature, it’s the same
as if the feature is broken.”
VS.
“It’s more important to fix things that really
don’t work. The user can learn the hard stuff.”
Prioritizing UX vs “real” bugs
139. Prioritizing UX vs “real” bugs
• You cannot win this argument on a case-by-case
basis
• Instead, adopt a strategy for getting required
investment in UX work
140. Strategies for Getting Investment in UX
• Political strategy: Create a formal equivalence of UX
versus bug priorities.
• Investment strategy 1: Block out fixed time
• Investment strategy 2: Block out people
• End-run strategy: get your own engineer
• Fix UX problems early, if possible.
141. Detail Matters
• Users are usually more delighted by low-cost
annoyance fixes than by big flashy new features
142. Focus and Negotiation
• Keep an intense focus on fixing the most important
things
• Negotiate on behalf of users
• Represent their needs as best you can
145. Research Balancing Act
Understand users, context, etc.
Create personas, mental models, etc.
Prepare for story mapping
and other sessions thoroughly
Strive for
UX Best
Practices
Engineers need designs
to develop - will move on without
UX involvement
Research cannot continue
forever
Meet
Production
Needs
Agile requires leaner methods
146. How much is good enough?
• What is being developed?
• What do you know?
• What questions are still open?
• Meet goal when users starting to talk about colors
and icons (not functionality)
147. Light Design - Lean UX
• Familiar UX methods made lean:
• Iterative (flexible, change as needed)
• Repeatable (easy to do, expected next steps)
• Incremental (lead into next, small changes over time)
148. Tips for Lean
• Usability Testing
• Insert questions to find out more for open issues
• Schedule regular testing to reduce preparation time
• Reach users quickly for meaningful information
(panels, remote testing, surveys etc.)
• Incentives as needed
• Put all data together quickly – no big reports
150. Don’t Overwhelm Audience or You
• Document in Wiki or similar (avoid PPT)
• Just enough to understand the “why”
• Always challenging due to:
• Limited time
• Multiple changes over time
• Findings building upon one another
150
151. Provide Details as Appropriate
• Archive prototypes and other deliverables
• Regulatory environment or complex interactions
• Test plans and guides
• Detailed changes
• Participant information as needed, but avoid sharing with
wider team
151
152. Capture the Evolution
• Helps avoid making same mistakes later
• Helpful to capture first, middle and end screenshots:
• primary pages
• primary features
• contentious issues
• Don’t sweat the small stuff
• Use final prototypes as a base for recommendations
(vs. written documentation and/or comps)
152
153. Separation affects documentation needs
• When team is not co-located, does not share time
zones and/or does not share language
• Use additional documentation to communicate and
coordinate
• Use Agile tools (GitHub, JIRA/Confluence) and UX tools
(Mural.ly, etc.) to share understanding
• Use communication tools as frequently as possible
(Skype, online meetings, etc.)
153
154. Lean Reporting
• Put all data together quickly
• No big reports
• Information as needed
• Get it to the team – quickly (Evernote, Mural.ly, Trello,
Story/Bug tracker, etc.)
• Tell the story – pertinent information – who, why?
• Provide solutions (wireframes, etc.)
155. Tell the Story
• Strive for “Caterpillar to Butterfly”
• Show progressions of key sections of the interactions
• Use more screenshots – fewer words
• Explain what changes were made and why
155
157. Activity: Determine User Expectations
• Early stages of a project - defining scope.
• Stakeholders: “Users will never sign a catering
contract on their phone!” Doesn’t need to work on
the phone.
• UX team: Not likely to be their primary access
choice, but will be desired to be done on their phone.
• You have 2 days: Determine if common/critical use case
• Teams of 3 people
• Make a plan for what to do (10 minutes)
• Share your plan
158. Guidelines
• What do you need to know?
• What resources do you have?
• How much effort/time do you have?
159. Activity: Part 2
• Take roles and act them out
• Discuss ramifications of findings
• What's in and what's out?
• Make tradeoffs – conversations
• Vote within teams
• See handout
161. Sprint Zero for Scrum Teams
• Time to do initial research, setup usability testing,
etc.
• When technical teams are setting up environments
• Back end that doesn’t hit front end
• Getting alignment on business goals – WHY??
• All bought in across board
• Do just enough work to get development started
162. Alternatives to Sprint Zero
• Can be in parallel sprints while other teams are
wrapping up previous work
• Do work in Sprint 1
• Planning, story mapping, etc. (or already done)
• Story creation (or not done yet, or will do later)
• Create initial wires and prototypes (or in Sprint 1)
• Goal is to have initial questions answered
– doesn't matter what you call it
163. Pros and Cons - Sprint Zero
• Pros
• Gives UX a head start
• Lot of backend work needs to be done anyway
• Establish common vision
• Who for?
• Common “elevator statement”
• Cons
• Can be a trap leading to Waterfall
• Big Design Up Front (BDUF)
• Time box and Focus on Outcomes to avoid this
164. Requirements
• Change in presence of the artifact
• Questions change as you learn more
• Pointless to do ALL requirements gathering up front
• Works better iteratively – unless in hands of those
that will use it
• Don't know what we don't know
165. Make it Quick!
• Proxies as needed
• Quick enough analysis
• Get to 80% confidence
• Continued learning with additional contacts
• Usability testing
• Customer visits (enterprise software)
166. Setting Expectations
• Developers
• Only get a little bit of information at a time
• Need to fit work in
• May need to rework as we learn
• Repeat it as we go
167. Arguments About UX
• Not done (what is “done?”)
• Indecisive (make up your mind!)
• Never right (“more feedback already?”)
169. UX Made “Agile”
• Any UX method can be adapted
• Don’t have to give up our favorite methods
• Don’t have to learn new ones
• Doesn’t take much effort to adapt our methods to fit the
Agile process
• Think about “lean” and “iterative” methods
• RITE is a good place to start
170. RITE Overview
• Qualitative user feedback
• actions + comments
• Series of small usability tests
• 3 participants each day
• Minimum of 3 days of testing
• Iteration between testing days
• Total of 5 days
172. What Works for RITE
• Best used early in project lifecycle
• Early concepts
• Need to be vetted with users
• Can assist in quickly shaping designs
• Doesn’t this sound “agile”?
172
173. Evaluation + Testing
• Think evaluation → testing throughout the product
development lifecycle
• Start with design evaluations and move onto testing
the deliverables for each Sprint/Iteration
• Start with the big questions and narrow down quickly
(what would be the top 3 things to fix/improve?
would you use it? Would it be a “wow”? which of 3
approaches do you prefer?)
174. Number of Participants
• Think fast and iterative
• For example ~5 participants for each, and iterate if
needed
• Key is to get the needed feedback, iterate, and move
on
• Do you really need 10 participants to tell you it’s
something they would never use?
• Know when enough is enough
• If 3 participants so far have “failed”, do you need to test
the other 2?
175. Testing Cycles
• Set a schedule and expectations with the team early
• User testing days (e.g., every Friday, we’ll have 3
hours set aside for testing)
• Schedule set to Sprints/Iterations (e.g., at end of
every Sprint, schedule a round of testing to cover
what has been completed)
• Also consider combining sessions for multiple goals
(e.g., test what was done last Sprint, get early
feedback on what you are working on now)
176. Testing Materials
• Use the lowest fidelity method possible to get the
needed information (the time spent in developing the
materials is time you won’t have for iterating and
testing)
• Use sketches and wireframes to work on basic
concepts and keep attention focused away from
details
• Use higher fidelity when you are testing the details
and interactions
177. Test Only Until “Done”
• Stop testing when you know enough to move
forward
• Test for the big stuff first: when you start hearing
about icons and colors, not function or layout, you
know it’s “enough”
178. Light Reporting
• Don’t write a report
• Focus on most important changes
• Record change decisions and reasons why (for
future reference, and for onboarding new designers)
• Explain changes to the team face-to-face
• Tell the story
180. Discussion
• Additional topics
• Bringing work in – how do you select the right thing(s)?
• Backlog grooming and where UX fits in
• Types of prototypes
• Other frameworks for Agile
• Working with PM’s, and leadership
• What are your experiences?
184. Principles behind the Agile Manifesto
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10.Simplicity—the art of maximizing the amount of work not done—is essential
11.Self-organizing teams
12.Regular adaptation to changing circumstance
http://www.agilemanifesto.org/principles.html
185. • Adapting Usability Investigations for Agile User-
Centered Design by Desirée Sy
• Journal of Usability Studies, Volume 2, Issue 3
(the most-cited paper in JUS)
• http://www.uxpajournal.org/