What is the best way to handle changes to product requirements or scope during or after User Acceptance Testing (UAT)? How dangerous is it to make those changes, and how can the danger be mitigated?

  • 2
    When you build a house, and you're almost finished, adding an extra powersocket requires you to break walls, redo the plaster and probably some more things. People understand that. Why won't they understand that changing software is often the same thing.
    – Pieter B
    Jul 27 '12 at 17:23
  • 2
    @PieterB - because they can't see the dust. Jul 27 '12 at 17:40
  • 2
    Nice rant... asking for a list of resources does not constitute an actual question for this site. If you have a legitimate question about the effects of last minute scope changes on a project then please post back.
    – maple_shaft
    Jul 27 '12 at 17:53
  • I guess I should have been more clear. Sometimes having articles or numbers to quantify this helps people understand what seems to be common sense. Even if you get them to agree to another QA and UAT cycle, experience tells me that the testing teams rush through it because they are already frustrated and just want to get this over with. There must be some study on this.
    – HackITMngr
    Jul 27 '12 at 23:56
  • @HackITMngr - I'm unclear on whether it's considered on-topic for the site to ask for references. I believe in general you have to simply ask the question directly, so I edited accordingly to get the question re-opened. I'm fairly sure it's O.K. to add something saying you would appreciate scientific studies, and you could edit again to add that. Though most people will probably read your comment anyway.
    – psr
    Jul 28 '12 at 0:08

The scope can be changed at anytime, provided those changing accept the required changes to budget and schedule. You can't stop people from continually trying to change the scope until they realize it costs money, providing a few estimates of the cost for requested changes from higher-ups will help them make that connection. Doing this is unlikely to stop them from requesting changes, but it is likely to stop them from complaining when you deny those changes, and will help you identify the changes you need to make when they understand the cost of that change.


I think the best way to deal with these change requests is to present a revised schedule including the change. And if it's after UAT, then the new schedule includes a second run through UAT.

When they go 'but we don't need that' you can ask why not? Doesn't the product need to be accepted by the user? If they haven't seen it, they can't accept it, right?

  • I totally agree. Think 'backbone'.
    – tzerb
    Jul 27 '12 at 17:16
  • +1 for "Doesn't the product need to be accepted by the user? If they haven't seen it, they can't accept it, right?" Jul 27 '12 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.