Invoice / Bill

i have worked in instances where we contracted a series of Sprints say 3 to get started and then add Sprints to the agreement as time went on... We have a webinar on this subject here.

What are all the methods in which a customer is billed when you develop a project for them using the Scrum framework?

In general, my advice would be not to encourage such foolishness. Value is found and made transparent through usable product increments, not in project development.

The maximum leap of faith anyone should be expected to take before receiving value is a Sprint. If there's a "project" to bill for I'd suggest that the Sprint ought to be it.

Since Scrum (and the agile methods in general) are best suited for cases where the full scope of the project is not known up-front or the requirements may change and evolve as more is learned, a cost-plus, time and materials, or indefinite-delivery/indefinite-quantity is best suited. I'd also suggest that the duration of the contract should give the team a certain number of full Sprints. Minimally, the team would know if the upcoming Sprint would be the last Sprint on the contract, since negotiations would likely be underway and even completed (one way or the other) prior to planning their last Sprint.

Exactly how you end up billing within each of the contract types varies based on the agreements between the acquirer (the organization receiving the product) and the supplier (the organization building the product). I'm not sure that there are any hard rules for how frequently to bill within a contract - there could be anything from payment per delivery to regular payments per unit of time to a single payment at the end. Scrum has nothing to say on this matter, but your legal and finance teams that create the agreement between the organizations involved can use the type of contract to decide on an appropriate time for payments.

Fixed capacity ! Bill for each associate in Scrum team you provide and let the customer drive the sprints. I don't see any other method is works well for both customer and vendor. Time based or output based billings may favour the vendor but not the customer.

First consideration:

Scrum is for developing a product.

Are you a Product organisation, or a Services organisation?

If you're a Product organisation, sell working product to customers. Let your product owner work with your customers to define product backlog items to develop a better product to sell more of.

If you're a services organisation: What Thomas said.