Explore Initial Scope

This Inception process goal describes how we will elicit and capture the initial requirements for our solution. We want to do just enough work to understand what our stakeholders want so that we can confidently begin Construction. To be effective, we need to consider several important questions:

  • What level of detail do we need to capture?
  • How will we explore the ways that people will potentially use the solution?
  • How will we explore domain concepts, the business process(es) to be supported by the solution, UI requirements, and general requirements?
  • How will we capture non-functional requirements?
  • How will we approach modeling activities?
  • How will changing requirements be managed throughout Construction?

Explore Initial Scope

Most of the strategies/practices referenced in the goal diagram above are described, including the tradeoffs involved and considerations for when (not) to apply them, in the book Disciplined Agile Delivery (DAD): A Practitioners Guide to Agile Software Delivery in the Enterprise.

Further Reading

3 thoughts on “Explore Initial Scope

  1. Ashish Pathak

    One of the problem that I face is that, after the initial Inception phase, the customer is looking for a “Final Delivery Date”. I do have enough information start work but not enough information to commit to a particular date; which I know will not change, once I commit. The customer doesn’t buy in the progressive elaboration story. How can this be dealt with, with the customer. Asking for more time/information is treated as an excuse and aspersions are cast over the teams ability to deliver.

  2. scottwambler

    This is a fairly common challenge. There are several aspects of the solution:
    1. Communicate time and schedule estimates in ranges. These ranges must reflect the uncertainty of the requirements. Early in a project the requirements are often vague/high-level and will evolve as your stakeholders learn as the project progresses, so early in the lifecycle the ranges must be fairly large. As your understanding of the problem, and solution, improves you can tighten up the ranges.
    2. Update the estimates as time goes on.
    3. Educate your stakeholders. Many stakeholders do not understand the realities of software development and as a result their expectations may be unrealistic. Usually when I run into situations like this I ask fairly pointed questions such as “How well has this worked out for you in the past?” and “What actually happened last year on project X?” I do this because they’ve likely seen a string of IT projects where the estimates clearly evolved over time. Then we discuss why this is the case and often discuss better ways of working. In short, lead them to the solution (in this case evolving ranged estimates) don’t just jump straight to it.

  3. Ashish Pathak

    Thanks Scott! BTW…It will be great if you can add such cases as well in both your book and on these pages as well 🙂


Leave a Reply

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