3 ms·

> You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". Uh,

> You don't get a user story saying: "as a user i would like my information to be private" or "as a user i would not like to experience a concurrency bug". Uh, you do. You totally do. "As a User, I want the site to appear on my browser quickly". In acceptance criteria, "Quickly is defined as 98th percentile 400ms full roundtrip to AWS US-east-1". How do you do this? You write a test. What kind? A performance test. When does it run? Every time you check into CI. How is this different from standard agile practice? It isn't.

zby 11y ago
The quote is about 'privacy' and your user story is about 'speed' - these are different criteria and 'privacy' is much harder to specify in a user story.
- jacques_chester 11y ago
  That's what I get for reading too quickly :) I focused on performance because that's one example I've had brought up several times. And it's probably the easiest one. I've seen privacy stories too. The style I like is to create a malicious user and deny them. As a Malicious User I want to steal credit card numbers So that I can sell them on the black market Given I have access to the web app When I supply malformed URLs I am ignored A/C Pentest tool with decent corpus Another approach, also used, is exploratory testing. Security and privacy are tricky because you're dealing with humans who can react creatively; so the best test is humans who react creatively.
partycoder 11y ago
A functional requirement is like adding a room to your house. A non functional requirement is defining what the construction material is and what the construction standards are. What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. If you construct it, and it was already earthquake resistant, should not be a problem. But if it wasn't, you will need to rebuild.
- jacques_chester 11y ago
  > What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. There's no law against writing every story with some NFR component, or interspersing NFRs with regular feature stories. The process of writing, test-driving and accepting stories is a framework, it's guidelines. When I or other engineers see obvious architectural landmarks ahead, we often encourage the product managers to bring those forward. A story can have user value, and it can also have business value outside of user value. One such business value is attacking architectural risks. And sometimes you tell business "this unaddressed architectural scope is a big risk", and they say "OK, let's fix it". And that is still agile. The point was never rejecting high ceremony in order to replace it with low ceremony. It was that professionals should talk to each other. Constantly.
  - partycoder 11y ago
    NFRs can be hard to add once something is built.
    - jacques_chester 11y ago
      Nobody is arguing with that. But it's also very wasteful to build an earthquake resistant house in a geologically stable area. You have to talk it over.

zby 11y ago

The quote is about 'privacy' and your user story is about 'speed' - these are different criteria and 'privacy' is much harder to specify in a user story.

jacques_chester 11y ago
That's what I get for reading too quickly :) I focused on performance because that's one example I've had brought up several times. And it's probably the easiest one. I've seen privacy stories too. The style I like is to create a malicious user and deny them. As a Malicious User I want to steal credit card numbers So that I can sell them on the black market Given I have access to the web app When I supply malformed URLs I am ignored A/C Pentest tool with decent corpus Another approach, also used, is exploratory testing. Security and privacy are tricky because you're dealing with humans who can react creatively; so the best test is humans who react creatively.

partycoder 11y ago

A functional requirement is like adding a room to your house. A non functional requirement is defining what the construction material is and what the construction standards are. What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. If you construct it, and it was already earthquake resistant, should not be a problem. But if it wasn't, you will need to rebuild.

jacques_chester 11y ago
> What you describe is like constructing a house, then once it is constructed, specify it needs to be earthquake resistant. That should be specified as an upfront requirement not a story. There's no law against writing every story with some NFR component, or interspersing NFRs with regular feature stories. The process of writing, test-driving and accepting stories is a framework, it's guidelines. When I or other engineers see obvious architectural landmarks ahead, we often encourage the product managers to bring those forward. A story can have user value, and it can also have business value outside of user value. One such business value is attacking architectural risks. And sometimes you tell business "this unaddressed architectural scope is a big risk", and they say "OK, let's fix it". And that is still agile. The point was never rejecting high ceremony in order to replace it with low ceremony. It was that professionals should talk to each other. Constantly.
- partycoder 11y ago
  NFRs can be hard to add once something is built.
  - jacques_chester 11y ago
    Nobody is arguing with that. But it's also very wasteful to build an earthquake resistant house in a geologically stable area. You have to talk it over.