Agile Inceptions are powerful and fast ways to get a team to internalize a vision. It’s a two-day investment that saves the company months of up-front planning and allows the teams to begin immediately deliver core product functionality. The inception model is a kickoff strategy that is repeatable and well-vetted. At it’s core, the inception deals with how we scope. The session(s) relies on full participation by an engaged audience, and co-location is crucial as we swarm around note-cards on tables and walls.

1. Using Inceptions to
Kick off Agile Projects
Victor Bonacci
June 5, 2014

2. Agile Inceptions
• kickoff strategy that is repeatable and well-vetted
• fast way to get a team to internalize a vision
• relies on full participation by an engaged audience
• co-location is crucial
• swarm around note-cards on tables and walls
• one- or two-day investment
• saves the company months of up-front planning
• allows the teams to begin immediately deliver core
product functionality

3. Sample 2-day schedule
• for a typical project that has had little formal
planning until now
• may not require a full 2 days
• if project is smaller in scope
• if has already undergone significant planning efforts
• schedule is a rough timetable
• times based on an 8am-5pm day
• common to deviate from the exact times specified

4. Day 1
• 8:15 – Office orientation
& get coffee
• 8:30 – Welcome: what’s
an inception?
• 8:45 – Introductions:
who’s who?
• 9:00 – High-level
product concept &
background
• 9:15 – Break
• 9:30 – Goals & Timeline
• 10:00 – Risks
• 10:45 – Break
• 11:00 – User Roles
• 11:45 – Lunch Break
• 1:00 – Activities and
Workflows
• 2:15 – Break
• 2:30 – Story Mapping
• 3:45 – End of Day 1

5. Day 2
• 8:15 – Get coffee & be
seated
• 8:30 – Summary of
where we left off &
what’s ahead
• 8:45 – Story Mapping
(cont.)
• 9:30 – Break
• 9:45 – Story Mapping
(cont.)
• 10:45 – Prioritization
• 11:45 – Lunch Break
• 1:15 – Risks (revisited)
• 1:45 – Break
• 2:00 – Next Steps
• 2:15 – Retrospective
• 3:15 – End of Day 2

6. Be present and engaged
• strongly encouraged that every team member be
present for the entire inception
• product managers, architects, designers, developers,
testers, project managers, other stakeholders
• use of laptops / other devices is frowned upon
• they have a way of distracting people!
• in addition to lunch, there are breaks throughout
each day
• email checking, etc. should be reserved for those times
so that all attendees are focused and engaged.

7. Introduce people and agenda
• Start with quick go-around of everyone’s name, etc.
• Identify agenda items and breaks
• Remind participants to not use electronic devices in
order to have everyone engaged with few distractions
• Create a spaces for:
• terms - acronyms and vocabulary that may not be
understood evenly among participants
• parking lot items - topics to be discussed later without
interrupting the meeting’s flow
• large pieces of paper from an easel pad work well –
stuck on a wall somewhere visible.
• Ask if everyone is clear with the agenda and rules
• important to get everyone’s buy-in

8. High-level product concept
• opportunity to introduce the product design
• both UX and UI are covered
• led by the Product Manager(s) / PO(s)
• previous experience with inceptions is helpful
• design (UX/UI) can be broken out into two types:
• experience design - important for discussions of goals &
risks and should be the focus of this section
• visual design - can usually be covered later in more
detail as we create activities and stories

9. Goals
• Log onto large, tear-away (easel pad) paper and stick
onto wall for quick reference
• Goals fall into four categories:
• business goals – eg. engineering efficiency, paid version of
the product, better position for us to ship features
• product goals – eg. product readiness, SLA reliability, etc.
• engagement goals (for facilitator) – eg. inception training
• non-goals (things we explicitly do not want included in the
scope) – eg. open source, fancy bells & whistles
• keep all goals SMART
• specific, measurable, achievable, relevant & time-bound
• identify goals by time (eg. month or quarter) or sequence

10. Risks
1. each participant uses 3x5 cards to identify the
risks they see, writing one risk per card
2. facilitator will collect these cards & organize them
into themed groups spread across the table
3. each participant will use three votes for riskiest
themes (not individual risks), and they may give
more than one vote to any single theme
4. facilitator will tally the results and post on wall
5. facilitator leads discussion of mitigation
strategies.

11. Actors and Activities
• Identify roles (internal and external) and write one
per 3×5 card
• Ask for each actor what they can do in the system
at a high level (activities)
• Examples include:
• internal developers
• other internal teams (billing, operations, support, etc.)
• customers (technical & non-technical), their agents &
apps
• 3rd-party entities (eg. remote MTAs, spammers, etc.)

12. Story Mapping
• The most time-consuming of the process, but do not rush it
• Facilitators especially use their skills to:
• Keep one conversation going. Eliminate multiple conversations so
that everyone can consume all available information.
• Remain impartial (don’t bias the discussion) and ask clarifying
questions (assume that not everybody knows the shorthand).
• Break each story down as small as possible (eg. by method call).
• Log onto 3×5 cards. Two or more colors are helpful; use one color
for the epic level, another color for child stories. Use colors
different from the Actors/Activities cards.
• The goal isn’t to get all the cards created, but to establish a
rhythm of story creation. More stories will inevitably get
identified and created post-inception, but knowing how to
brainstorm is the key.

13. Prioritization
• Establish the strategy to be used for prioritizing
• are we going to address risks first, or do we want many
stories to be completed quickly (momentum &
visibility)?
• The product team representatives will take the lead
responsibility prioritizing epics & stories.
• Tape the cards to a wall by prioritized epic left-to-
right across the top
• Stories (children) fall under each epic, prioritized
top-to-bottom.

14. Pointing / Sizing the Stories
• Developer teams (and others doing the work) begin
sizing each story
• write story points on each card
• Can be done in parallel to the prioritization
• Can begin after the first epic or two has been prioritized

15. Revisiting the Risks
• After stories have been prioritized and sized
• Team re-convenes to revisit the original list of risks
• Follow the same exercise as before
• give each attendee three tokens (pieces of candy, etc.)
to vote on risk theme (not individual risk)
• tally the votes
• compare to the original baseline

16. Next Steps
• Review any Parking Lot items to see if anything has
been missed (stories, etc.) and potentially schedule
out additional meetings to cover edge cases,
dependencies, etc.
• Capture actions with committed people (including
backups) and due dates
• Record the information from the inception’s
artifacts (cards and papers) and enter them into
your preferred project-tracking software system
and other documents.

17. Retrospective & Closing
• A quick retrospective of the inception is helpful to
continually improve the process.
• Update your process with suggestions for
improvement.
• Give constructive feedback to the facilitators so
they can sharpen their skills.

18. Conclusion
• Agile Inceptions are both powerful and fast in getting
the team to internalize a vision
• The two-day session vets out goals, risks, roles and use
cases, as well as other key topics
• All the players are together, focusing on the project
and airing the ideas and assumptions about the
project so that the entire team starts off on the same
page.
• The design emerges organically, saving months of
requirements gathering.
• The structured discovery process enables participants
to begin delivering core product functionality
immediately.