I'm a PHP developer
I've often worked directly with non-technical product owners and users
I workED at a University
What's Your Skateboard?
Emily Stamey
© photo by Kenny Louie
A Problematic Project Workflow
- Research
- Develop over several months
- Deliver something
- 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.
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
© photo by Barnyz
Focus during development
© 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.
Find Variations
Pick 3 things that you did today that are different from your normal work routine.
Building the narrative: Users
Who are the Actors/Users in your morning routine?
Building the narrative: Activity Groups
Build The Story
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
- Frame the idea
- Understand Customers and Users
Simple Persona
Four Steps to Discovery
- Frame the idea
- Understand Customers and Users
- Envision your solution
- 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
When we build in parts
Instead we want to iterate!
Strategies
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!
