User Stories seem to be my favourite topic these days…
…the idea behind this post started with seemingly innocent user story, like this:
I, as an End User, want to authenticate by PIN at the MFD, so that my documents are secure.
Today, I want to focus on one particular thing and that is stakeholder value.
The value to the user, according to this story is security and the desired function is authentication. Long story short, I do not know that many users, who would require authentication! Authentication (and authorization for that matter) is a solution which is helping us to achieve something else, something, like data confidentiality and non-repudiation.
The real value the user desires is data confidentiality. Non-repudiation is usually the desired value of IT administrators or security officers, who own the security policy of the organization in question. So what is the function of the system the user needs? Or does the user really care?
The function the user actually needs is some kind of protection, which creates confidence in the user that it is not easy or even possible to retrieve their documents.
So let’s start with something completely different…
I, as an End User, need the system to exhibit protection of my documents, so that I can trust their confidentiality.
What message I can take from such user story as a developer:
- There is a stakeholder called End User.
- The user wants the system to exhibit protection, meaning that the system should not only protect the documents, but also demonstrate that it is protecting them.
- The user values the trust which the system builds and maintains and the fact that the trust can be put in confidentiality of user documents.
But what hapened to our authentication? There are two other stakeholders, who actually value authentication. As mentioned above, stakeholders internal to the customer, who govern the security policy may have specific requirements on authentication. In this case, it is intentional design as it stems from constraints imposed by customer environment. These constraints can and perhaps should be challenged, but never ignored.
In such case, we work with another stakeholder and with different user story:
I, as a Security Officer, want the End Users to have to authenticate by PIN at the MFD, so that we can trace each action at the MFD to a specific End User.
Putting these two user stories together brings us to authentication and much more. The user experience we are delivering has to build trust between the user and the system.
Another option is to look at authentication (by PIN) as a solution to our security problem. There are other ways how to maintain data confidentiality, so we might put data confidentiality in the position of the required function.
I, as an End User, want the system to control access to my documents in a way visible to me, so that I can trust that my documents remain confidential.
This might be one of the possible descriptions of data confidentiality in the form of a user story or rather the trust in data confidentiality. Again, no unintentional design. In this case, we are leaving more room for innovation as we are delivering on values with no design constraints.
And I will talk about constraints in one of my next posts.