-1

I have the following example for a user story with acceptance criteria.

I would like to know if I am allowed to describe how the GUI must be changed to support the new feature.

This is my example:

User Story:

  • As forum administrator I will connect persons in groups, so that people can get organized.

Acceptance Criteria:

  1. The creation of a person group happens below a person group pool (person group pool is an object also visually available in the current software system)
  2. The creation happens with a context menu of the persongroup pool. Below the pool one can create new groups.
  3. A person group contains: person group-ID, description, remark

May that be relevant an right acceptance criteria?

Kind Regards, Kai.

Kai Kramhoeft
  • 53
  • 1
  • 1
  • 2
  • Hi Kai, welcome to StackOverflow! This question is actually a bit off-topic for this site's mandate, which is about answering specific *programming* questions. I suggest it be migrated to the [Programmers StackExchange site](http://programmers.stackexchange.com/faq). – Mark Peters Nov 14 '11 at 05:07
  • This question is off-topic because it's not within the scope for this site, as defined in [What topics can I ask about here?](//stackoverflow.com/help/on-topic) Also see: [What types of questions should I avoid asking?](//stackoverflow.com/help/dont-ask) You may be able to ask on [another Stack Exchange site](//stackexchange.com/sites#name), for example [pm.se] or [softwareengineering.se]. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Makyen Oct 03 '17 at 23:51
  • 3
    I'm voting to close this question as off-topic because it's not about programming. – TylerH Nov 02 '17 at 13:41
  • As a comment on your question, it is not clear to me how the "requirement" (the user story) connects to the verification criteria. The verification describes the process, not the outcome. I would say you have a problem of under-specification in the requirement and over-specification in the verification. I do agree that the question is on-topic. However, it is not clear to me exactly what you are asking. – theMayer Nov 02 '17 at 17:08

3 Answers3

3

Well, whether or not this question gets migrated I figured I'd leave my opinion.

The Acceptance Criteria are chosen by the Product Owner, plain and simple. It's a way of formalizing what the Product Owner will need to see to be able to sign of on a story as being "complete."

How much detail the PO wants to put into that is therefore a product of the PO's work style, knowledge, etc. Many POs have UX training and would like to go so far as to define what it should look like. I think that's fine, as long as it works for your team. Others are mainly customer experts and leave the design up to the team.

Personally, I would encourage teams to formalize as much as can be thought of when looking at the story so that you minimize the number of conflicting assumptions between the team and PO.

However, in the end it's up to the team whether to accept a story into their sprint. They have every right (in Scrum, anyway) to say that the ACs are overly broad, overly prescriptive, infeasible, or too large to chew off in one sprint. Therefore, there is usually a lot of negotiation that happens between the team and the PO before agreeing on the ACs for each story.

But in the end, it's the Product Owner's call since she's the one who will be doing the "accepting." In general, Scrum says that it's the Product Owner's job to say what to build, and the team's job to say how to build it (and to actually do it). So really it's about what type of PO you want to be.

Mark Peters
  • 80,126
  • 17
  • 159
  • 190
0

You may want to add acceptance tests to your user stories. My question may give you some perspective on how others approach user story specification.

I would describe the how the user interacts with the UI(ie UX) in the appropriate acceptance test, not the acceptance criteria. The criteria is better suited for input validation and other business rules that don't need to be covered in the higher level acceptance tests.

Community
  • 1
  • 1
Brenden
  • 7,708
  • 11
  • 61
  • 75
0

In my experience, Mark's answer is on the money about the suitability of the ACs listed by OP. However, though those criteria are acceptable, I suggest that they are insufficient to reduce ambiguity as to what the PO expects the product to do when the story is presented for acceptance.

In addition to the listed ACs which describe how the story will be implemented, I would expect to see ACs that describe what the product will do. For example, are those groups visible to forum users as well as the administrator? How do you define "connect"? What are the details of the business logic tying users and groups? Does the story cover both the "mapping" and "unmapping" of users to groups, or were they separated to keep the story within a sprintable size?

JP Beaudry
  • 194
  • 5