Methods for estimating projects

Approaching Project Estimation

A possible approach to estimation post-discovery is shown in the example provided below.  A similar approach can be taken as a good jumping-off point in identifying the solution types, estimating task sizes and prioritising sprints as the project progresses to development.

Solution Type

Depending on the scope of the project, you may define these Possible Values separately, but as a point of reference, the Base solution could be the out-of-the-box solution you get from Fluent Commerce.

Estimation

Estimation again there is the T-shirt size understanding whether it is base or should be minimal effort (0 to 1) days. Small simple configuration ranging from 1 to 2 days. Medium, Large, all the way up to X-Large where it’s a complex custom solution that's gonna need to be designed and can potentially be 20 to 40 days. 

Priority

In addition to identifying the solution type, and T-shirt estimates against each requirement, it is also important to run through the priority. 

The MUST, SHOULD, COULD and Won’t is a good place to start to be able to prioritise the sprints as we move to development.

Estimation by priority

Estimation by priority (Must, Should, Could and Won't) is a good place to start to be able to prioritise the sprints as you progress to development.  In the example below, priority estimates are in days (min, max and total) are placed against features and integrations. Statement of Work (SOW) or project deliverables can be translated into a resource workload to identify the project team requirements from project implementation to launch.