What's Your Skateboard?

Emily Stamey

© photo by Kenny Louie
developer

I'm a PHP developer

I've often worked directly with non-technical product owners and users

I workED at a University

Inspired By

A Problematic Project Workflow

  1. Research
  2. Develop over several months
  3. Deliver something
  4. Learn if the big guess was correct

The Client-Vendor Anti-Pattern

What's so great about this anyway?

Communicate with non-technical users of the product

Removes implementation from the discussion

Objective-focused deliverables

What is a Story Map?

A diagram of a project that tells the story of the people and systems involved in a process.

Detail is added as we learn more about the project

The map can be built for an existing application or a new application.

Diagram of a User Story Map

Who should Story Map?

Anyone who knows the process ... Not Just Developers

At least one knowledgeable person from each group of stakeholders

When to Story Map?

 

  • When you have questions
  • Before You begin development

Why Story Map?

  • Build shared understanding
  • Encourage full discovery before prototyping
  • Prioritize work to be done as a group

*Lowers problems with estimates and feature creep

The big picture

Panorama of mountains, a town, and fields far into the distance
© photo by Barnyz

Focus during development

Focus
© photo by Theilr

Where?

A large, clear wall or whiteboard.

A place central to the team, at least in the beginning.

You'll need

  • painter's tape
  • markers
  • post-its (many colors & sizes)

A simple example

Use a familiar process that is not your project

List five tasks you do in order to get to work. Put each one on a post-it provided.

goofy sun wearing sunglasses

Find Variations

Pick 3 things that you did today that are different from your normal work routine.

goofy sun wearing sunglasses

Building the narrative: Users

Who are the Actors/Users in your morning routine?

Building the narrative: Activity Groups

Build The Story

My work story map

Learn More

  • Risk
  • Assumptions
  • Uncertainty

If you cannot elaborate, mark it and revisit

Clarifying Questions

  • What could we learn to replace risk with REAL information?
  • Do we really know what has been mapped, or did we fill in assumptions?
  • Are you sure about the story you're telling?

Label These

Thorough Discovery

  • Understand the full process
    • Understand "why" steps are needed in the process
    • Talk about things inside and outside of the app

Thorough Discovery

  • Simplify and lower risk at implementation
    • Lowers the questions at the phase of implementation
    • Limits Feature Creep (beginning implementation w/o understanding, new features come in)
    • Better estimates

More than just adding stories

If the only thing you create while making sense of a big opportunity is more, small stories, you're doing it wrong.
- Jeff Patton

Four Steps to Discovery

  1. Frame the idea
  2. Understand Customers and Users

Simple Persona

Four Steps to Discovery

  1. Frame the idea
  2. Understand Customers and Users
  3. Envision your solution
  4. Minimize the plan
Anatomy of a User Story Map

Priorities

Prioritizing the Project

  • Who will use this product?
  • What steps must they accomplish for success?
  • Remove/postpone the rest

Prioritizing Features

  • Differentiator - feature sets you apart from competition
  • Spoiler - moves in on someone else’s differentiator
  • Cost reducer - reduces organizational costs
  • Table stakes - feature necessary to compete

Focus on Outcomes

  • What are you hoping to do with your application?
  • Prioritize features based on the problem they solve
  • Implement only what solves the problem or meets the objective

Prototyping

Prototyping

  • What is the smallest thing you could build to prove/disprove an assumption?
  • Sketch & prototype to test viability of the solution
  • Aim for less than minimum, get feedback, and iterate often
  • When you give prototype to development partners you can include metrics to see what they actually do

MVP vs. Most Valuable Features

Focus on releasing valuable features every time.

Sometimes we plan features in a chronological order

Or we divide the project into components

When we build in pieces

Building a car in parts

When we build in parts

Painting in parts

Instead we want to iterate!

Building a car in parts
Painting in layers as the image becomes cleared

Strategies

Opening Mid and Eng-game Strategies stacked on top of each other

opening game strategy

  • When the number of features is too large, you can cut a slice across that gives you the minimum end-to-end functionality;
  • It doesn’t solve all user’s stories, but it affects the largest number of stories.
  • With this product, they can have test data, begin testing it for load, and see how it will work

midgame strategy

  • fill in and round out features
  • support optional steps
  • implement tough business rules
  • continue testing the product usability

endgame strategy

  • refine: make it look more polished and efficient
  • it’s here that you’ll have feedback from users that can be applied.

Summary

  • A tool you can use with non-technical subject matter experts, customers, etc
  • A visual guide for managing your workload
  • Focus on objectives when you prioritize
  • Plan to deliver a usable product at each deliverable

Sooo...

What's Your Skateboard?

Thank You!