At the beginning of each Execution Cycle, GigsBoard generates an Invoice to the Customer that covers the payment due for the components that are due to be delivered as part of that Cycle.
This enables the Customer to plan their cashflow better, as the payments will be staggered in a clearly planned manner and not needed to be funded upfront.
The Customer is expected to pay the Cycle advance within a committed timeframe as agreed in the Contract.
The Project team will build and submit deliverables to the Customer team against each User Story that is planned for that Cycle. Each User Story may be mapped to one or more deliverables.
The Customer team can review & choose to approve or reject each deliverable that is submitted by the Project team.
The decision of Accept/ Reject will be taken based on the Acceptance criteria defined for each User Story.
If any deliverable is rejected by the Customer team, a Defect will be raised in GigsBoard. The defect will be used to track the deliverable to closure.
If all deliverables associated with a User Story have been accepted by the Customer, then the User can be moved to DONE state.
If any deliverable remains unaccepted at the end of an Execution Cycle, then the corresponding User Story will automatically be pushed to the next Execution Cycle.
On the day after the planned End date of the current Execution Cycle, GigsBoard will analyze the planned User Stories and the User Stories actually accepted & closed by the Customer team, and then calculate the amount due to the Project team on pro-rated basis.
This calculation is used to perform the settlement to the Project team at the end of each Cycle.
If any deliverable has an associated open defect, then the corresponding User Story will automatically be pushed to the next Execution Cycle. The Project team’s payment corresponding to this User Story will be retained in GigsBoard, and will be released to the Project team only after the defect has been closed.
At this point, GigsBoard will also initiate a 360-degree feedback mechanism, to collect automated or semi-automated feedback on all the Users on the project.
