0

I recently found myself debating about the usefulness of acceptance criteria in a user story. Bear in mind that the team in question is not a feature team, it is a technical component team (if that changes things).

The team members have been writing a page or two with things that they will build; not so much of a spec document, as a definition doc of what needs to be done. In there, it's quite clear what the scope of the story is. So in effect, the verdict was that there was no need to worry about acceptance criteria (in the Jira ticket for example).

This seems to be working with the team, as there was no ambiguity on implementation (and if there is any, the team will discussing amongst themselves), so I am puzzled about what would the acceptance criteria add to this user story, and whether it is worth enforcing that.

2
  • Who are YOUR team's customers for the work that you are doing? - It may not be the end business users, but it has to be someone, otherwise there would be no point in you doing the work. So, having defined the customers, you should be able to ask what THEY would be required to accept. Does that help clarify? – Iain9688 Jan 30 at 14:10
  • The customers are other internal teams. Again, because this is quite low level, and the design spec has been written to satisfy what these teams will need. – dqm Jan 31 at 16:16
3

You can of course use a design or requirement document as the basis of your acceptance criteria. No need to record that information again on a story if you already have it. However, change control can be difficult with documents. If your backlog changes and you create new stories then you may want to hold on to the previous versions of your documents. It can be difficult for multiple people to edit the same document simultaneously while maintaining clarity about which version is relevant to a given story. For these reasons many people resort to documents only when they have to and otherwise rely on stories as the preferred place to put acceptance criteria.

1
  • It's a shared doc in Confluence so I don't think we'll face such issues. – dqm Jan 29 at 19:18
3

There's no one form for acceptance criteria. If your document describes what needs to be done in sufficient detail to write tests against, then that document is your acceptance criteria.

Keep in mind that a story has three parts - card, conversation, and confirmation. The card is a way to remind the team about the work. The conversation (and any required notes or details that come out of those conversations) help the team to work toward a solution. The confirmation is how you make sure that the work is done, often through automated tests. There are different ways to capture what you need to test from the associated conversations.

0
1

Acceptance criteria is what the acceptance tests (on customer side!) are carried out against. It may but does not have to be 100% conformity to requirements. It should not be more (because that would imply the requirements were not complete), but could be a subset of requirements, especially for gradual development.

Acceptance criteria are set by the customer, since based on the result of acceptance test they either accept or reject the deliverable. Therefore:

  1. project should be well aware of those;
  2. if they are not provided, the project should actively find out what they are, otherwise it creates a project risk.
1
  • Ok, since this is a component team and we don't have customer involvement directly (the PO and team has the agenda of what needs to be done), I don't think we need them altogether. Acceptance tests are produced and run by the team. – dqm Jan 29 at 11:27
0

To echo the above ... "Acceptance Criteria" represents what The Business(!) will accept!"

You, "sitting down there in your code-development dungeon," fully understand the intricacies of the source-code that you are developing. But, the business does not – and need not – "and that's the point."

Instead, they spell out their "acceptance criteria." (And, be very grateful that they did.) Because your source-code, when finally delivered to them, will be "a tool in their hands." It has to actually enable them to do their jobs. (Not yours.) You've got to be absolutely sure that the software which you finally deliver to them fully satisfies them on all of these business(!) points. Otherwise, you haven't done your job at all.

2
  • Good angle, but the doc in question would explain in quite simple terms, high and mid level what the software needs to do. – dqm Jan 29 at 19:20
  • I think that the key point in the OP is ... "discussing among themselves." – Mike Robinson Feb 1 at 19:40
0

You should bear in mind that the acceptance may be a combination of functional and non-functional criteria - ie both "what" the solution delivers, and "how" it delivers it - which could be performance, capacity, reliability, maintainability, and so on. These should all be captured. If they are all in the deign spec, then you may not need separate acceptance criteria (as per your original question).

If these are not specified, then I would suggest that you create an acceptance document, to avoid arguments along the line of "You never said it would have to cope with 20,000 simultaneous users!", or "I thought it would be obvious that the system should keep running through hardware upgrades." Or even "Why did you build it with so much spare capacity? It's never going to need to handle more than 10,000 entries in the database!"

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.