What is an Inception?
- an exploratory workshop…
- where the whole team…
- defines the goals and themes for a project…
- and produces an initial backlog…
- to kickstart an iterative process
Before the Inception
Some research and development has happened, e.g.
- Business / Market / User Research
- some user experience design
- some user testing of mockups
No code has been written
- (or, any code that has been written will be thrown away)
Resources and time have been allocated for a short project
- (inception + discovery + maybe one MVP)
- define the project’s goals, anti-goals, risks
- produce an initial story backlog
- produce a rough project timeline
- establish initial recurring schedule for team meetings
- sketch technical architecture (but avoid Big Design Up Front)
- introduce the team to each other
- define who is the customer (and other responsibilities)
Optional Inception Goals
- write elevator pitch and/or mission statement
- define user Personas, Roles and Activities
- build paper prototype or wireframe sketches
- write team charter
- determine need for more discovery
- start project glossary (aka ubiquitous language or domain language)
- examine assumptions (scope, schedule, feasability, business goals, risks, user population, team size, etc.)
- working software
- an inception is not a hackathon
- set anything in stone
- it's an iterative process; everything may change
- set rigid requirements and deadlines
- we will know more later
- can be one day, two days, or a full week
- needs a facilitator
- invite as much of the whole team as possible
Sample Inception Schedule
from Pivotal Labs
keep all goals SMART (specific, measurable, achievable, relevant & time-bound)
- workday experience and pacing
- exploring technology vs. exercising skills
- using new or old processes (e.g. remote pairing)
- aka "The Not List"
- things we explicitly do not want to accomplish in the project
- useful when there’s a priority decision to be made
- e.g. if a non-goal is "support mobile" then we can ignore Mobile Safari UI bugs
- It's also OK to list unknown or unresolved goals
- Business risks
- Does the market want this?
- Will an emerging technology disrupt this product?
- Can the client support success?
- Technical risks
- Are there 3rd party integrations?
- Are there unknown technologies or libraries to learn?
- Does the product rely on platforms that are changing, e.g. Android or Apple Watch?
- Schedule risks
- Is there a near term, immovable milestone like a festival or holiday?
- Are there bottlenecks or signoffs, e.g. developers on another team?
- Budget risks
- Will we run out of money (aka "runway") before beta? Before launch? Before handoff?
- Other risks?
- Legal or regulatory?
- Specialized knowledge (e.g. human language fluency)?
How do we want to work?
- Part-time (vs. dedicated) team?
- Remote (vs. co-located) team?
- Customer availability? (in-room, on-site, etc.)
- Deployment environment? (stability, automation, scripting, other hassles)
- Desired test coverage?
- Desired role ratios?
- Customer :: Project Manager :: Developer :: Designer :: QA Tester :: Support :: Ops :: Coach
Play the Pitch Game!
An elevator pitch is a concise, clear, persuasive explanation of a product that can be told in the time it would take to ride an elevator.
Split into small groups and within each group, brainstorm to fill in the following template:
For ______ who need ___, the ___ is a ______ that ___. Unlike _, our product ____.
Then select a spokesperson to share your result with the group. If time allows, collaborate to create a consensus pitch statement.
Elevator Pitch Example
Mission Statement Game
- everyone writes a draft mission statement
- pass them around the group and highlight important/recurring words
- write those words on a whiteboard
- then dot-vote on them, and use at most the top three or four
- collaborate to write and reach consensus on a final mission statement
- hopefully without a lot of run-on "and" clauses
- example (bad): "focusing on birds, other wildlife, and their habitats"
Consensus is hard; concise consensus is a miracle.
Here are some mission statements from 50 non-profit organizations, sorted from shortest to longest. See how much more poignant the short ones are!
- motto (quote)
- bio / personality
- persona design comes from user research, so traditionally, personas represent types of end users
- but practically, don't limit yourself to end users -- you can and should make personas for any human in the system
- developers, clients, admins, customer support reps, QA testers, apps, spammers…
- only one persona per sheet
- pick a real-sounding name (not a cute pun) and invent details that have nothing to do with your product
- this facade will help activate the creative, narrative, storytelling part of your brain
- often you will discover new use cases or scenarios via these ostensibly irrelevant details
- there are many online persona tutorials and even persona generators:
After creating the personas, you can start applying them to the system you're designing, e.g...
- for each persona, list ways to reach them
Roles and Activities
- for each persona, ask what they can do (and can’t)
- start to diagram relationships among personae and activities and roles
- start to make timelines and sequence diagrams showing communication and workflow between roles and documents
- very time-consuming
- take plenty of breaks! facilitator, don’t rush!
- the goal is to get broad and deep, clustering rather than prioritizing
- looking for themes, not details
- but still, try to break down stories into smaller stories
Story Mapping Example
- A story:
- provides business value
- is discrete
- is testable
- is estimatable
- can be implemented within 1 iteration
- Usually one story per feature, bug, or chore
(For more see the Planning lesson.)
Story Body Template
Story titles should be brief and imperative; story bodies should follow this pattern:
AS A ____ [role or persona] I WANT TO ____ [action or goal] SO THAT ___ [value or motivation]
|Sort By Price|
|As a customer, I want to sort the matching cars by price, so that I can see the best deal.|
Acceptance Criteria Template
Generally a single story has several acceptance criteria, which are often written following this pattern:
GIVEN ____ [precondition or scenario] WHEN ____ [the user does something, or something interesting happens] THEN ____ [the system is in this state, or responds in this way]
- The "then" part must be something observable, ideally by an automated test.
- Use present tense for WHEN and subjunctive mood ("should") for THEN
- During the Inception, don't worry too much about filling in acceptance criteria for all stories, but it can be useful to do so for important or mysterious stories.
GIVEN I have $100 in my bank account,
WHEN I attempt to withdraw $200,
THEN the bank should reject the transaction
AND I should still have $100 in my account
- An Epic is a series of Stories
- Can also be called a Theme or a Feature Set
- For instance, the epic “User Accounts” could include “Sign up, Sign in, Change password, Edit profile, Upload pic”
- Put epics across the top row of your story map
- Put stories in columns underneath their epic
Story Mapping Order
- Write Story Titles
- Organize Stories into Epics
- Prioritize Stories under Epics
- Write Stories
- Estimate Stories
- Prioritize Stories into a Backlog (across Epics)
Advice for Facilitators
(for Story Mapping or any planning or retrospective workshop)
- Stay impartial
- Assign a Timekeeper and a Scribe (so you can focus on the meeting, not the logistics)
- Try to ask questions, not make statements
- After asking a question, count to ten! someone else will fill the silence
- Ask clarifying questions, even if you know the answer
- If the conversation veers, steer it back to the original topic (or ask for consensus to change topics)
- Use a Parking Lot (or IOU) list for items to deal with immediately after the meeting
- If the conversation ebbs, ask if anyone sees a pattern… or has a suggestion… or if it’s time for a break
- sometimes inceptions reveal that a project is not yet ready to build
- the first iteration can be used for continuing the discovery phase of a project
- the team can use the first iteration (sprint) for...
- building a prototype
- "spiking" proof of concept on architectural or usability unknowns
- setting up technical infrastructure (build, deployment, environments)
- these experiments should be bounded and scoped just like "real" features
Inceptions are a great place to establish the regular rhythm of the project, as punctuated by recurring meetings.
- Review Parking Lot / IOUs
- Schedule additional meetings
- Assign someone to capture cards and diagrams into Tracker
Retrospective & Closing
- Have a brief (5 min.) retrospective about this inception.
- What worked?
- What didn't?
- Specific feedback for the facilitator?
- Appreciation Circle
- Any last thoughts?
- We're done!