How to Scope an App Development Project

An app brief becomes easier to estimate when it explains what people need to accomplish. “A customer app with accounts and notifications” leaves important questions unanswered. Who is the customer, what task are they completing and what result should the business receive?

Bring the current spreadsheet, form or approval steps to the scope discussion, alongside a short explanation of what needs to improve. Remove private information from any examples you share. We can then work through where a request starts, who makes the next decision and how everyone knows the task is finished. A manual step may contain a business rule that needs to survive the move into an app.

Choose the journeys required for the first release and describe them from beginning to end. Include the ordinary path and meaningful exceptions. An approval journey, for example, needs to explain rejection, revision and cancellation as well as acceptance.

A practical journey record includes:

• The person and the task they want to complete.
• The information available at the start.
• The decisions and system responses along the way.
• The information stored or sent to another service.
• The final state and the acceptance conditions.

Walk through the journey with the people who currently do the work. Ask them to follow a request from its starting information to its final state, including any handoff to another person. Screens help explain that sequence, but the review needs to show that the request reaches the agreed result.

Choose the smallest set of behaviours that lets someone finish a useful task safely. In the service-request example, submission, review and a visible outcome belong together if those are the agreed steps. Extra notifications can be considered separately, but removing the review outcome would leave the customer unable to tell what happened. Write down both the included behaviour and the ideas left for later so everyone reviews the same release.

Use prototypes or technical investigations where uncertainty is high. The output of discovery may be a refined scope, a tested integration assumption or a decision not to build a proposed feature. Reducing uncertainty is useful work when it changes the next investment decision.

Consider an illustrative service-request application. A customer submits a request, an operator reviews it and an administrator manages permitted users. A feature list might name forms, accounts and notifications, but still leave ownership and acceptance unclear.

A useful draft story might read: “A customer submits the required request details. An operator can review the submitted request, approve it or return it with a reason. The customer can see the outcome for their own request.” This gives the team a sequence to discuss without choosing a technology. It also exposes a question: when the operator returns a request, can the customer amend and resubmit it? Settle that behaviour before treating the story as ready to estimate.

Now walk through the exceptions. Missing information needs a response that lets the customer correct it. An unauthorised person must not gain access to someone else’s request. If another system is unavailable, agree what the app displays, whether the request remains saved and who takes the next action. The business owner needs to approve those outcomes; they should not emerge by accident during implementation.

Keep each story together with its starting information, permitted actions, result, dependencies and the person who will approve it. That makes it easier to review a proposed addition. If a notification is requested, ask who receives it and what they should do next. A message telling an operator to review a request has a clear place in the workflow; a message with no next action needs a clearer purpose.

Before estimating, ask which uncertainties could change the architecture or delivery plan. A controlled prototype or discovery task may be needed for an integration or unusual operating condition. The output should answer a specific question and identify what remains untested.

This illustrative story does not prescribe a technology or predict a project duration. At acceptance, ask the intended users to perform the agreed tasks in an appropriate environment. For this example, follow one request through approval and another through return and correction, if resubmission is included. Check the customer’s view as well as the operator’s. Keep failures against the approved story separate from requests for new behaviour, so the team can see what needs fixing and what needs a further scope decision.