Scrum and User Experience Design: Bringing Great Design into the Agile Process Patrick Neeman, Usability Counts Mike Vincent, MVA Software
Scrum A process for managing complex projects. Stay small: Focus on smaller, measurable increments Staying in communication: Short meetings to encourage more short meetings between fewer team members Stay transparent:Inspection is dependent on transparency.
Scrum… Works Well Existing products Smaller teams Projects with no existing methodology Projects with existing technology but a failed approach Dedicated teams Jack of all trade team members Doesn’t Work So Well Undefined, new products Larger teams and projects Teams with members on several projects Without a strong team in place Specialists
Scrum Sprint Process Daily: Talk about yesterday, today, tomorrow(15 minutes) Take longer conversations offline Retrospective: Change the process to make it better(1 hour) Don’t change Product Backlog (list of features) once sprint has started Week 1 Week 2 Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Daily Meeting Retrospective Meeting Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
Product Owner Defines the features of the product Agency: Client is Product Owner Company: Product Manager/UX Lead is Product Owner Manages project features and releases to optimize return on investment (ROI) Inspects increment and makes adaptations to project after end of sprints Can change features and priority every X days, but not in the middle of a Sprint
Scrum Master Ensures that the team is fully functional, productive and improves quality Enables close cooperation across all roles and functions and removes barriers Shields the team from external interferences Ensures that the process is followed Teaches Product Owner and Team how to fulfill their roles Not a dedicated role, but it’s nice if this it the UX team member
Roles and Responsibilities Team Cross-functional, seven plus/minus two members Example: 1 UX Designer, 3 Developers, 2 QA Self organizing Manages itself, its work and its process Commits to what it feels it can accomplish Limit team to 45 hour work weeks for measurable results Collaborates with Product Owner to optimize value Demos work results to the Product Owner as much as possible Hallway usability testing
Team together with product owner defines what “done” means.
Done defines the current technical capability of the team.
Typically, Done should include everything needed before deployment.
Done may be a stub page or a process that requires human intervention.
Not done backlog items should be pushed to the next Sprint.
How to measure Done Development team must be able to produce a completely “done” piece every Sprint Product Owner must inspect and adapt to optimize ROI every Sprint “Undone” work must be identified WaterfallDone at end of project Development Process Done Agile/ScrumDone at end every iteration Done Done Done Done Done
Documentation Plan Just enough – it’s what you have to say and what you don’t have to say Overall style guide High level use cases / user stories Light wireframes, 3 by 5 cards, hand written notes Don’t update what you don’t need Detailed test plans (definition of done) Pass / Fail The only deliverable that counts is the final product
Corporate Espionage Sprint Plan Where User Experience / QA fits in Work one sprint ahead Wireframes Test Plans Test driven development Unit tests defined by requirements Test plans are written to define completing requirements Schedule a sprint or two for user research
Product Backlog User Research – Sprint 1 UX Scoring Architecture – Sprint 2 Claim Card – Sprint 2 UX Play Card – Sprint 2 UX Sign In – Sprint 2 UX Sign Up – Sprint 3 UX Pick Card – Sprint 4 UX Score Card – Sprint 4 UX
Example Product Development Team agreed to… Two week sprints Daily 15 minute meetings Retrospective, no more than one hour, talk about process One sprint on user research Everyone gives estimates, fill 80 percent of their schedule (8 of 10 days) Developers need breathing room UX’ers need drinking, research time With further sprints, estimates will become more refined
Sprint Backlog 1 Developers Set up development environment Set up testing environment User Experience / QA User Research What is the game Who is the target audience Plan with product owner the first few sprints Plan a design pattern Claim Card
Sprint Backlog 2 Developers Scoring Architecture Build Of Pages/Stubs Claim Card User Experience / QA High level use cases High level site map -- Establish Pages/Stubs Play Card
Sprint Backlog 3 Developers Create Pages/Stubs Play Card User Experience / QA Pick Card Score Card A/B Testing of Claim Card
Sprint Backlog 4 Developers Play Card Score Card User Experience Claim Card Refactor
Retrospective What did we do well What didn’t we do well Is our Product Owner Happy? Produce working fully tested software Did not produce unnecessary stuff Metrics Look at key reports