richardd wrote: If you are lucky enough to get a feature list, and it doesn't change half-way through, everything will be top priority. If you make the decision for them, you can bet you'll make the wrong one - whatever you choose to treat as low-priority will be the one thing they really, really needed yesterday.

We're in that boat.  We have re-designed and re-wrote an existing product.  We knew that the new app would need to do most everything that the old app did, so everything did have a top priority.  We still needed to break those down into deliverable units so that we could get the pieces in front of the customer for sanity checks.

...and (of course) we heard statements like

• "Your requirements are already done - Just make it like the old app."
• "It's not done until it does everything that the old app does."

Our managers honestly believed that was the correct strategy, but the development team focused on deliverable units, and prioritized the features based on our experience with the customers. 

Our company's founder (who is no longer on this earth) used to say "Just get most of it done, and we'll sweep up the sh**later."  I've used that strategy with much success when porting new systems, because it allows us to remove features that some previous developer thought were "so important" and that no one uses!

SCRUM rocks because it balances procedure with common sense.  It provides a framework to make decisions and take action, but it does neither of those things for you; SCRUM does not replace effective people.

Thanks for writing that article!  Good stuff.

--Scott Fletcher

--Propeller Head