The role of Inception in Scrum
One thing I regularly see mixed into the use of Scrum are exceptional Inception (aka. ‘Kick-off’) meetings where a Product Owner will pull together the scrum team with the aim at getting that team across the next major piece of value that they intend on delivering.
Typically these meetings are driven by the Product Owner — introducing the wider team to a much broader set of information about the next major piece of value, often captured in some Epic of Feature artifact.
The team will meet and (hopefully) discuss the information presented, and the ultimate goal of these session becomes to use the power of conversation to develop a shared understanding across the team implementing.
I find myself regularly coaching on these specific sessions — so let’s explore them more deeply in the context of Scrum and Agile delivery as a whole.
So what do the Agile teachings tell us?
Well — like many things we use and talk about in the Agile world, the Scrum Guide itself doesn’t actually make reference to Inception, Kick-off, or any sort of specific ceremony for establishing a shared understanding.
It’s not until we see those writings that expanded on the original Scrum Guide, such as Ken Rubin’s ‘Essential Scrum’ that we start seeing the concept of “Backlog Grooming” and a specific event developed to talk about and prepared upcoming items in the product backlog.²
Yet as we dig deeper into this space, we start seeing a huge range of teachings in the space of needs analysis, capture, and ideation to facilitate understanding the what and the why behind a need.
The two I tend to coach on the most are the Lean Business Case from SAFe³, and the Inception Deck from James Rasmussen⁴ — but regardless of the format, the purpose remains the same:
To collate a clear picture of the problem space, to help the team understand the what and the why while having an early proposal on how the delivery might look to inform some early estimates, and approach.
It should start the process of deeper discovery, breakdown, and design — not be a ceremony to handover complete up-front requirements, design, and planning to the team
Is it really necessary?
That really depends on the complexity of the new work at hand, and how foreign it is to the team.
The reality is you always have to do some up-front work, and Inception can be that “some”⁴. But when do we really need Inception?
Well, it depends on many things — from the familiarity of the team to the desired outcomes, the size of the desired outcomes, and changes to the desired outcomes or team.
Here’s a simple decision tree to help guide you if you need one?
But wait — there’s nothing above talking about the state of the technical designs and architecture. Surely I’ve overlooked at the importance of this in the decision process?
Well — no.
Technical design and architecture may be important things to consider, but the need for having these up-front should be dictated by the size and complexity of the work.
If we’ve estimated the work as smaller than a Sprint— then we’ve already acknowledged the complexity is low enough that the work likely doesn’t need such artifacts up-front, and they can be generated through other ceremonies.
How to get started?
My favourite place to start is always the Inception Deck⁵ from James Rasmussen. Conveniently — he has the entire chapter on the topic from his book ‘The Agile Samurai’, along with a template for the deck on his blog here.
I’d also recommend ‘The Loop Approach’⁶ if you’re looking something to help define the problem more deeply — where they use tools like the Business Model Canvas, and Impact Mapping to understand the customers and their outcomes more deeply. They’ve published their entire book on the topic for free here at issuu.com
Finally, if you’re in a more bureaucratic environment — you might need to start with the Lean Business Case⁷ from SAFe. Where the others focus on what and why for the development team — the Lean Business Case helps businesses decide if they should invest in unpacking the area further before taking the work to the team for deeper inception.
If you’re not sure what to use from the above — always default to the basic Inception Deck here.
Wrapping it up
Inception shouldn’t be the default for everything coming into a team — instead the team should identify if it really is necessary first, in an effort to avoid over-investment in the up-front definition.
But when it’s right to use — it’s an invaluable tool that brings a deeper and honest discussion of the what and why behind your next piece of work — developing a shared understanding for your team.
References
- Schwaber. K, Sutherland. J (2017), The Scrum Guide, Scrum.org
- Rubin. K (2012), Essential Scrum, Addison-Wesley
- Unknown (2020), Epics, Scaled Agile
- Caroli. P (2017), Lean Inception, martinfowler.com
- Rasmusson. J (2010), The Agile Samurai, Pragmatic Programmers
- During. B, Kleijn. H (2014), Agile Inception — The Loop Approach, issuu.com
- Unknown (2020), Epic, Scaled Agile Framework
