How do you create a user story for tasks like implementing hashing Sha256 on passwords or modify column in a table? Let us consider the
As a ________, I want to be able to _________, so that ________
template. I find it hard to choose a WHO for it especially in user stories like these?
Thank you!
welcome!
The examples you give are "how" rather than "what". User stories are explicitly about the "what" and the "why" without specifying the "how".
So:
Why do you want to "modify column in table"?
As a user, I want the Username field to have more length so I can enter my entire long hyphenated name in it.
As a sysadmin, I want to make the Foo column an indexed field so I can easily perform searches.
You see? Either of these user stories could be implemented by modifying a column in a table, but they are very different from each other.
The benefit of writing a user story even when you already have a requested implementation in hand is that it creates an opportunity to ask "is this the best/simplest implementation that will get the job done?" and "what is the value of doing this, anyway? and who gets that value?"
Does that make sense?
Not everything needs to be a User Story.
Using Feature-driven development (FDD), you write in this format:
[action] the [result] [by|for|of|to] a(n) [object]
In the case you mention, could be something like
Implement hashing Sha256 for password protection
And also – the "users" in a so-called "user story" are not necessarily true application users, and they do not have to be. In the case of describing a "backend service," for example, the "user" would be the (whatever-it-is) that issues the SOAP-call to that service.
Furthermore: some things, like "implement hashing on passwords," might not correspond to any "user story" at all! After all, what does any "user," who merely proffered you a correct password, know or care of what you subsequently did with it, how you verified that it was correct, or how you stored it?
As Vicki very well put it, the wisdom of "user stories" is to cleanly separate "what and why" from the otherwise uninteresting drudgery of "exactly how." Indeed, IMHO it may well be said that the purpose of this entire exercise is to divorce the description of "what and why" from the "how" with which it is much-too-often conflated.
As a user I want to be confident my password is secure so that my account stays safe
Sub-task: implementing hashing Sha256 on passwords
As a user I want to be able to store both my home and work phone numbers so that I can be easily contacted
Sub-task: modify column in a table so that two phone numbers can be stored
