Guide: Scoping Features - dsriseah/ursys GitHub Wiki

These are Sri's recommended considerations for scoping any feature- or project-level task. The main goal is to capture all the concerns prior to writing a more detailed technical plan and contract. It is the precursor to performing any billed discovery work as well, since unknowns are revealed in this process.

• Describe - in your own words, get the idea off your chest in any way that works for you.

After describing what you want to see, it's helpful to provide the following supporting insights to help us understand it more fully. I use this matrix of initial questions to extract the detail I need.

• Intention — the immediate actions that you want to see happen.
• Motivation — the reason you want this to happen, such as a benefit or quality of life change.
• Expectation — what you expect to result when the task is completed and how it's gonna be used.
• Urgency - why you want this task right now instead of later.

When conducting the audit, I don't use the prompts as is but use them to make sure I get all the needed reasoning.

After that, I ask about the more quantitative requirements:

• Dependencies - who else is dependent on this work, and who are we dependent on?
• Stakeholders - who else has a vested interested or review authority?
• Risks - what things could go wrong, or are worried about?
• Success metrics - what is considered a passing grade?

Lastly, figuring out what we have to work with. These are estimates to get the client thinking about the production calendar and their own readiness to start.

• Resources - what resources are needed, and who will provide them?
• Dates & Deliverables - what concrete deliverables will be provided by when
• Budget - how much money is available for what?

With this all gathered, we are in a good place to strategize our solution that meets your needs on your terms within known constraints.

For a project consisting of multiple requirements, it takes about 30 minutes from first question to summary. It takes another 30 minutes to summarize it into a brief afterwards that is shared immediate with the prospective client while this is fresh in everyone's head. This is assuming face-to-face between the practitioner and the prospective client in a 1 to 1 setting; more people will lengthen the time, but you can ensure that all your questions are addressed.

The process can go much faster for a task that exists within a project scope, because you already have a brief that outlines the expectations and outcomes for context. In this case, you use the project-level brief to confirm that what you're doing is meeting the needs and are within requirements.

The brief is the collection of constraints, used to guide work. How much additional planning you need is dependent on the scale of that work.

PROJECT LEVEL

You can now write more detailed planning documents, noting uncertainties and scheduling possibilities. When applied to a smaller context like implementing a code feature, From this you can derive a scope of work or contract. In terms of development, you can start writing code

CODE FEATURE LEVEL

You can proceed to design, code, document as you go, referring to the feature-level brief as needed.