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.
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.
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.
Or:
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.
You could also just have it as a general "task". Not everything needs to written in a user story format.
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.
