16

The acceptance criteria you have listed are really a mixture of stories and tasks. Given your example story: As a user I want to register and log in so that I can register on the application and start using cloud memory I would break that down in to: As a user I want to register so that I can gain access to and start using cloud memory and As a user I ...


7

Why Your "Story" Isn't Testable As a small business owner I want simple and easy instructions to follow for any recommendations to my website so that I understand what it is I need to do and what resources are required. You have two problems here: This is not a user story. This is an epic which needs to be decomposed. This story doesn't follow the ...


6

The concept is valid, which is to seek a result based on a reference. But of course it needs to be broken down into measurable points. For example: the acceptance test will be like: Achieve the same exact effect as in screen x in app y in terms of: 1. Dimming effect hex value is #9999 2. Area affected by dimmed light is 70% of the screen 3. Colorful ...


5

As you are referring to sprints and user stories, I will assume you are using the Scrum framework. Within Scrum, there is no such thing as a partially complete user story. A user story can either be done, in which case all acceptance criteria and the definition-of-done have been fulfilled, or the user story is not done. When, at the end of a sprint, some ...


5

Interesting question. While it really does not matter I believe that linguistically it needs to be present tense. It can never be past tense as it is describing something that has not been done yet. It should not be possible to add the product... The user should be redirected...


5

Scrum is based on an empirical process control system. It assumes that not everything is known and that knowledge will emerge over time. Trying to specify every acceptance criteria in exact detail may not be possible and may take way more time than needed. It's not possible to know all acceptance criteria in advance. Instead, Scrum explains that the ...


4

The acceptance criteria are to verify the new feature is working as expected by the stakeholders. They are better called Business Facing Tests. A business-facing test is a test that's intended to be used as an aid to communicating with the non-programming members of a development team such as customers, users, business analysts and the like The ...


4

In certain situations I think they should, but there are a lot of caveats and gotchas to it. Let me list out reasons I have done it, and also times when I would not do it and maybe that will help as you consider what you need. Before I start I want to echo Sarov though in that if your main reason for doing this is because the PO is not technical then some ...


4

It depends, does it help the team in better using them as requirements and does it improve communication with stakeholders? Then yes. Just discuss with the team which they think gives the most value for the project. GTW adds a bit of extra work. Also it might make it harder to read and understand instead of one liner high level acceptance criteria, since ...


4

It should first be said that there are no hard and fast rules on this. That said, the most successful teams I see operate as you describe. Specifically, the PO creates a backlog item with initial acceptance criteria and shows it to the team in backlog refinement and if needed, they collectively create more. And while the backlog item should be "ready" ...


4

Before We Dive Any Deeper... You don't have a single problem, you have many. Aside from lacking a cross-functional team that fully collaborates, the two biggest process problems appear to be: The entire team isn't involved in planning the iteration (including acceptance criteria and the Definition of Done). The Product Owner thinks she's in charge of "...


3

Usually, we clone the user story and move it to the next sprint for tracking. Don't do that. The story isn't done. If you put it to Done and clone it, your velocity will be messed up. It will look as if you completed work, when you didn't. This will cause you to overestimate in the future, because velocity reports mistakenly show you being able to complete ...


3

Good Acceptance Criteria cannot stand alone. It has to be derived from the requirement description - e.g. User Story. Therefore, a good requirement description is the starting point. However, without knowing the requirement details is hard to say if your example is a good one or not. But anyway, let's take a look at the basics. Acceptance Criteria should ...


3

The Acceptance Criteria is about usability. When a feature meets the acceptance criteria, then for sure it can be used. The acceptance criteria is as clear as black/white. See this video, please: https://www.scrum.org/resources/definition-done-vs-acceptance-criteria Now, anyone can write a User Story and put it in the Product Backlog. Each user story needs ...


3

Yes, ofcourse, why should the development team settle for second hand information. Self-organizing teams should get the information from the source! I really like this item from the Cargo Cult Agile Checklist: Stakeholders are prevented from talking to the Scrum teams What are stakeholders? (quoted from Agile Modeling: Active stakeholder participation ) ...


3

A viable strategy could be the following. First, make him truly aware of the delay he's causing: you might produce a Cumulative Flow Diagram to point out the slowdown (quite easy given that you work with Jira). Then, help him dispose the pending approvals: as Ashok said, show him how to test the user stories schedule a weekly UAT session (possibly ...


3

Actually I think you see this more with web applications vs 'normal' apps. Clients can have a whole host of browsers/plugins/firewalls etc which you dont have in your test enviroment. In regards to how to mange these problems, it sounds like you are doing the right thing by testing on the customers own devices. I would add that carefull and conservative ...


3

The user story is closed when the acceptance criteria is met. So if any team member can check if the story acceptance criteria passed or not, then yes they can close the tickets. If any technical background/setup needed, like creating automated tests, test data..etc. then it's more dependent on the setup or the person who have it on their machine.


3

I can't really answer this from a SAFe perspective since I'm not very familiar with the framework, but I'll add a general answer nonetheless because I sense some confusion in the way the question was asked (and it's too big for a comment :)). For example, the "Verify the put API updates correct information in DB" AC that you mention, isn't really ...


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 ...


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 ...


3

I also believe that the most concerning part is: the PM has decided that whilst the AC has been met, the code should not reach production as it does not deliver a suitable enough value to our user. I see three possibilities here. The PM does not believe that the AC need to include providing value. The PM is not putting in enough effort to the AC to ...


2

I think subjective user stories are a recipe for scope creep. If you want to focus on business owners requirements & make something that is measurable then I would fall back on a framework like the Digital Marketing & Measurement Model for generating discrete KPIs that the business owner will understand & are achievable from your point of view. ...


2

On our project, we hold virtual demos for clients at the end of releases all the time. We have a pretty standardized format for this, that usually works pretty well. First of all, you want to make sure that everybody involved understands what technology you are using for the meeting itself. Are you using webex? Skype? Skype for business? Something else? ...


2

I think the question is why he's not reviewing the stories. I'd use the lean approach that Toyota developed: help the client eliminate his own bottleneck. Possible reasons: he doesn't have dedicated resources to the project he doesn't know how to review the stories (as he's external and not involved in the development efforts, he might not know all the ...


2

Jira does not offer any native character count function. A few alternatives: Export to CSV and filter the data in Excel Use Jira API Use ScriptRunner, as you can see here: issueFunction in issueFieldMatch("project = FOO", "description", "^.{0,10}$") Now, more on the PM context: People using such small acceptance criteria are either very seasoned or very ...


2

A user-story is a description of a Requirement. I think what you are concerned with is about describing a Specification. Specifications are not rendered as user-stories; they can (and should) be rendered as acceptance criteria attached to the story. For example, if a ORR checklist says things like: - Have all new logging functions had a archiving and ...


2

The product owner is responsible for defining all the items in the backlog with enough detail for the team to be able to work on them. Acceptance criteria is part of those details. The product owner needs to have these clearly expressed before work begins. Of course it's also the team's responsibility to make an effort to understand the items from the ...


2

If the quality of the product isn't good, is the Scrum Team fault It is never the stakeholder fault! According to the Scrum Guide (2019), the Scrum Reviews are "informal meetings" in which the stakeholders are invited to participate and collaborate. Being "informal meetings" we expect the requests, needs and ideas presented by the stakeholders to be ...


2

Why are you talking about blame? Your Question reads, to me, like "Something went wrong. Who do we blame?" The only situation in which "responsibility" (read: blame) should be relevant is when it is necessary - namely, when selling to an external party. In which case, the only valid answer could ever be: "Check your contract". This is a question for a ...


Only top voted, non community-wiki answers of a minimum length are eligible