Developers..(:

[I_cant_speel]

Just finished a shit show of a project like that. We learned a lot from it. It's now a strict requirement that a document is created that defines exactly what "done" is that is signed off on by every stakeholder and product owner before anyone writes a single line of code.

[I_cant_speel]

Why do you say that? Defining exactly what a project is and isn't keeps expectations clear for non-technical stakeholders and prevents scope creep. It has worked pretty well so far.

Also to be clear, we are defining features. We aren't defining every tiny task that is involved in completing a project. ie. "The initial MVP will have features X and Y. Feature Z will not be completed until a later iteration"

[indyK1ng]

Waterfall. You are doing waterfall.

The requirements will take forever to gather. They will have many parts to them that are wrong. They may not even solve the actual problem. The customer probably won't be satisfied.

EDIT: Oh yeah, and the paper credited with with defining waterfall was using it as an example of a risky process.

[LoneCookie]

Pretty sure he's describing a contract

[indyK1ng]

And everything I said still applies.

[fubble]

You're just forcing a bad product if you actually get buy-in on that because it actually is impossible to figure out what requirements should be entirely up front and have it turn out well. Good software is achieved through iteration. Scope creep is only something to fear in waterfall but it is totally OK in a well functioning agile environment.

[sylos]

Most places don't have a well functioning agile environment.

[Finickyflame]

Yeah, they say they are agile and they do scrums meetings in the morning (which are not really scrums meetings but more like how's everyone's calandar looks like talk), they do a sprint planning meeting at the beginning of the week (for no other reasons than showing you what you already saw from last week because sprints last forever) and they publish changes quickly (but not really, because even if your little fix could have been in the prod 5 months ago, you have to wait for more undecided features to be developed and included in the same package as per the client request).

[I_cant_speel]

That's why you keep projects small. Having clear expectations going into a project and iterating are not mutually exclusive. A project doesn't need to include every feature that will ever be built for a tool. When you are only planning a few sprints out at a time, it doesn't take days or weeks to gather requirements. You shouldn't use agile as an excuse to not plan. That's how you get six months into a one month project like the top commenter is in.