Previous Lesson
 Agile Development 

Inceptions

Next Lesson 

 Slides





inception

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)

Inception Goals

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

Inception Anti-Goals

  • 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
  • others?

Inception Schedule

  • 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

sample schedule

from Pivotal Labs

Project Goals

  • keep all goals SMART (specific, measurable, achievable, relevant & time-bound)

  • business goals

  • product goals

  • engagement goals

Team goals

  • workday experience and pacing
  • exploring technology vs. exercising skills
  • using new or old processes (e.g. remote pairing)

Project Non-Goals

  • 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

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/

Team Risks

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

Elevator Pitch

Play the Mad Libs 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

elevator pitch

(from https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/)

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!

Personas

example persona

Sections:

  • picture
  • motto (quote)
  • demographics
  • bio / personality
  • goals
  • frustrations

Links:

Persona Details

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

Story Mapping

  • 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

"The goal isn’t to get all the cards created, but to establish a rhythm of story creation."

Story Mapping Example

Winninpeg Example Story Map

http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html

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:

Epics

  • 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

  1. Write Story Titles
  2. Organize Stories into Epics
  3. Prioritize Stories under Epics
  4. Write Stories
  5. Estimate Stories
  6. 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

Iteration Zero

  • 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

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?

Next Steps

  • 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?

Party Time!

  • We're done!

References



 Previous Lesson
 Agile Development 

Inceptions

Next Lesson