How do you handle the specification, acceptance and measurement of the web apps you build?
For example, if the user story states that there should be a password and confirm password field but validation isn't discussed, it is within or outside of the quoted scope to ensure that the password and confirm password field matches?
What about an application which must check inventory level where the developer assumed this was a field in the product database and in fact it requires integration to a complex third party system?
What about a client having "assumed" that inventory would be on a per warehouse basis and explaining that without that the project is unusable and they are out of budget for changes? If the fact that they had more than one warehouse was never mentioned, this can cause a problem.
On our part, while we might try to take care of the password/confirmation password issue, we make it very clear that unless something is written down as part of a user story, it is not included within the project. The fact is that we can't provide a fair fixed bid for features that will meet a clients business needs as we have no idea what kind of dark matter might be lurking. We do our best to poke around in the discovery time available, but all that we commit to within a fixed bid is creating working software that implements the explicitly documented elements of the user story.
The problem of course is that this often doesn't meet the clients needs which is not good for either of us - which is why we're looking to move towards a blended approach.
Any other tips anyone would like to share?
