Proper Story Writing for User Experience in Agile

I am purposely avoiding the debate over whether design and agile can work together and instead providing my experience should agile be deemed the project management technique of choice. Several early adopters and founders of agile are currently touring the world-begging disciples to pay less attention to process for process sake. Any good creative will tell you that the best design rarely comes from following a prescription to the letter, please keep that in mind as you proceed. The only advice that I’ve found to be universally true is that a “story” is called a “story” because it demands discussion.

Basic structure of a story

Story

  • As a [role], I need a [feature] so that I can [task/activity].

Acceptance Criteria

  • What will be delivered by the end of the sprint – typically outlined during the sprint prior.
  • Often times I will include a sample user flows (note that I said “user,” NOT “process” flows) at the top of my story to give context for anyone who will touch the story.

Tasks

  • How it will be delivered and by whom. 

Sample Story 

As a Channel Partner, I would like to have Step 1, Step 2, and Step 3 available in an easy to use format so I can request Marketing Development Funds via the portal.

This user story is to provide a mock up of that process.

User Experience Acceptance Criteria

A channel partner has an upcoming event for which they would like Company ABC to provide $6,000. Prior to requesting funds they’ve chatted with their Channel Manager to confirm that they will likely be pre-approved. Entering the Request is more of a formality and something they’d like to do quickly.

[insert mockup link]

Log in from Customer Portal

  • Tab, furthest right at top, entitled “Development Funds”
  • Opens as a new browser tab from Customer Portal

Development Funds Landing Page

  • [Mockup Link]
  • “Create A Request” button on left
  • Recent Items includes Request Icon (attached) http://fortawesome.github.io/Font-Awesome/icon/credit-card/
  • Welcome Headline
  • 160 Character limit text section directly below welcome banner editable by System Admin
  • List Views (My Approved Requests, My Pending Requests, My Saved For Later Requests, My Recently Viewed Requests) leverage native functionality with Customer Portal CSS styles
  • Banner that links to PDF uses an editable text component.

Request Form

  • [Mockup Link]
  • Leverage “My Profile” styles for accordion
  • Buttons at top: Check Spelling, Save for Later (uses notification system), and Cancel
  • Step 1
    • Step 1 on Create fields: Name of Request (text), Type of Activity (Picklist), Activity Objective (text medium), Activity Start Date (bootstrap date picker), Activity End Date (bootstrap date picker), Amount Requested (text with USD prompt), Promoted Products (text with Enter Product(s) prompt), ID (system generated, read only). Submit button nested in Step 1 on Create – creates a record with the information and updates status in backend
    • On Step 1 in Create, Step 2 and 3 are grayed out (#6f6570) and locked
  • Step 2
    • Step 2 on Create fields: Leads Generated (Number), Event Description (Post Event) (text medium), Total Cost of Event (text with USD prompt). “Submit” and “Submit and Add Attachment” buttons nested in Step 2 on Create – updates record with the information and updates status in backend.
    • On Step 2, Step 1 font and carrot are active color (690070) but Submit button does not show. Fields are read only, “Principal Account” and “Request Date” added.
    • On Step 2 in Create, Step 3 is grayed out (#6f6570) and locked
  • Step 3
    • Step 3 on Create fields: Products Sold (number), Comments (text medium), Revenue Generated (text with USD prompt), Other Relevant Data Points/Proof of Success (text medium). “Submit” and “Submit and Add Attachment” buttons nested in Step 3 on Create – updates record with the information and updates status in backend.
    • On Step 3, Step 1 and 2 font and carrot are active color (690070) but Submit/Submit and Add Attachment buttons do not show.

Request View/Edit

  • All three Step accordions are open
  • Fields are read-only

Decisions to discuss with your team

  • Should we include acceptance criteria for all teams on ONE story or more (e.g. Customer Experience Acceptance Criteria, Integration Acceptance, Criteria, Business Acceptance Criteria)?
    • Using one story can inadvertently give a cross-functional view of how a solution is progressing. Sometimes a story may become to large to have multiple teams on it.
  • What if I know I will need to design something but I don’t have all of the complete information yet (e.g. an email needs to get sent from the system but we don’t have the exact copy or audience?)
    • It wasn’t until I started using Powerpoint heavily (yay consulting) that I understood the Mona Lisa example given for how agile works. Outline first, then fill in detail and learn from work you’ve done to-date. When creating a PowerPoint, I naturally am drawn towards perfecting each slide then moving on to the next. Over time, I’ve learned to storyboard my presentation with pen and paper first, draft my copy, make my visuals a reality, then go back to edit. I’ve found it’s best to put a placeholder spot for an email in your system rather than skip over it for the time being or attempt to create a fully functioning email without verified copy.
  • What cadence for design and development works best?
    • Most commonly we aim for design prior or in tandem with development. Sometimes you work in a system that has native paradigms which design then goes back to refine.
  • Should I use persona or role in my story?
    • It depends. At my last company, we attempted to template this and the real answer is use will vary based on project size, budget, and team.
  • How should design be included in story pointing for more technical stories?
    • Do your best to work it out as a team up front so you can stay consistent on numbering. My unfounded gut reaction has been that as a designer I will give me best estimate for the affect on experience as opposed to completely handing over the reigns to my technical peers
Advertisements