I've enjoyed a, for lack of a better term, per-sprint billing cycle. It lies somewhere between all of the techniques on the page and has worked the best for my

I've enjoyed a, for lack of a better term, per-sprint billing cycle. It lies somewhere between all of the techniques on the page and has worked the best for my past client base (startups creating MVPs, companies that need relatively stand-alone websites and services). You bill by sprint (2 weeks; expectation of full-time), planning for a set of deliverables with approximate story weight among them. This gives the client something concrete that you're building towards and gives me incentive to actually produce value and not get mired in non-value-producing things like tweaking styles or excessively mulling over long-term architecture and deployment. Also, it has sufficient room for the inevitable adjustment to scope mid-sprint (although I found this was rare; perhaps 1/4 of my sprints experienced this). We'd just estimate the new work that gets introduced and pick off an equally weighted task, no fuss. My clients found the level of certainty reassuring, and the bug flow of deliverables at the sprint pace was very satisfying, especially to clients who are used to project-scale deliverables. I also found it was conducive to producing better overall software. The sprints made us work together to constrain our thinking to the most valuable things to do in that time horizon. For my specific client base, it left us flexibility to adjust to acquisitions, major project-level scope changes, and financial circumstances, which typically only happened at a biweekly sprint pace.