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)
Project Risks
- 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?
- Safety?
- Specialized knowledge (e.g. human language fluency)?
Based off http://pivotallabs.com/agile-inception_knowing-what-to-build-and-where-to-start/
Elevator Pitch
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.
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!
Persona Sections
After creating the personas, you can start applying them to the system you're designing, e.g...
Marketing Plan
- 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
Stories
- 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]
e.g.
| 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.
Example:
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
Links:
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
Recurring Meetings
Inceptions are a great place to establish the regular rhythm of the project, as punctuated by recurring meetings.
- Standup (daily)
- Planning Meeting (at least once per iteration, up to several a week)
- Acceptance (can be weekly, semi-weekly, ad hoc, or any combination)
- Demo (often coincides with Acceptance, but not always)
- Retrospective (weekly, bi-weekly, or monthly)
- User Testing sessions
- Others?
