Agile Inception

What is Inception?

Inception consists of a series of up to 11 exercises that help teams rapidly arrive at a shared understanding. For an Inception session to be successful, it is important that there be a neutral facilitator present, who acts as a moderator for the conversation, without trying to steer the team toward a particular decision.

Note: Credit for the Inception concept goes to Jonathan Rasmussen, who describes it in his book The Agile Samurai: How Agile Masters Deliver Great Software.

What’s the Benefit?

Particularly when a new product or feature set is being introduced, it can be a challenge to ensure that the team and stakeholders have a shared understanding of what needs to be built. As Rasmusson says in his book,

Assumption of consensus where none exists is what kills most projects

Rasmusson goes on to say that two of the worst things that can (and often do) happen when teams are just getting started:

  • People fail to ask the right questions

  • People don’t have the courage to ask the tough questions

Having an Inception session helps ensure that we take the time to ask these kinds of questions.


An Inception session can be helpful in many situations, such as the following:

  • Starting up a new Agile team
  • Beginning work on a new Product (either with one or more new teams or existing team(s) that will be working on the Product for the first time)
  • Rebooting an existing team that has undergone significant changes to team composition

Who Attends?

  • A facilitator (often a Scrum Master or an Agile Coach)
  • A subject matter expert on a new initiative or product (often a Product Manager or Product Owner)
  • Members of one or more teams
  • (optional) Stakeholders


  • A business case or similar construct that articulates the business value associated with the initiative/product/project
  • (optional) One or more business/technical artifacts, such as information about users, a flow diagram, or a diagram showing existing solution architecture (which can be hand-drawn or rendered via software)


As Rasmusson points out, the primary desired outcome from an inception session is:

Align on goals, vision, and context for a project/product/feature set so a team can make intelligent decisions while executing

If stakeholders are also present for the conversation, than an additional desired outcome is:

Give stakeholders the information they need so they can be informed participants as the team iteratively builds the desired product /feature set.

Preparing for Success

  • If the facilitator is new to Inception, self-study of the various activities will be necessary in advance
  • It is helpful for the facilitator to partner with at least one or person in advance (e.g., the Product Owner) to select the Inception activities
  • The facilitator will need to prepare a “container” which contains prompts/questions for each of the selected activities, either on a white board or flip chart paper (for in-person sessions) or in a presentation, document, or “canvas,” using software such as Miro or Mural (for sessions with at least some remote attendees)


Inception consists of up to eleven time-boxed exercises. Here is a minimalist set of Inception exercises that can fit just about any situation, whether enhancing an existing product, or starting a new product:

Why are we here?

To state this a bit differently—what is the single most important reason for us to work on this right now?
It’s likely premature to have an Inception session unless and until this question can be answered. Therefore, if you’re going to facilitate an Inception session, reach out to the person(s) who you think can answer this question before you meet, and see whether they can in fact answer it.

NOT list

Teams often get bogged down in questions about scope. One way to make the conversation about scope shorter at the outset is to try to agree on what is NOT in scope. Talking about what can be deferred until later can be a very revealing and insightful conversation, because it is common for the team and the Product Manager/Product Owner to enter the Inception session with very different ideas about what is not going to be in scope.

Technical solutions

Depending on how well the team understands what is being asked of them at this early stage, it can be a good idea to have a conversation about what technical approach might be best suited to addressing the business need. As the team’s understanding evolves over time, it’s possible what they originally thought about the technical approach could change, but I find it tends to be helpful to have such a conversation as early as possible.

What keeps us up at night?

The essential aspects of this conversation are to try to surface things that could constitute dependencies and risks, and to capture some initial thoughts on what steps can potentially be taken to minimize the impact of such dependencies and risks.

Additional Inception exercises include:

  • The elevator pitch. The basic construct here is to arrive at a brief description that could be used to explain the what, why, and how to somebody who knows nothing about it, typically in 60 seconds or less. The Inception Deck referenced below provides a useful template.
  • Product box. This is a popular exercise in training contexts like the Certified Scrum Product Owner (CSPO) course. The idea is to create basic content (images and text) that would go on a box containing the product. (Whether it would ever actually be a shrink-wrapped product is beside the point; the idea is for the team working on it to be able to describe it in a way that would make sense to a prospective buyer/user.)
  • Your project community. This conversation focuses on making sure it’s understood who the stakeholders are.
  • The Team. An initial conversation about who’s on the team. Hopefully all of them are in the room for this conversation ; ).
  • How big is this? A preliminary conversation where the team tries to arrive at how large an effort this is, in comparison with other work they’ve done.
  • Trade-off sliders. A visual technique that helps reinforce the notion that only ONE thing can be fixed. If there is a hard deadline, then schedule is fixed; and if there is a must-have feature set, then scope is fixed.
  • The first release. It can also be helpful to talk about which feature(s) could potentially be released the earliest.

Background Information

How is Inception Different from Chartering?

For anyone who has facilitated a chartering session (often referred to as Project Chartering or Team Chartering), chartering sessions can be significant undertakings which can last anywhere from a couple of hours to one or more days.

In the hands of an experienced facilitator, chartering sessions are a great tool to have in the toolbox, and can pay big dividends early by helping teams and stakeholders get into alignment on what they are trying to achieve. 

A significant difference between Chartering and Inception is session length. It’s generally possible to complete an Inception session in less than one hour (assuming that Product Box, which takes longer to facilitate, is not included).

Note: Project Chartering or Team Chartering is NOT the same thing as writing a “Project Charter” document, in that the primary desired outcome is not a formal documentation deliverable or artifact – it’s a shared understanding of the nature of the work that is to be done, captured in a place that is readily accessible for easy team reference. For more about chartering, refer to the book by Diana Larsen and Ainsley Nies that is cited in the References section below.



Inception Deck (template)

If slide decks are your thing, Jonathan Rasmussen created a blank Inception deck that you can use as a template for an Inception conversation.