3 ms·

EBS: Evidence Based Scheduling [1] I've never used EBS myself; only read about it... A client required project estimates, but only gave vague requirements whi

EBS: Evidence Based Scheduling [1] I've never used EBS myself; only read about it... A client required project estimates, but only gave vague requirements which constantly ended up changing anyways. And they always asked me to work on stuff outside the scope of the contract. (Help debug this; add that feature, etc) Also they balked if I ever estimated anything over two weeks. So what we ended up doing: 1. I give my best over-all estimate, but only contracted for two weeks at a time. 2. After two weeks, we'd re-evaluate the situation and repeat. This worked pretty well for us. --- [1]: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Leftium 2y ago
Another thing I observed was building something (at least) twice is a valid development process. 1. The first time, the client hammers out their (often changing) requirements and you get a pretty good understanding of the problem that actually needs to be solved. So the main objective of the first build is actually just gathering the requirements. You also uncover issues that may have been missed just "thinking" about the requirements. 2. The second time almost never takes as long to develop, so the development time to build that first version is a good hard upper-limit. It usually takes significantly less time because development of the second version usually involves copy-pasting a lot of the original code and just refining it.