Some teams actually work without acceptance tests, instead relying on the programmers' testing to make sure the system works. This might seem like a good way to go, and perhaps it is. However, there are two things to be concerned about. First, with little testing before release, the chance for mistakes goes up. If defects in the released product are a problem, doing no acceptance tests is not a good way to save.
Wrong answers tend to make the real users unhappy, and can often cost the company big money.
Proceed without tests at your own risk. Until you get the rhythm of it, it can be difficult to provide acceptance tests as part of the iteration that implements the feature. A test that finds a defect in a subsequent iteration will require you to schedule a fix, taking time from what you really wanted to do in that iteration. And the fix will take longer, because the programmer isn't as fresh on the code as when he was actually working on it. Sometimes the fix can be a big problem, because it will point out that the programmer didn't understand the feature and has made seriously incorrect assumptions.