Agile Project Inception Planning – The “Think It” Stage…

The goal of the Agile project inception stage is to:

  • Bring clarity to what it is that might be built, who to build it for, and why
  • Drive down risk in a very cost-effective way – by prototyping and experimenting
  • Fail fast, cheap and safe (if in fact we’re going to fail)

The deliverables are:

  • Working draft of a Customer Experience Canvas (Product/Project definition)
  • Prototype(s) that provides “just enough” to be able to “see” if the idea is actually worth building (or will never be worth building and should be abandoned)

High Level Process Map

  1. agile project inception planningAssemble a cross-functional team
  2. Build the hypothesis of “why this product?” by answering the “Four Questions”
    • Who do we plan to serve with this product?
    • What do they need and want most? What matters to them?
    • What do we do—better than anyone else—to meet those needs and wants?
    • What is the best way for us to deliver this product/service?
  3. Create a billboard (Yep, like the ones on I95) for this product—this is the core message and value proposition of the product. The story we are going to tell the world when/if we actually “Ship It”
  4. Write decision filters (details below) for the product—you will use these to filter every and all decisions about product features and priorities
  5. Build out a canvas of the customer experience (more details below)
  6. Identify the features that deliver the minimum viable product (MVP)
  7. Write and prioritize features for the next release (post MVP iteration)
  8. Discuss the required tasks and roles and ask the team which product development elements they will own
  9. Agree on the process for making decisions and how decisions will be communicated—both to the team and to the stakeholders. (See Decision Making)
  10. Agree as to how the team will hold each other accountable (See Expectations Exercise)
  11. If there were any issues that could not be resolved in the initial planning session, list them as action items and let team members volunteer to define and deliver a plan that resolves those issues
  12. Build high-level wireframes, storyboards, or prototypes (lo-fi or hi-fi)

Decision Filters / Alignment for Agile Project Inception Planning

Many decisions are based on individual views and assumptions between choices. A few examples:

  • What is most valuable: security or easiness of usage?
  • What about scalability and security?
  • And scalability and easiness of usage?

Business Value Metrics

We don’t want to ignore costs, benefits, or any other driver of value just because we cannot readily quantify it, and so the Business Value Metrics  (BVM) attempts to take these considerations into account. These could be the drivers or inhibitors of value. Depending on the process, project, or activity, considerations might include:

  • Time to benefit
  • Market window
  • Alignment to goals
  • Compliance
  • Market uncertainty
  • Technical uncertainty
  • Technical complexity
  • Market complexity
  • Internal capability
  • Partner capability

Trade-off Sliders Activity

trade offs and decsion makingThe Trade-Off Activity fosters an open conversation based on a visible and collaborative canvas. And making trade-offs very clear upfront will reduce future disagreements and will hasten decisions.

  1. Run a divergent list creation exercise where folks write down the ideas, topics, or categories under comparison on post-its. Collect them and converge the notes, eliminating duplicates, into clearly defined topics.
  2. Place these topics on the canvas on the left axis then draw a horizontal line for each.
  3. Draw vertical lines (same number as horizontal lines). Write “highest” on top of the left-most line and “lowest” on top of the right-most line.
  4. Ask the team to mark their initials on as many post-its as there are topics and place one per row. The constraint: each priority column may have only one post-it with their initials (e.g. only one of the categories will be marked on the highest column line).
  5. Trade-offs equalization: with a different post-it color (orange post-it on the photo to the right), decide as a group how each topic relates to each other. This conversation should be interesting as agreements and disagreements will be very visible on the canvas – either by clumps or distributions 🙂

The Experience Canvas – A Framework for MVP

The Experience Canvas is a framework for teams work thru the the details what encompasses MVP. It helps ensure “The Idea” is thought through, user-centered and lean, without compromising on flexibility.

Put simply, the Experience Canvas is a vehicle for getting the strategy right at the start. It’s inspired by Alex Osterwalder’s Business Model Canvas, and also borrows from Spark59s Lean Canvas, which is itself a version of the Business Model Canvas optimized for lean startup operations. The Canvas below was developed by Atlassian, makers of JIRA, Confluence, HipChat and many other really cool tools.

A completed canvas is not a requirements specification, and it is not a roadmap. It is more like insurance: it helps the team stay on track to be lean and user-centered. It is also an excellent catalyst for getting everyone on the same page.

experience canvas

A tour around the canvas

The Experience Canvas has the following boxes:

  • Hypothesis – This is where it should all start: We think that […] will have the following effect […]
  • Problem – What triggered the hypothesis? What is it that we’re trying to solve for customers? This is paradoxically often the hardest box to articulate and agree on, but the most important. It’s also the easiest one for teams to gloss over, so be warned! Maybe elaborate where things stand today, what are the symptoms that you feel requires actions? What are the root cause(s) of the problem. What constrains us? What should change? (see A Framework for Change)
  • Personas – Who will use the solution? Who will benefit from this and how?
  • Stakeholders – Who is genuinely affected by this solution and should have a say (rather than just be informed)?
  • Team – Who is going to deliver this solution? Best to keep it small – and skillful – as possible. Who will do what, when and how?
  • Idea – What are the early thoughts and options to solve the problem? These ideas may be generated separately as a result of a brain storming session, where quantity is the goal. What alternatives could be considered? How will you choose among the options? What are the decision criteria? How do you think these ideas will cause the current situation to change?
  • Value – What is the user benefit and business benefit for your solution? Could this a “step change” (that is, a MVP that we expect will give at least a 2x improvement on the chosen metric)?
  • MVE – What does the smallest, easiest, fastest-to-make testable version of your idea, that you could launch as an experience?
  • End-to-end demo – Tell a story to bring this to life, using anything from role play, sketches, to a low-fidelity or high-fidelity prototype.
  • Test Results – How will you test the experience you’re setting out to provide? What are the indicators of performance and progress? What are the critical few, visual, most natural metrics? How would you anticipate using the results of what you find? How will we know if this is successful? Any failure modes to watch out for? Unintended consequences? What might the ongoing PDCA cycle look like?
  • Title – (Ok, no box… ) Can you, in seven words, communicate what “it’s all about”? (This could be the copy for the “Billboard”…)

The boxes in the canvas are different sizes to indicate how much effort and detail should go into each one. The solution space for example in the canvas (MVE) is quite small compared to the problem space. This is because a lot more work should go into understanding the problem and telling/demonstrating end-to-end scenarios, rather than theorizing about a solution.

How to “fill in the boxes”

There are a variety of ways for a team to bring all of the information together into each box:

  • Facilitated call-and-response on a whiteboard – a facilitator poses each box as a question to the room
  • Post-up activity – each box is tackled by first getting everyone to write their thoughts onto post-it notes, then grouping and refining those post-it notes to generate the main insights to take onto the canvas
  • Small group activities – where groups of up to four brainstorm on each box, especially when it comes to the idea, value and MVP boxes
  • Rotating Flip Charts – Small groups brainstorm on a single box, and then rotate

It is very important that the canvas is explored by the whole team; it is after all a means to an end, not the end itself. It is a catalyst to generate the strategy, not a final deliverable.

Remember, too, that the idea is not to fill it all in for the sake of it. If the team gets stuck on one of the boxes, that’s a good sign that the canvas is doing its job. It can be tempting to focus on getting it all filled in rather than exploring the reasons why there are some parts that can’t be filled in, or are much harder to fill in.


The final leg of this initial “Think It” journey  – #12 Build high-level wire-frames, storyboards, or a prototype (lo-fi / hi-fi) – provides just enough to be able to “see” the potential, the big picture and will help determine if the project is worth taking to the next step: Build the the smallest possible thing that fulfills the basic narrative and that can be released to (and
delight) external users to test the hypotheses, i.e. deliver the MVP itself…

More on that on another day….

Resources / References for Agile Project Inception Planning

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top