The Agile Gap: Closing it with User Experience


Published on

Agile is missing something. Stories and epics are focused on self-contained iterations but its not always clear how everything is supposed to fit together - what does the final user experience look and feel like? This gap in Agile is significant because the final user experience is how the customer determines value - is it efficient, effective, and satisfactory? Consider filling the gap with scenarios. Scenarios blend well with Agile by allowing the generation of iteration-level user stories but also make it very clear what is the desired user experience and value proposition. This session describes how UX professionals not only have the expertise but are uniquely positioned to develop and drive these scenarios, in turn making themselves an essential part of the Agile process.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • - Intro to ourselves, lend credibility (Brian first) - Agile creds, years practicing agile, development organization - Bring up a real conversation we had with someone at the conference, related to our topic (“How do you figure out what to build? What are some of the problems you experience?”) -
  • BRIAN - In pairs, answer this question - Give you 2 minutes, ready set go - Let it go until the audience settles down, or about 2 minutes
  • BRIAN - Who has some ideas to share of why that happened to you? - We have time for (one, a couple) more – who else has ideas to share?
  • BRIAN - Agile and no other development methodology is immune to this problem of ‘misunderstanding the user experience’. Hugh Beyer, author and speaker, advocates user-centered agile methodology but working within the scope of Agile. Reference quote – there is no upstream in Agile. Instead need to understand the stream we are in Example from picture: Given req’s to build things to help the salmon get up stream (e.g. fish ladders). Missing the context and user experience of why the salmon actually need to get upstream.
  • KALEB - Look at what the blind scientists are saying as they inspect the various visible features of this elephant. - Take 30 seconds to look at the comic and ask yourself what you would do to get everyone to start thinking “elephant”. - Who has an idea they'd like to share. - Now, imagine the elephant is the total user experience in your product stemming from multiple stories and epics in your backlog across maybe a single or multiple releases. Now think about these scientists as being your developers, product management, sales and marketing folks, etc. looking at your stories and trying to figure out what the intended total user experience is. - Chances are they're going to arrive at the same sorts of conclusions these blind scientists did. - Misunderstanding is one of the most common problems with an agile backlog, and can cause rippling effects throughout the software development process.
  • KALEB - Take 15-20 seconds to ask the question - Who would like to share?
  • The Agile Gap: Closing it with User Experience

    1. 1. The Agile Gap:Closing it with User ExperienceBrian M. Anderson & Kaleb D. Walton © 2012 IBM Corporation
    2. 2. When have you experienced this in an Agile environment? © 2012 IBM Corporation
    3. 3. Why did this happen to you? © 2012 IBM Corporation
    4. 4. “We are always trying to push ourselvesupstream. The thing about Agile is there isno upstream.”- Hugh Beyer, Author of User Centered Agile Methods © 2012 IBM Corporation
    5. 5. The Agile Gap – Understanding the user experience  Do you see any of this? – Ineffective prioritization – Unstable development with constant rework, Requirements thrashing and delay – Inconsistent, frustrating and low-value product experience Development User – Miscommunication about your product from Experience outside of development  Agile facilitates communication primarily focused on Requirements + Development  The gap is not in the requirements or development - it’s in the understanding of the user experience © 2012 IBM Corporation
    6. 6. © 2012 IBM Corporation
    7. 7. Can you close the gap with existing agile tools? © 2012 IBM Corporation
    8. 8. User Stories Adding context is contrary to INVEST – Story Independence deters expression of total UX – Context is big, not Small, reducing story agility – Heavy context may imply undue Value User stories arent broken – dont fix them! © 2012 IBM Corporation
    9. 9. User Stories Epics Just a large user story Adding context brings same problems as with user stories Total user experience is often comprised of multiple epics Epics arent broken – dont fix them! © 2012 IBM Corporation
    10. 10. User Stories Epics Product Vision “Paints a picture of the future that draws people in” - Scrum Alliance Helps to point people in the same direction Never intended to describe user experience Wrong tool for the job © 2012 IBM Corporation
    11. 11. Other ways to define the user experience?Use cases – Lack valuable user context (motivator trigger) – Too detailed and task specific (action-oriented) – Takes too much time More meetings! – Takes time away from development – Different meetings for different groups – Slow, expensive method to close the gap © 2012 IBM Corporation
    12. 12. How do you close the gap? © 2012 IBM Corporation
    13. 13. Introducing the “Scenario” Borrowing a concept from the UX discipline Our definition: A real-world example of a persons experience with a product, describing context with a problem and a proposed solution, bringing focus to their goals. Paints a picture of an experience that has value and can be sold © 2012 IBM Corporation
    14. 14. The “elevator pitch”Example Scenario EFFECTIVE PRIORITIZATION AND ASSIGNMENT OF WORK ITEMS PROBLEM Mary, a systems manager at ABC Health, is responsible for a team of 12 system administrators who handle steady state support of their health care systems and network. One of her biggest time sinks is prioritizing and assigning her teams daily work efforts. The tool she uses, Systems Manager Plus, doesnt give her any prioritization features except for the ability to sort on a priority field when reviewing work items. As she spends half of her time prioritizing she ends up working over time to tend to her other duties. SOLUTION After a major update Mary signs into Systems Manager Plus, heads to the work items area and is pleasantly surprised to see a number of new prioritization capabilities. There are more fields available to sort and filter, as well as a “smart assignment” system that enables her to specify rules that will result in automatic assignment to specific members of her team. Mary creates a few rules, applies them to existing work items, and is excited to see that over a quarter of the items were automatically assigned. She proceeds to sort and filter the remaining work items to prioritize and assign to her team. As more work items trickle in she notices that many of them are being auto-assigned. These improvements have enabled Mary to focus less on prioritizing and more on doing. © 2012 IBM Corporation
    15. 15. Derived Stories and Epics Additional sorting capabilities As a systems manager I want to sort work items by additional fields such as created date, severity and platform so that I can more effectively prioritize them. Additional filtering capabilities As a systems manager I want to filter work items by additional fields such as created date, severity and platform so that I can more effectively prioritize them. Smart assignment system (epic) As a systems manager I want to specify assignment rules for the system to use to automatically assign work items so that I dont have to assign every work item manually. Apply new smart assignment rules to existing work items As a systems manager I want to apply new smart assignment rules to existing work items so that I can use smart assignment on work items created after the smart assignment process has executed. © 2012 IBM Corporation
    16. 16. How Do Scenarios Fit in Agile? © 2012 IBM Corporation
    17. 17. Scenarios are Agile Just Barely Good Enough and Just in Time: – Fidelity naturally matches immediate need. Ya Ain’t Gonna Need It: – Does it enable the scenario? Minimum Viable Product: – What is the minimum experience someone would pay for? Lightweight Contract: – Low cost, flexible and easy to change. © 2012 IBM Corporation
    18. 18. Yearly Planning Release Planning Sprint Planning Development & Testing Release Review  Starts with ‘investment themes’  Continues with market research and other product management activities (e.g. writing PRD)  As ideas begin to form, conceptual, or “elevator pitch” scenarios are developed  Relative estimates are assigned to each scenario and they are prioritized in a backlog  Replaces PRD © 2012 IBM Corporation
    19. 19. Yearly Planning Release Planning Sprint Planning Development & Testing Release Review  Scenarios broken down & split so they fit into a release  Assigned to upcoming releases based on priority and development throughput  Continued refinement until they are “just barely good enough” to be broken down into stories  Wireframes are often developed during this time period  Scenarios become the lightweight contract between development and product management © 2012 IBM Corporation
    20. 20. Yearly Planning Release Planning Sprint Planning Development & Testing Release Review  Development team reviews scenarios and considered the ‘source of truth’ around the user experience  Common questions about stories are usually answered within the scenario, without product owner hand-holding  Scenarios continue to be refined based upon developer feedback © 2012 IBM Corporation
    21. 21. Yearly Planning Release Planning Sprint Planning Development & Testing Release Review  Scenarios are constantly referenced by development teams to validate the user experience they are creating  Scenarios are often used as the basis for test cases, and for validating the intended experience  Serves as the storyboards for iteration reviews  Progress reporting is scenario-based © 2012 IBM Corporation
    22. 22. Yearly Planning Release Planning Sprint Planning Development & Testing Release Review  Scenarios are used as the storyboards for the review © 2012 IBM Corporation
    23. 23. How do I get started with scenarios? © 2012 IBM Corporation
    24. 24. Begin Today!  Start small: Create scenarios for existing stories & epics – Pick a story from backlog and talk through an example of how it would be used – Add as much context as possible – Think of other stories you could naturally pull into scenario  Continue the evolution: Build your backlog by leading with scenarios  Maintain the format: 2-act play of Problem + Solution  Reinforce through communication: Refer to scenarios instead of stories & epics © 2012 IBM Corporation
    25. 25. Questions?Brian M. D. © 2012 IBM Corporation
    26. 26. References – Hugh Beyer quote An Easier Way to Develop Product Requirements – Modernizing “Modern” Applications: Agile and a Strategy of Continual, Iterative Development – © 2012 IBM Corporation
    27. 27. Fidelity © 2012 IBM Corporation
    28. 28. UX Evolution © 2012 IBM Corporation