Agile Inception techniques

Agile project inception techniques

You often hear agencies talk about running ‘agile’ projects which usually ends up being hybrid wagile or planning + iterative development. Lots of agile books dive right in to delivering the project, mid-code and everyone on board. So one thing that interests me a lot is how to run a truly agile project inception. I was lucky enough to attend DeliverConf’s 2017 workshop day in which Delivery Director at Valtech, Kevin Murray, discussed this very topic.

As it turns out, truly agile project inception is actually a lot more similar to waterfall in its aims than you may think. You still need to understand your client’s business, their users, stakeholders and objectives. You still need to find a good digital solution which is feasible and realistic. You still need to gain buy-in, confidence and build the foundations for the project delivery. What was in stark contrast was the amount of collaborative exercises that are done with the team and client as well as the role of the project manager. I’ll explore a few more of these exercises in depth below, but here is a photo of all of the agile inception techniques that Kevin may draw on when starting a project.

Agile Inception techniques

One really interesting thing Kevin mentioned was that running an inception phase with this approach meant it was okay for a client not to have all the answers. Typically in waterfall we ask a client to drive the development of a list of requirements (especially for cost reasons if there’s a tight budget). This puts the assumption and risk onto the client that they must have all the answers immediately and up-front. I’ve seen first hand that this can fill clients with ‘project FOMO’ or make them overly and unnecessarily lofty and abstract in their requests.

So, what agile inception techniques are available to help clients (and teams) who don’t need to know everything right here, right now?

As you guessed from the name sliders are a set of criteria which can be assigned a value (e.g. 1 to 10). Clients can slide the values higher or lower to demonstrate which criteria are fixed, and which are flexible. For example, your client may say that accessibility is absolutely fixed, but security is flexible. Such a site may exist for a marketing site for a charity which supports the deaf-blind. It has high accessibility needs, but as a marketing site doesn’t need Fort Knox security.

An add on from me, would be to set the values between 1 and 10, with 1 the most flexible and 10 the least. Then, times the number of criteria by five (e.g. 10 criteria x5 = 50). The total here gives you a total amount of points which can be assigned amongst all criteria in order to determine the relative flexibility or rigidness.

If you find your stakeholders really struggling with the number of points they can assign it’s a good indication that there are too many fixed elements and that either something needs to change at the stakeholders end, or you should have a conversation about whether agile is the right delivery framework for this project, at this time.

If your clients can assign all of the points and come to relative consensus on them, you have a great understanding of the project’s priorities in order for it to be successful.


Assumption mapping
Assumption mapping allows everyone to have a say about things which either seem really obvious to them, or feel a bit risky because they don’t know the answer. It’s a great technique for when there is a shared and understood idea about what you’d like to do for the delivery phase.

Take a big sheet of paper and draw an intersecting x and y axis. Name one axis Certainty, and one Immediacy. Ask all your stakeholders and team to begin jotting down their assumptions onto post-its. It’s okay if you have loads – that’s the idea! Better to ask the question now than be thwarted by an assumption later down the line.

Once your stakeholders and team have a good list of assumptions ask them to start placing them into the relevant quadrant – certain and immediate, uncertain and immediate, certain but not immediate, uncertain but not immediate.

  • Certain = how sure are we that x is feasible?
  • Immediacy = how urgent is this feature to include in the MVP?

Once you have a finished and well debated map, you can pass it over to your team for technical, user, and business analysis and investigation. The aim is to move everything out of the immediate and uncertain quadrant either by establishing its feasibility or by de-prioritising its immediacy. This will help you generate a first draft of features and stories before committing them to a more formal backlog.

Assumption map

Vision statement
A good tool to sense check thinking and collective understanding of the proposal is the vision statement. Done well, it guides the project, working as a checkpoint for feature proposals, objectives, and product or service aspiration.

Best used once you have completed some initial brainstorming and research, it works simply by following the formula and filling in the blanks:

  1. THE (name of product/service)
  2. FOR (users of product/service)
  3. WHO WANT (key features of the product/service)
  4. THIS SERVICE(S) WILL (sub key features)
  5. UNLIKE (existing/competing product/service)
  6. THIS SERVICE WILL (key differentiation/advantages of product/service)

The idea is to get to a vision statement that everyone agrees sums up the aspiration.

Vision statement

Apart from the above inception techniques one of the things I took from Kevin’s workshop was the level of involvement the UX researchers, business analysts and client stakeholders have in the inception period. As well as the need to have good quality users available at relatively short notice to ‘real-world sense check’ ideas. Additionally, the role of the project manager in this stage was far less about planning and far more about facilitating workshops, conversations and exploration.

You can view Kevin’s full presentation on slideshare.

I’d love to hear about any agile inception techniques that you have used and have found to be really successful.


We Need to Talk – DeliverConf workshop 2017

A huge thank you to DeliverConf 2017 for another fantastic 2 days of workshops and talks.

This year I ran a three hour workshop for 43 delivery professionals from the UK and Europe called “We Need to Talk“. Participants learnt how to handle difficult conversations when running digital projects.

In the three hour interactive session we looked at ways to handle difficult, awkward and down right uncomfortable conversations, with a focus on team performance and project finances.

By the end of the workshop participants had flexed and strengthened their communication skills as well as developing their project leadership capabilities allowing them to handle even the stickiest situations.