Hacker News new | comments | show | ask | jobs | submit login

So how do you handle any sort of software development planning? Do you just tell the client "It'll be done eventually. I'll let you know when.", or would you accept that reply from your employees?



That's why agile is used: We'll show you what we have at an agreed upon time (1 week, 2 weeks, 6 weeks, whatever) and you can say "that's fine keep going" or "hmmm, we should change direction."


But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?

Estimating is hard, but it's an estimate. Problems usually arise when one gives an estimate of 'X days' and what the manager hears is 'It will take X days, and no longer.'

An estimate will increase in accuracy the more you know, so if you don't feel comfortable giving an estimate, ask the question: "What information do I need to know to give me comfort for an estimate of Y% accuracy" and ask more questions.


> But even with agile, you have to have some kind of idea how long an overall project might take, otherwise how do you even decide if a project is worth starting?

If each iteration is producing sufficient independent business value (e.g., not dependent on subsequent iterations), then you don't have to estimate the size of the "overall project" to determine if it is worth starting. That's actually a key part of the risk mitigation provided by agile/lean methods.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: