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 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.

The Story Map

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 story

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

goofy sun wearing sunglasses

My Morning at Work (first draft)

Find Variations

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

goofy sun wearing sunglasses

My Morning at Work (revised)

There are variations between people, days of week, at-home and out-of-town work days

Building the narrative: Users

Who are the Actors/Users in your morning routine?

Building the narrative: Activity Groups

Sometimes several tasks can be grouped together

Build The Story

My work story map

Let's put them together to build a story of your getting to work!

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
Anatomy of a User Story Map

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

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

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!