BBC #04 - Scoping (Part III) How it actually is

If you've been reading this newsletter, you probably noticed that scoping is a pretty hard part of the project.

If you haven't, check it out:

1. Part 1 - An Analogy
2. Part II - What not to do

To make your life easier, I brought two real examples.

In the first one, Hammad Khan explains how he scopes his projects for his No Code agency Posybl .

Then, I will tell you how Lucas Piccoli Weinmann has been successfully scoping projects for Design, Webflow, and Custom Code projects.

I tried to make both as simple as possible.

Hammad - Posybl

According to Hammad, the scoping process takes, on average, between 4 and 7 days.

During this period, he and his client talk about timeline, budget, and a set of features for the project.

With this information, he can plan a strategy and estimate the resources needed for it.

Hammad's scoping process is based on two documents:

1. User stories/feature flowchart
2. Frontend Data Spreadsheet

The User Stories/Feature flowchart is done using Miro and it's a sequence of boxes showing exactly the steps the user should take to complete one action.

These flowcharts:

• Helps the clients visualize every step the user needs to take to complete the actions.
• Helps them make sure they are in sync with the project vision.

In this stage, the client should add/remove anything that (s)he might think it's necessary.

The Frontend Data Spreadsheet is a Google sheet with possible Tables and Fields that will be needed by the user on the screens.

The spreadsheets:

• Gives the clients an easy way to check if the frontend screens have every data the user needs to fulfill the action.
• Holds possible values for the dropdowns and other fields.

With these two simple, but complete, documents, the design team has everything they need to design the app.

They know:

• The steps the user will take
• What fields are necessary for it
• Where to place them
• Possible values for them

Easy, right? Let's take a look at how Lucas approaches this.

Lucas Piccoli

The average scoping time for Lucas is 1 week.

But he has a slightly different process.

Lucas makes sure the clients understand that the scoping process is:

• Collaborative: both of them will contribute to it
• Creative: there are many gaps to be filled
• Speculative: nothing is "for sure"

As a Designer, Lucas approaches the scoping process like what we know as a "Product Discovery" process. With the following steps:

1. Define clear goals for the project
2. Define Personas and User Flows
3. Hand sketching with the client

The definition of goals gives them a clear vision of what they should include in the project and, mainly, what they should not include.

For all steps, Lucas and the client work together on one (or more) call(s) to define the Goals, Personas, and User Flows.

The "hack" according to Lucas is that he sketched some screens on paper and show to the client to get his feedback right on that call.

"By doing this, the client has a strong feeling of collaboration. And, from my experience, this makes our relationship stronger."

Conclusion

There is no right or wrong when scoping a project.

There is only what fits you.

Both approaches described here have similarities and differences.

But one thing I noticed is that both of them mentioned communication as an essential part of a good relationship with a client.

In a nutshell, a good scope process needs:

• A set of features/user flows/goals
• Clear boundaries (what will not be implemented)
• A good and honest relationship between stakeholders and developers

As long as client and agency/freelancer know they are together on the same journey, it doesn't really matter what approach you choose.