Managing blockchain projects with user stories
Part I — Identifying users/personas
This is the first of a three-part blog describing a way of applying the agile methodology for blockchain projects. In this part, I’ll discuss the importance of identifying personas, or a stand-in character, instead of user roles as a basis for identifying the beneficiary of user stories.
Agile development emphasises the delivery of things that end users perceived as usable. User stories are the principal mechanism in agile development to capture the required features of a solution from the perspective of a user. Blockchain, as a piece of technology, could be used to fulfil the needs of users but its impact is not directly impacted by an end-user.
A blockchain-based system does not look any different from any non-blockchain system especially from a User Experience and User Interface (UX/UI) perspective. This begs the question: are user stories a good mechanism for capturing the features of a blockchain project?
A user story represents a feature of a product as seen from the perspective of a user. A user story is typically written in the form “As <user>, I want <feature>, so I get <value>”. The question is; who exactly is a user?
Firstly, let’s address the question from the perspective of who is not a user. The answer is if you are building a product for the benefit of the people who will be interacting with your product, then you, as the developer, are not the user from a user story perspective.
You could make the argument; if you were to build a piece of utility code that would eventually go into a product that you intend to deliver, then you, as the developer, should be presented as the user (beneficiary) in the user story about the utility code.
This is probably one of those grey areas that you need to be mindful when creating user stories. A utility code specific for a product might not be worthy of a user story. It is more a chore or task that you, as a developer, would have to create in order to fulfil the needs of the product’s beneficiary.
On the other hand, if the utility code was meant to be a standalone product, then a case could be made for it to express it as a user story. We’ll explore this later.
Likewise, sponsors of projects or stakeholders of your solution are not users that you would express in a user story. Whilst they may be paying for you for your effort to build the product and to whom you will be delivering the product, they are not the person interacting with your product.
Secondly, it is common to find user story written from the perspective of a role. For example, it is not uncommon to find:
As a cryptocurrency user, I would like to be able to simply choose from a list of my trusted broker, and initiate payment, so I won’t make the mistake of paying the wrong person.
A role (e.g. cryptocurrency user, system administrators, developers, etc.) is not interacting with your solution. Ultimately, it is a person that will be interacting with your solution. A person, a human[1], is a complex creature. He/she may be interacting with your product in a role, but his/her interactions are likely to be influenced by his/her personal experience. For example, imagine two characters both interacting with the Ethereum blockchain system:
a) Lisa, whose day job is an experienced DevOps engineer, may have no qualms setting up her own Geth node, would probably take exception to your solution abstracted out much of the features associated with Geth.
b) Lenny, whose day job could be a cryptographic mathematician but with little or no DevOps experience, finds setting up Geth a chore, might not be too pleased with your solution that requires expertise not dissimilar to the installation of Geth.
Both Lisa and Lenny, in this instance, are interacting with Ethereum via Geth in the role of cryptocurrency users. However, you can see the different experiences are likely to dictate the way they interact and therefore the way you, as a developer, should build your better-than-Geth product.
My recommendation is to use personas or fictional characters with real names[2] to express your user stories. This helps to better disambiguate the people who are interacting with your product in the same role.
I have, thus far, suggested who should not be a candidate user in a user story and recommended that we should use personas in user stories. I shall now try to answer the question: who is the persona in the user story?
At the start of this article, we have eluded to the fact that a blockchain based solution, would look no different than a non-blockchain based solution. Would that not suggest the use of user stories to describe the features of a blockchain-based solution inappropriate?
Should we not use other methods of informing the expected architecture of a blockchain-based solution?
Indeed user stories themselves do not necessarily inform us of the architecture of our blockchain-based solution. Nevertheless, a blockchain-based solution must still deliver value to its intended user much like a non-blockchain solution. A user story is a useful way of scoping the work.
The question of who is benefiting and identifiable in our user stories depends on the level of abstraction in the technology stack that we wish to delivery and to whom. Figure 1 illustrates a blockchain application stack. It also highlights the kind of personas that will be interacting with the stack.
At the highest level are end users[3] interacting with the application in a role (such as a cryptocurrency user). These users are not concerned with the technology needed to fulfil his/her needs. For example, cryptocurrency user would only be concerned with the ability to exchange business values using cryptocurrency. The fact that need is being served using, for instance, Proof-of-Work or Proof-of-Stake consensus mechanism is of no concern to him/her.
At the “middle” layer you have “smart contracts” and blockchain client developers. Personas, at this layer, are typically engaged in coding “smart contracts” and/or client (UI/UX or integration). What might be of value to these personas are productivity toolkits to enable them to debug or assemble codes.
You could identify personas in the “middle” layers collectively as “developers”. But you will find a broad range, from very in-experience programmers to very experienced programmers, polyglot programmers, single language programmers, etc. Hence, writing user stories using personas offer better focus.
Finally, at the lowest level, these users are your platform engineers (sometimes referred to as DevOps Engineers) and blockchain protocol engineers (i.e. the people who build and updates say, Ethereum, Hyperledger Fabric, Hyperledger Sawtooth, etc). To these users, the things that are of value to them are typically development kit, orchestration tool, API documentation, etc.
The point here is different users at different layers of the blockchain application abstraction has different needs. By expressing the needs of users from user stories, we are much able to clarify work to be done.
In conclusion, user stories are a useful mechanism for capturing features of a blockchain-based product not unlike non-blockchain based products. It helps you focus on and identify the features that you should be delivering and avoiding delivering features that are of no value. The key to creating useful user stories is to identify the personas that will benefit from the product that you plan to deliver. In other words, are you delivering the feature to an end user, a developer or platform type personas?
In Part II, I shall demonstrate the process of writing user stories, based on Roman Pichler’s “10 tips for writing good user stories” and “From personas to user stories”, techniques using blockchain related use cases.
Notes:
[1] You could be delivering a solution where an animal, your pet, could be its beneficiary but that is beyond the scope of current discussion.
[2] Roman Pichler’s “From personas to user stories”.
[3] Most literature on user stories focus on these types of personas.
