In our Agile/Scrum process, should we have a Customer Acceptance Testing (CAT) stage when the Product Owner looks at what has been developed and acknowledges that it meets all acceptance criteria?
asked Jan 31, 2013 at 18:57
Add a comment
|
2 Answers
TL; DR
User acceptance testing should be done as a separate process outside the sprint whenever possible. It can be incorporated within the sprint, but there are a number of caveats and lots of potential for in-sprint scope creep.
Define "Acceptance Testing"
Acceptance testing means different things in different organizations. In some companies, it means "ensure the widget meets the original specifications." In others, it means someone signs off that the feature works for them, whether or not it does what they want. Yet again, sometimes acceptance testing means that someone reviews the feature to see if they like it.
Scrum Provides Inspection Points
The whole idea of Scrum is that the customers (directly, or via their proxy, the Product Owner) remain engaged throughout the process. In addition, the Sprint Review at the end of every iteration is the chance for stakeholders to see the features demonstrated, and offer feedback about it.
Note that negative feedback in a Sprint Review doesn't mean the sprint failed, or that the user stories weren't completed according to the "definition of done." It simply means that the feature, even if operating as designed or functioning as specified doesn't meet an undocumented (or recently changed) expectation.
Acceptance Testing in the Definition of Done
If the lightweight Sprint Reviews are insufficient for your purposes, you can always bake a user acceptance task into each story as part of its "definition of done." For example, after a feature has passed the sprint's QA step, you may require Joe from accounting to try out each new feature on a staging system before calling it "done."
However, if you make user acceptance testing part of your definition of done, you need to ensure that your story estimates include that effort as well. In addition, you need to decide what acceptance testing should measure; for example, should it measure satisfaction, or simply conformance as defined at the start of the sprint?
You also need to think about what the team's process should be if a story is technically correct, but does not meet a "definition of done" that includes user acceptance testing. If "delighting the user" is part of your definition of done--an unworkable idea that people sometimes try--then best practice would be to treat significant variance in the story as new scope that should go back to the Product Owner to re-prioritize on the Product Backlog.
Embrace Change Without Abandoning Sane Boundaries
Defining the limits of acceptable variance for any user story is a job for the entire Scrum team to explore within the process framework. Just make sure to keep your acceptable variance within sane boundaries, or poor requirements will never stop moving your cheese.
answered Jan 31, 2013 at 21:17
Each story must have (a list of) crystal clear acceptance criteria, at the latest agreed on in the sprint planning.
Then all team members now how to finish the story and a rejection by PO should not come as a surprise. If it were a surprise you should make better acceptance criteria and or ask more questions (also during the sprint) to the team and PO.
NB when you mentions stages, that is very "waterfallish". The agile way is to find simple rules so the team can self organize without stages or formal checks like a described above...
