Using an Inception to kick off a project

Agile Inceptions are powerful and fast ways to get a team to internalise a vision and plan out a project. It’s a ~two-day investment that allows the teams to begin immediately deliver core product functionality.

Overview

Over the last 10 years or so I’ve been involved with teams adopting the Agile Inception format kick off new projects. The inception model is a kick-off 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. This page is not a comprehensive documentation of the process, but rather a how-to for interested project leaders to get started spinning up our own inceptions. Starter for 10 - The 2-day schedule Below is a sample schedule for a typical project that has had little formal planning until now. Some projects may not require a full 2 days if they are smaller in scope or have already undergone significant planning efforts. The schedule is a rough timetable (times based on an 8am-5pm day), and it is common to deviate from the exact times specified. While it is strongly encouraged that every team member – product owner (“PO”), business analyst (“BA”), Customer Experience designer (“CX”), usability designer (“UX”), developers, PM / scrum master – be present for the entire inception, the use of laptops 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.

(note the example agenda below is specific to the kickoff for the delivery phase of a project - the agenda would be a bit different if it was a design phase)

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 (PO)
9:15 – Break
9:30 – Goals & Timeline (PO)
10:00 – Service Blueprint (CX)
10:45 – Break
11:00 – Tech Solution Design (Tech lead)
11:45 – Lunch Break
12:30 – Story Reviews, Decomposition and Estimation (BA, UX, Tech lead)
2:15 – Break
2:30 – Story Reviews, Decomposition and Estimation (cont.)
3:30 – Break
3:45 – Story Reviews, Decomposition and Estimation (cont.)

DAY 2

8:15 – Get coffee & be seated
8:30 – Summary of where we left off & what’s ahead
8:45 – Story Reviews, Decomposition and Estimation (cont.)
9:30 – Break
9:45 – Story Reviews, Decomposition and Estimation (cont.)
11:45 – Lunch Break
12:30 – Risks and issues
1:45 – Break
2:00 – Sprint planning
3:15 – Break
3:30 - Sprint planning (cont.)
4:30 - Break
4:45 – Retrospective & Next steps (e.g. entering stories in Jira)
5:30 – End of Day 2

Description of Agenda Sections

Below are notes specific to the different parts of the agenda, as well as a few items that aren’t included in the default.

Introduction of People and Agenda

Start with a quick go-around of everyone’s name / role / department / etc. Discuss the agenda items, pointing out when the breaks take place. #Remind participants to not use electronic devices (laptops, phones, etc.) in order to have everyone engaged with few distractions. Create a space for terms (acronyms and vocabulary that may not be understood evenly among participants) and another for 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 (ie. get buy-in).

High-level product concept

This is an opportunity for us to introduce the product design. Both UX and UI are covered. This portion is led by the Product Manager(s) / PO(s), and previous experience with inceptions is helpful. The design (UX/UI) can be broken out into two types: experience vs visual design. The experience design is important for discussions of goals & risks and should be the focus of this section. The visual design, while important, can usually be covered as we create activities and stories.

Story Elaboration and Estimating

This activity is the most time-consuming of the process, and facilitators should 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 index cards on a wall. Two or more colors are helpful; use one color for the big stories, another color for child stories / tasks. 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.
Prioritisation

Establish the strategy to be used for prioritizing. For example, 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 prioritising epics & stories. Tape the cards to a wall by prioritised epic left-to-right across the top. Stories (children) fall under each epic, prioritized top-to-bottom.

Sizing the Stories

The developer teams (and others doing the work) will begin sizing each story, writing the points on each card. This activity can probably be done in parallel to the prioritisation, at least after the first epic or two has been prioritised.

Risks

This agenda section follows the following five steps:

Hand out 3×5 cards to each participant. Based on the goals, each member should identify the risks they see, writing one risk per card.
The facilitator (and helpers) will collect these cards organize them into themed groups spread across the table.
Distribute three pieces of candy (or other tokens) to each participant. Everyone will use their three tokens to vote on the biggest themes (not individual risks) on the table, and they may give multiple votes to a single issue.
Facilitator will tally the results onto another large (easel pad) paper and post on the wall.
Facilitator leads discussion of mitigation strategies.

Sprint Planning

Major steps are:

Define the team capacity per sprint (days of developer effort)
Take 70% of this to account for contingency, admin and continuous improvement tasks (or less if the risks are material)
Define the total number of sprints in the build increment (e.g. 4 sprints)
Identify all external dependencies (e.g. code coming from another team)
Allocate story cards up to the 70% level to each sprint, factoring for dependencies
Gain commitment from the team to the plan
Revisiting the Risks - After stories have been scheduled, the team re-convenes to revisit the original list of risks. Follow the same exercise as before, giving each attendee three tokens (pieces of candy, etc.) to vote on risk theme (not individual risk). Tally the votes and compare to the original baseline.

Retrospective & Closing

A quick retrospective of the inception is helpful to continually improve the process. Update this wiki with suggestions/improvements, and give constructive feedback to the facilitators so they can sharpen their skills.

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. Capturing actions with committed people (including backups) and due dates is a critical part of the process. At a minimum, someone will be tasked with capturing the information on the inceptions artifacts (cards and papers) and enter them into your preferred project-tracking software system and other documents.

Conclusion

Agile Inceptions are both powerful and fast in getting the team to internalise a vision, and 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, and the structured discovery process enables participants to begin delivering core product functionality immediately.

« Back