Agile Inception Deck Checklist
Kick off your next project right with this project chartering framework. It is a lightweight set of 10 questions to ask at the start of your next project to get everybody on the same page.
How often should this be used?
Before new project work commences.
Attribution:
Developed from the Agile Warrior blog post by Jonathan Rasmusson.
Library
Categories
Agile Inception Deck
Agile Inception Deck
Why are we here?
You can’t build a great product if you don’t know why you are building it in the first place. Asking why gives you and the team the context you need to make all those smart decisions while executing.
Mission Statement
Elevator Pitch
Example:
For individual construction teams
who need to track road access on the construction site
the Road Closure System (RCS)
is a safety communication tool
that information crews when roads will be closed.
Unlike the current paper based system
our product is web based and can be accessed by all contractors anywhere anytime
For [target customer]
who [statement of need or opportunity]
the [product name]
is a [product category]
that [key benefit, compelling reason to buy]
Unlike [primary competitive alternative]
our product [statement of primary differentiation]
Design a Product Box
Thinking hard about your product from your customer’s point of view is always cool.
- What are the top three reasons people are going to buy this product?
- And if there was one slogan that captured the spirit of this thing, what would it be?
Benefit 1
Benefit 2
Benefit 3
Slogan
Create a NOT List
Saying yes is easy. It’s saying no that is hard.
The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project.
Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow.
Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.
This is really a “big rock” scoping exercise. All you are saying here is: “If we move these big rocks as part of this project we are going to be OK.”
In Scope
Out of Scope
Unresolved
Meet Your Neighbours
Who else does this affect or do we need to interact with?
List of neighbours
Show the Solution
Mud map the architecture upfront.
Minimise ongoing surprises by communicating infrastructure, technologies and design patterns that are intended to be used.
Document all of it!
Ask what keeps us up at night
There are a thousand things that could wrong on our projects. Some we can handle. Others we can’t. This exercise is about making sure we identify the risks that are worth worrying about and not sweat the ones that aren’t.
For example, you can’t do much to prevent the economy collapsing, or your customer getting promoted to VP of Engineering. So don’t sweat it.
Having full-time dedicated team members, however, is something you can manage and is worth fighting for.
This is your chance to call out the craziness before the project begins and fight for what you are going to need to make this project a success. You may not get everything you ask for, but it never hurts to ask.
Stuff we lose sleep over
Size it up
This exercise is about answering the question: is it bigger than a breadbox? We can’t say exactly how many days it’s going to take to do this project up front. But we can say whether it’s a 3-, 6-, or 9-month’er.
To do this exercise you’ll need to do some high-level story planning and estimation. The NOT list will serve you well here. And you will need to come up with some high-level numbers to at least give your stakeholders some idea of how big this thing is and what they are looking at.
The point here isn’t precision. It’s to determine whether this project is even remotely feasible with the resources you’ve got.
Estimated delivery time
Be clear on what is going to give
Scope
Budget
Time
Quality
Ease of use
Show what it is going to take
This exercise is about the two questions burning on every stakeholder’s mind: how long is this going to take and how much is it going to cost?
If this is a pre-sold piece of work, your budget may have already been set. In this case all you need to do is some simple table napkin math to see if this project is feasible given the cards you’ve been dealt.
This is also your chance to show what kind of team it’s going to take to pull this off. Here you can set expectations around team size, skill set, and the mix of cross functional skills necessary to make this happen.
Summary - X People, Y Time for Z Dollars
We help you and your business
Make ChecklistsItemize your repeatable tasks once - perform them many times.
Document ProcessesProvide detailed documentation alongside tasks.
