0

I am currently working as a Business Engineer/Product owner in a company. We follow agile methodology. I want to discuss the challenges I faced during the Design and Development Process. As a Business Engineer, my job is to work with the requirements provided by stakeholders and transform them into User stories.

The process we follow right now:

Requirements -> User stories -> Acceptance criteria -> UX/UI Designs -> Refinement of User Stories -> Implementation of the requirements

My Questions are as follow:

  1. Should Acceptance criteria be written before the UX/UI Designs?

The issue I face here is that I have to think like a UX/UI designer, who is hard as I don't have a design background. Based on a User Story and its Acceptance criteria, the design team is designing screens, leading to frequent changes in the Acceptance criteria.

It would be helpful if I could get suggestions on the same.

3 Answers 3

3

Based on your description of the process and the question, it seems like you're trying to fit things into a linear flow. That's not usually a good way to set the team up for success.

You should start writing the acceptance criteria alongside the user stories. However, performing the UX/UI design activities may result in modifications to the user stories and/or acceptance criteria. Similarly, refining the user stories may lead to splitting and merging the stories along with asking questions that result in new or changed acceptance criteria. In fact, you may even start asking some questions during implementation, in which you'll want to capture the answers as new stories to defer the work or new acceptance criteria to capture the intended behavior of the system.

Leave your process open to iteration. Don't try to get too many details too early in the process - do just enough work to reduce the risk to let the next activity start, and be open to discovering something new that changes the previous work.

1
  • Hi Thomas, Thank you for your answer. I believe User story is a process (also debatable though), which requires brainstorming and iterations. Your answer gave me a clarity and direction. Thank you once again Mar 23 at 14:57
4

Short Answer

yes

Detailed Answer

Creating a detailed mock-up can be a waste of time if the Product Owner determines the size of effort is too high to include the story in an iteration.

Risky Flow:

  1. Acceptance Criteria written
  2. Mock-up is created Team sizes story
  3. Product Owner determines that the effort of the story doesn't justify its cost.

Outcome: time has been spent creating a mock-up that won't be used.

Lean Flow:

  1. Draft acceptance criteria created
  2. Team roughly sizes story (t-shirt)
  3. Product Owner decides if the rough size is worth the cost of the story
  4. Low-Fidelity Mock-up is created (when justified)
  5. Acceptance criteria could likely be further refined during mockup creation
  6. Team sizes the user story
  7. Product Owner determines if the cost of the story justifies including it in a backlog
1
  • Thank you for your suggestion, Ryan. Mar 23 at 14:57
2

Keep your acceptance criteria independent of the solution. We shouldn’t have to change the specification for small changes in the UI requirements as the intent behind the system behaviour doesn’t change. The acceptance criteria capture the basic requirements associated with a standard feature without being tied too closely to the UI or the solution design. If I include details of what the UI should look like in the acceptance criteria, I’m taking the focus away from what the specification should really be capturing; behaviour of the system. Finally best way to describe UI requirements is through visual communication.

1
  • Thank you for your suggestion, Mish. Definitely a good point here, Acceptance criteria should be independent of the solution. Mar 23 at 14:58

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.