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
- 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
- Must we satisfy other parties, e.g. developers on another team?
- Is there a near term, immovable milestone like a festival launch?
- Budget risks
- Will we run out of money before beta? Before launch? Before handoff?
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?
- Customer :: Project Manager :: Developer :: Designer :: QA Tester :: Support ratios
- mad-libs game
Mission Statement Game
- everyone writes a mission statement
- pass them around and highlight important/recurring words
- collaborate to write and reach consensus on a final statement
- hopefully without a lot of run-on "and" clauses
- traditionally: personas map to types of users
- practically: you can/should make personas for any human in the system
- developers, clients, admins, customer support reps, QA testers, apps, spammers…
- one persona per card/sheet
Roles and Activities
- for each persona, ask what they can do (and can’t)
- one card for each activity
- one card for each role
- diagram relationships among personae and activities and roles
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
- 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.|
- 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)
- 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!