It Requires Discipline to Keep Inception Short

The Disciplined Agile Delivery (DAD) process framework includes an explicit Inception phase – sometimes called a project initiation phase, startup phase, or iteration/sprint zero – which is conducted before actually starting to build a solution.  The goals of this phase include: clarifying the business problem that needs to be solved; identifying a viable technical solution; planning your approach; setting up your work environment and team; and gaining stakeholder concurrence that it makes sense to proceed with investing in the implementation of the chosen strategy.  These goals are listed in the following diagram.

Inception goals

Form Initial Team Develop Common Vision Align With Enterprise Direction Explore Initial Scope Identify Initial Technical Strategy Develop Initial Release Plan Secure Funding Form Work Environment Identify Risks

In the Disciplined Agile Delivery book we devoted a lot space to describing how to effectively initiate a DAD project.  Unfortunately in our experience we have seen many organizations that are still new to agile treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications.  Some people have referred to the practice of doing too much temporary documentation up front on an agile project as Water-Scrum-Fall.  We cannot stress enough that this is NOT the intent of the Inception phase.  While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to this phase and strive to reach the stakeholder consensus milestone as quickly as possible.

According to the 2013 Agile Project Initiation survey the average agile team invests about 4 weeks performing project initiation activities, including initial requirements envisioning, initial architecture envisioning, forming the team, initial release planning, and so on.  Of course this is just an average, some respondents reported investing less than a week to do so and some reporting investing more than two months – the amount of time required varies depending on the complexity of the effort, your stakeholders’ understanding of their requirements, your team’s understanding of the solution architecture, whether this is a new solution or merely a new release of an existing solution, and many others.

If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach.  It takes discipline to be aware of this trap and to streamline your approach as much as possible.  You can do this in several ways:

  1. Recognize that the goal is to get going in the right direction.  For any project or product of reasonable complexity you want to spend a bit of time up front ensuring that you understand the problem and have what you believe to be a viable strategy to addressing that problem.  This doesn’t imply that you need a comprehensive requirements specification, a detailed project plan, nor a comprehensive architecture model but it does mean you need to do a bit of initial thinking and organizing.  In a small handful of cases, typically at scale, you may find that your team does require detailed models and plans but this is a very uncommon exception (regardless of what traditional THEORY may claim).
  2. Educate people that details can safely come later.  If you have the ability to plan or model something in detail today, won’t you also have that same ability a few months from now when you actually need those details?  Of course you do.   In lean software development they recommend deferring decisions – including planning decisions,  detailed design decisions, and even requirements – until the most appropriate moment.  The observation is that by waiting you can make a better decision because you have better information at hand.  This strategy of course assumes that you’re able to overcome basic logistical problems such as having the appropriate people available at the time to help explore an issue, provide requisite information, and make the decision.   It’s far less risky, and far less expensive, in most cases to address basic logistical issues than it is to apply the process band-aid of writing detailed documentation at the beginning of a project.
  3. Promote a sense of urgency.  This is the most important thing that you can do.  Just as there is risk associated with not sufficiently thinking about your strategy for approaching a new project or product there are also risks associated with doing too much up front work.  My experience is that far too many IT professionals are complacent regarding the risks associated with the project initiation activities of the Inception phase.   The longer you put off building a consumable solution the greater the risk that you’re building the wrong thing.
  4. Keep your modeling efforts as light as possible.  You very likely need to do some initial requirements envisioning and architecture envisioning early in the project lifecycle to help you think through what you’re doing.  But in most cases this modeling should be high level and light, not detailed and heavy.  In every project I’ve ever been involved with the team has been asked to identify what they’re going to deliver (at least giving a rough sense of the scope) and how they’re going to do it (at least providing a rough idea of the technical strategy) to secure funding for construction.  In short, they need to do a bit of up front thinking.  You will often find that you need to reign-in some of your staff who are experienced with traditional approaches to modeling and specification.  These people have a lot of value to add to your project, modeling is an important skill needed on disciplined agile teams, but they may need help keeping their approach light-weight and incremental.   The details can come later.  See the process goals Identify Scope and Identify Technical Strategy for more thoughts on this subject.
  5. Keep your planning efforts as light as possible.  Similarly you need to invest some time in high-level release planning to answer basic questions such as how long do you believe (roughly) it will take to get a release of your solution deployed and how much (roughly) this will cost.  Planning details can come throughout the Construction phase when it’s more appropriate to invest in such decisions.

I think that it’s very clear that the secret to keeping Inception short is to have the discipline to know that you need to invest some time thinking your approach through but that you want to avoid getting bogged down in too many details.  You need the discipline to do some planning but not too much.  You need the discipline to do some modeling but not too much.  You need the discipline to get going in the right direction knowing that the details will come out in time.

Have any Question or Comment?

20 comments on “It Requires Discipline to Keep Inception Short


In the defense and space business this is called “Capabilities Based Planning.” (CBP) This approach “discovers” or elicits what capabilities are needed to fulfill the mission, stated in measures of effectiveness (MoE). This usually results in a Concept of Operations (ConOps) describing the mission and its actions in Scenarios – (1) Fly to Hubble with a robotic service vehicle, dock, and don’t break anything, (2) Change the Wide Field Camera, (3) Connect the umbilical battery to bypass the built in batteries, (4) unlock and land in the pacific and don’t kill any whales – how much does that cost, and when can it be ready to launch? This is an actual conversation at the Broad Area Announcement, NASA, Houston, 2003.

The CBP method was developed by the Australians, adopted by the Canadian Forces, and finally came to the US DoD. It is directly applicable to Enterprise IT especially with ERP systems, since it is easy to get stuck in the quagmire of “needs and requirements” even in an agile world.

CBP allows the program to ask “why do you need this?” “What capability does this thing you want to build support and what measures of effectiveness will be improved or what risk will be reduced, once you get it to work?”

As well, with the Capabilities in hand, in a model of their interactions, trade offs, and impacts directly on the business (or mission) value, there is now a home for all requirements. This prevents scope creep – even in the agile world – since a requirement must support a capabilities.

The foundation for CBP is highly developed in the defense acquisition domain, and is staring to be used in enterprise IT. A good reference paper is “Competing on Capabilities: The New Rules of Corporate Strategy,” George Stalk Jr., Philip Evans, Lawrence E. Shulman, Harvard Business Review, March 1992

The steps in CBP are:
(1) Define Capabilities as Operational Concepts
(2) Define Capabilities with Scenarios or Use Cases
(3) Assess Needs, Costs, and Risks of the Capability Simultaneously
(4) Define Explicit, Balanced, & Feasible Alternatives


Great post about a common mistake … it is very difficult to people to understand that inception is something you must have (otherwise: who created a thing called backlog ?) but you should do it as fast as possible … they don’t do it or they do it in the wrong classic way …
We had the same problem applying RUP: the inception had a goal (understand the problem) but RUP didn’t tell you to write a lot of docs, just to achieve the goal ! It could take from 15 minutes to 3 months …


Great post, Scott – as I mentioned during our brief meet-up I think the motivation behind an Iteration-Zero/Inception “priming” stage is a solid idea and I’ve found it useful in the projects I’ve engaged, especially those that just can’t get started.

In his book, The Scrum Field Guide, Mitch Lacey pitches a similar idea for a “Ranges and Changes” approach to contracting, using a two-week “priming” engagement for a small segment of the anticipated team (and that’s vital) to meet with stakeholders and begin sussing out the details of the proposed solution and building an initial Product Backlog that can be used to forecast a feasibility release plan.

‘Appreciate that you take the time to clarify the intent and how this isn’t BDUF in disguise or an apologia for agile frameworks.


Through this write up you sum up a couple
of the most main views.
Easy to read through and inclusive of interesting insights.

Thanks a lot for posting It Requires Discipline to Keep Inception Short | Disciplined Agile Delivery!


Our group is reviewing the case study in chapter 12 of the DAD book. We have some questions regarding the section on Concluding Inception Phase – This section felt a little light to us around guidance on approval to move forward based on estimates and approval of the business benefits. Do you have any guidance on precision?

We were hoping for some insight on the following. Justification of the business case, Ie; realizing the business benefits, ROI, business value, payback. Today in our organization we need to justify the spend with an approved business case and we base our release plan on delivering features based on benefit and risk. I was wondering if you had an example on this approach. Also we would need to ensure that any specialized resources are sourced and available for us to proceed. Our current governance process to proceed is not as simple as an agreement from a stakeholder which was described in the case study.

It is a challenge but it really takes us time to move from one phase to the next by ensuring we have the right amount of information to proceed to satisfy our governance model.

Any thoughts?


Nancy, you’ve identified some common issues that many organizations still face. Here are some thoughts for you:
1. Early in a project the information that you have isn’t very accurate. Stakeholders will struggle to tell you what they want, this is human nature, and even if they were good at telling you what they want they would change their minds anyway. In addition you may not have a completely clear idea as to how you’re going to approach building/configuring the solution nor will you even have a clear idea as to who will be on your team and how available they are. All of this information is important input into your schedule and estimates. So, because the input is “fuzzy” so is your output. The implication is that at the beginning of a project your time and cost estimates should be given in ranges. These ranges will reflect the uncertainty, or the fuzziness, of the information you have at hand. In the book we cover these sorts of ideas in Chapter 10 and even promote a ranged burndown chart approach for updating the estimates based on improving information.
2. One of the strengths of the DAD framework is that it makes your process-related options explicit. As a result there is in effect an infinite number of ways that you can tailor DAD to reflect the context of the situation that you face. So, the case study reflects only one of many ways to take a DAD-based approach.
3. Calculation of ROI, NPV, the business case, and other issues will also be based on this fuzzy/uncertain information. I find that many organizations want you to invest time in creating these sorts of things, which clearly has a cost associated with doing so, yet rarely do they track after the fact whether you acheived what you originally promised. This is a sign that something is wrong in your governance strategy. I suspect it’s because management inherently knows that the initial ROI… calculations are little better than works of fiction yet are unwilling to realize that there’s little value in spending much time on them.
4. In DAD we clearly promote the idea that you should identify and then mitigate risks, that you should invest a bit of effort in common to a common vision for your effort, that you should invest some time in identifying the initial scope, and other project initiation activities. We also promote the idea that you should invest as little effort as possible in doing so because you will increase project risk by doing too much up front planning.
5. It sounds as if your organization is still suffering a bit from a more traditional mindset. This is a common problem. You need to help your management team understand that what they are requesting increases the cost, schedule, and risk to your project. In Chapters 7-10 we explicitly discuss the advantages (few) and disadvantages (many) of heavy/detailed approaches to requirements, architecture, and planning required to fulfill such requests. In Chapter 20 we describe strategies for governing agile project teams effectively. From the sounds of it your organization is still applying traditional governance strategies, or at least traditional-leaning strategies, and as a result are likely causing harm to the teams that they hope to be helping.
6. To explore the inherent waste in your existing governance process, consider creating value stream maps to explore what is actually occuring.
7. Feel free to contact us via if you’d like some help adopting a disciplined agile approach.


FYI links in Inception Goals image are broken (old hosting).
Hope that helps.


My pleasure. DAD is very inspirational.


[…] Inception. During this phase project initiation activities occur.  Although “phase” tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than a single iteration (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception whereas the most common iteration/sprint length is two weeks).  So in DAD’s Inception phase we do some very lightweight visioning activities to properly frame the project.  It takes discipline to keep Inception short. […]

Leave a Reply to Disciplined Agilists Take a Goal-Driven Approach « Disciplined Agile Delivery Cancel reply

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