The title sums the question up pretty well. How do you do that? Should you even make implementing HTTPS a user story?

I thought of:

"As a page visitor I want all communication with the service to be secure so data integrity is kept". Sounds pretty dumb if you ask me. The other way around would be:

"As a technical manager I want web page access to be secure so that information from the page visitor is secure". Also sounds stupid.

4 Answers 4


I would focus on the need, rather than the implementation. The user story would then simply be:

"As a user, I want any personal information I give (Company) to remain private and secure."

With HTTPS then being an implementation detail of that story. After all, if you found some other means of completing the requirement (such as not getting any personal information in the first place), then HTTPS would become irrelevant.

You could also append something like "even from a malicious attacker", which should make it more testable (see INVEST mnemonic) - make sure all common attacks (other than social engineering, which isn't really solvable...) fail.

Just keep in mind that the user shouldn't really care whether the web page is secure. They care that their data is no compromised. You could have a (potentially very large) user story for everything necessary to secure is secured. (depending on how large it is, it might invalidate INVEST, though.)

Alternately, you could bake it into your Definition of Done (see this answer). Note that the DoD is not a user story, task, nor epic in and of itself - it is a part of the acceptance criteria for stories. If your DoD contains sufficient security as a requirement, and you have a story that doesn't yet have that security, then the story cannot be considered as 'Done' (and thus burned down) until it meets the DoD requirements.

  • Let us continue this discussion in chat.
    – Sarov
    Commented Aug 3, 2017 at 14:03
  • I agree with this but I would like to emphasize on that user stories better suit functional requirements. We achieve nothing really by forcefully writing every requirements as a user story. This is especially true for non functional requirements. Having said that, if your product owner is technucally thick as wood, maybe its best to write things as stories so the value of the requirement is better communicated.
    – Muhammad
    Commented Aug 4, 2017 at 7:25

First of all, you are potentially misusing user stories as a mechanism. A user story emerges from a real need, it should not be invented or changed to fit the process.

Anyway, it could be something like:

As chief security manager, I want all communication between all our applications and all clients to be done via HTTPs so that the risk of a MITM attack is lowered.


As a page visitor, I want to see a "green lock" in my browser so that I feel safe and protected.

Note the difference between the two. For example, if you have a mobile app with client-server interaction, an API - first story forces you to cover those as well.

  • My approach for this would be the latter here too. HTTPS is a tricky example as there are internal and external drivers to making the case, but assuming the case is user-driven this gets my vote.
    – Drew
    Commented Oct 30, 2017 at 16:11

You could also just have it as a general "task". Not everything needs to written in a user story format.

  • 4
    Can you expand on this a bit? As written, it's probably more appropriate as a comment rather than an answer.
    – Todd A. Jacobs
    Commented Aug 3, 2017 at 11:35

Would recommend “Implement HTTPS” as the task title.

User stories are great for describing a problem, particularly from a customer point of view (or in the shoes of a customer). They also help customers structure their problems so that they less likely to put forward what they think is a solution.

But you need to be practical, that’s part of the agile manifesto.

There’s no misunderstanding of the problem here; there’s no great interpretation and there’s no “open-mindedness” required. A user story could actually muddy an otherwise clear outcome in this instance.

Do yourself and your team a favour by keeping this simple. But definitely log, track and create a definition of done, so it can be tested and sized.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.