Agile Storyboard and Software Development Leveraging Smart Contract Technology in Order to Increase Stakeholder Confidence

Abstract

We present a solution based on blockchain technology and smart contracts for agile project management in light of the continuing transition in the software development industry. Due to the fact that these technologies are self-executing, customized, and impervious to tampering, they are considered to be crucial for the transition to a more efficient, transparent, and transactive payment gateway between major stakeholders. These major stakeholders will be able to communicate through smart contracts, which will act as a bridge between them. As part of their responsibility, they will make sure that all of the terms of the contract are met and acknowledged by all members of the team. As a result of our research, we propose a model in which payouts could be automatically enabled and penalties or grants could be introduced based on performance. If any changes were to be made to the contract in the future, all parties involved would be automatically notified. To maintain the development cycle, they should accept these changes as soon as possible. Because of this, the product owner and client are able to concentrate their resources on more profitable and productive tasks, without the need to monitor this aspect of agile project management. Our proposed model brings together different partners with the objective of successfully developing different IT projects by leveraging software engineering solutions such as smart contracts.

1. Introduction

Having an agile approach is essential in the world of software development, since the environment is constantly changing. As a result, software developers have to adapt to these changes in order to survive. In order to deal with this constant change, it is imperative that agile principles such as early delivery, continuous improvement, and adaptive planning are applied effectively. As a result of these software development principles, there are a variety of processes that follow these principles. We choose to focus on the Scrum methodology in this article. As a result of the chosen methodology, we may notice that processes can be categorized into two main categories: those that require human intervention to make decisions and interpret data, and those that do not, which means that they can be automated as well. By leveraging smart contracts, we propose using the recently emerging blockchain technology to automate some specific tasks associated with Agile software development in order to increase efficiency. It is our proposal to use smart contracts to conduct acceptance tests and verify that the conditions are met for a certain set of implemented features. In addition, we will involve key stakeholders to ensure that the conditions are met for a certain set of developed features. Payment for the developed feature will be initiated automatically as a result of this action. Due to the fact that the blockchain is publicly accessible and immutable, smart contracts make any activity on the blockchain transparent and visible to all parties involved.

There is no doubt that Scrum is a practical and effective method for managing complex projects and delivering high-quality products. It promotes transparency and accountability among stakeholders. It encourages a team to constantly reevaluate and adjust priorities as often as possible, which allows for flexibility and adaptability. As well as allowing for iterative development, it also allows for frequent releases to take place. Teamwork and collaboration are fostered by this kind of system, and it helps the team focus on the tasks that are of highest priority to them. As a whole, this seems to be a very robust methodology that has a number of very strong points to it. The product development life cycle does not cover all aspects of the product development process, including the payments that must be made between stakeholders. When something is not paid in time or the payment itself is delayed, it weakens trust among its stakeholders [1]. This weakened trust can quickly decrease team productivity, increase conflicts between stakeholders and decrease the overall morale of the team. In essence, it will negatively affect everyone who is involved in the particular project as a whole [2]. However, if the problem worsens, it can have a much more significant effect on the organization itself by negatively affecting the organization’s revenue stream and its ability to pay its employees [3].

It is our aim to provide a solution to the above-mentioned problem with the proposed model. By doing this, it ensures that there is not a breach of trust between stakeholders in the case of a default on payments for certain developed features. This will be done by leveraging smart contracts in conjunction with the Scrum methodology. Therefore, stakeholders would be able to gain a much higher degree of confidence in dealing with each other in the long run. As part of the smart contract, it ensures that funds are locked up and available for the development of certain features. It will only be released if development has been completed according to the contract. The research paper’s objective is to simply propose a possible solution to this problem. The aim of the proposed solution is to be easily integrated within an existing organization’s workflow that already uses Scrum in their daily activities. There are definitely similar solutions out there to our proposed model, such as [4] or [5]. However, none of the research seems to focus on increasing confidence between stakeholders by ensuring that the payment will be successfully made. This is because no one will default on either payment or contracted features.

The article follows a structure that has the following objectives: a thorough understanding of the major concepts surrounding blockchain technology, followed by the consideration of smart contracts and a review of the Scrum methodology. The next chapter is going to focus on the main parts of the proposed model itself. This is after a comprehensive literature review of the main components of the model has been conducted. Finally, we will conclude this article by bringing to a close what we have learned throughout the process and our conclusions.

2. Background

2.1. Blockchain Technology Overview

The blockchain was defined as a distributed ledger of transactions, or an append-only log [6]. One of the key pieces of this ledger is that it is distributed, meaning the data is not in a centralized database. This means that only one entity can write to it. By using a cryptographic method, the information is spread in a chain of blocks. If any additional information is added, all the peers need to agree on it, which is called the consensus protocol. By cryptographic hashing the so-called Merkle tree from the header, an information block cannot be changed once it has been created. In each block, a hash from the previous block will be stored in the hash table, making it completely tamper-proof and transparent to all parties. Moreover, storing this hash in the header ensures that the blockchain is truly secure, since unauthorized updates will be quickly detected by all nodes.

By establishing a consensus protocol, all nodes will be in agreement about what information needs to be changed. We will focus on just a few of the essential protocols that are needed for our model [7,8,9]. First, there is proof of authority. In this case, nodes must reveal their identities and register with a public notary database in order to remain trustworthy, as that is the primary purpose of the blockchain. Secondly, proof of work is basically the backbone of most blockchain systems, for instance, Bitcoin, which has its own cryptocurrency [10]. In order to link two blocks collectively, a cryptographic puzzle needs to be solved, so-called “zero-knowledge-proof” [11]. In order to solve the puzzle, the difficulty increases with every solution, requiring more and more computational power to handle the solutionizing process. With this high computational power comes high energy consumption as well. Consequently, this makes the process environmentally unfriendly [12]. In some cases, energy consumption exceeds the amount of energy used by some countries. Two additional protocols would demonstrate the passing of time and activity [9,13]. These protocols are not as essential as the previous ones, but they facilitate proving the time spent on a particular task, which will be essential for our model.

The above-mentioned consensus protocols are not suitable for all types of blockchain systems. There are two major types: permissionless and permissioned [14]. Their main difference is who holds the central authority granting access. In the permissionless blockchain, the cryptocurrency holder can remain totally anonymous until the currency is converted to fiat currency. After this, the blockchain holder’s identity will be revealed, as the fiat currency will be transferred into their bank accounts. With permissioned blockchains, a user can only join the chain once they have been granted access rights, thereby divulging their identity.

2.2. Blockchains and Smart Contracts

Originally introduced in 1996 by Nick Szabo as a way of automating legal contracts, smart contracts were designed to be secure. They could not be changed without the consent of all parties. Szabo defines smart contracts as “a set of promises, specific in digital form, with protocols within which parties perform on these promises” [11]. As another method of implementing smart contracts, the Ricardan approach has been proposed [15,16]. This involves capturing legal agreements in software code that is then able to be executed. When pre-defined rules are met by these contracts, they are able to automatically execute predefined tasks once they have been met. This enables them to be considered smart contracts. If-then logic is used for these predefined rules, which require a condition that either is met or is not, and an action that will be performed when that condition is met.

In order to create an automated contract, there are three fundamental steps that need to be followed: The first step is to establish an agreement between the parties. The second step is to define and initiate a smart contract. In the third step, the predefined criteria are checked, and if they are met, the process is finally concluded. There is also an optional fourth step, which would be the release of the funds to the entitled party, if these funds are already available under the contract. However, this step is not mandatory in any case.

Smart contracts around the world are used in different sectors due to their inherent power in security and tamper-proofing. One of these sectors is within the logistics industry, especially supply chain management, using blockchain technology in order to perform infocommunication activities with distributed databases [17]. One of these sectors is the financial industry. For instance, Barcleys, a British multinational investment bank, developed and implemented smart contracts into their product as well as into their transactions [18]. Another area where smart contracts are being used is the utility sector, in which Makmur et al. [19] presented a case study of Persero, an Indonesian company that introduced smart contracts into their billing processes with a vast customer base of 72 million customers. Additionally, smart contracts can also be used in the retail sector. In the future, invoices and contracts with suppliers will be able to benefit from blockchain technology. An option to take advantage of these novel types of contracts would be to monitor energy consumption and provide billing services [20]. Nevertheless, this new technology not only affects SME sectors, it has a direct effect on our day-to-day lives as well, such as being able to perform payments with an e-wallet without having to touch actual currency [21].

Among the biggest challenges that any industry faces today is cyber security. Data theft and data leaks are the main topics of concern. There is a possibility that smart contracts contain sensitive data, which could provide an advantage to all those who may have access to this data. In addition, these smart contracts may have access to huge sums of money as well, making them even more vulnerable to cybercriminals. The benefits of blockchain technology are that they are based on append-only permissions and have a distributed and resilient nature [22] compared to other IT systems. As a result, they are more resistant to cyberattacks.

Based on the cryptographic characteristics of blockchains where cryptocurrencies can be supported, smart contracts are able to handle financial transactions between two parties (such as a currency exchange) [23]. It is due to this reason that they are capable of converting cryptographic currencies into fiat currencies. With each smart contract, the financial transaction functionality of the blockchain is leveraged [24]. This means that whenever funds are transferred, they are only released if the desired conditions within the smart contract are met. This creates an extra layer of security for both parties. This ensures that funds are only released if they are in compliance with the contract, otherwise, they will not be released [25].

2.3. Agile Methodologies in the Form of Scrum

One of the key features of Agile development is finding the proper balance between effective coordination and process agility with the least impact on quality and metrics [26]. As process quality and metrics are closely related to the delivery timeline, which, in turn, is linked to the business plan; and as this plan is continuously subject to change, the aim of Agile is to ensure that change can be easily achieved at the development level without directly affecting the elements mentioned above [27,28,29]. In addition to supporting a constantly changing environment, Agile development also facilitates effective communication between team members [30,31].

Scrum is an Agile methodology which is based on an incremental development model aligned to the following three principles: all of the activities within the team need to be transparent to all members; each process element can always be viewed at any given moment to make sure that they are heading in the right direction; in case the business plan changes or mainly due to outside forces the working process can easily be altered and adapted to meet the changing requirements [32]. Another advantage of Scrum is how it is possible to structure these processes in iterative cycles of fixed duration, which usually last for two weeks. It is hoped that this approach will allow us to break up the already complex overall process into smaller, more digestible pieces that can be developed and finalized with greater ease than if it were taken as a whole [33,34]. The responsibility for dividing the whole process into smaller cycles is solely the responsibility of the product owner. The product owner is the one responsible for gathering the client requirements and structuring them into user stories, which will form sprints [35]. In order to ensure the highest amount of visibility and transparency within a Scrum process Agile methodology, we can highlight the following key ceremonies: refinement is a ceremony which will result in the creation of the user stories based on the clients high level requirements; planning is the meeting where the user stories are estimated and divided into sprints based on the estimations; stand up is a daily meeting where each team member will focus on presenting what they did yesterday what they will do today and if something is blocking them or not; sprint retrospective is an overview of the past sprint, where the aim is to identify bottlenecks and fix them so they will not happen in the next sprints; sprint review is an often forgotten part of the Scrum ceremony; however, its aim is to showcase the progress which has been done in the last sprint to a wider part of the organization [36]. In addition to these ceremonies, we have the sprint backlog, current sprint and future sprints as well, where all the user stories are kept [37].

It is possible for a user story to be accepted by the product owner alone in the event that the requirements of the story are fully met. Due to the fact that this process relies solely on human judgment, which is prone to bias and error, by leveraging smart contracts and blockchain technology, we aim to diminish this possibility, and by creating a more secure way for all stakeholders to accept these stories, we also aim to create transparency.

3. Model Implementation

3.1. Advantages of Leveraging a Smart Contract

The primary advantages of leveraging a smart contract in an Agile environment are:

• Smart contracts, as they are based on code, will execute automatically if the predefined conditions are met. Additionally, as the code is distributed within the virtual environment, execution of it is guaranteed.
• As smart contracts are based on blockchain, once they are created, they will become immutable and unalterable. This characteristic will make them tamper-proof, as modifying something within the contract would alter the blockchain component as well.
• As the blockchain is transparent to all stakeholders, it ensures that the smart contract retains its original content.
• In terms of security, blockchain offers the highest level of security for the contract, as smart contracts, due to the technology used, are tamper-proof and transparent.
• The execution time of the contract is instant, once the conditions of the smart contract are met. This is due to the fact that blockchain technology runs in a decentralized virtual environment and each member of the network will have a copy of the ledger.
• In addition, smart contracts via blockchain technology offer the capability of self-verification by leveraging generated cryptographic credentials before and after a user story is complete. This cryptographic credential will include proof of code existence and passing test cases, which should match the predefined business requirements within the smart contract.
• Smart contracts can be linked to cryptocurrencies and non-virtual currencies. Additionally, this linkage can be used for triggering a fund transfer from a defined source to a specified account. It is pertinent to note that the use of non-virtual currencies is not mandatory. It is ultimately up to the person who defines the smart contract to choose the source of its funds.

3.2. Key Stakeholders of a Smart Contract

Within the relationship between the smart contract and the Scrum process, we can clearly define three main stakeholders, which are: the client, the product owner and the developer(s). Additionally, we can define a fourth stakeholder as well, which would be the organization the product owner and developer(s) belong to. The fourth stakeholder is unique, because if the client works directly with the product owner and the developer(s), the company can easily be dismissed. Hence, our model aims to support both variations, and as such, we will reference just the three major stakeholders and include the fourth one only where needed. These key stakeholders have the objective of initiating a smart contract via the creation of a user story. They also need to make sure that the user stories are built according to the laid-down criteria. The stakeholders are further divided into two categories: the givers and the receivers. The givers are responsible for laying down the foundations for the user stories and ensuring that the necessary funds are assigned to the smart contract. The receivers are responsible for ensuring that the user stories are executed and match the requirements of the giver. In addition, they are also the ones who will receive the funds once the smart contract’s elements are properly executed.

The client is in the giver category and they are responsible for building out the necessary requirements for the user stories from the business perspective. Additionally, their financial funds will be linked to the smart contract and those funds will be released to the receivers once the user stories are completed. The product owner, the developer(s) and the organization itself (optional) are in the receiver category, as they are the ones who need to develop the user stories and who will also receive the funds once those user stories are completed. Under the developer(s) umbrella, we bring together key people who are responsible for building out the final product via the user stories; including: software developer(s), software tester(s), designer(s) and devops. The role of the product owner is to act as a bridge between the developer(s) and client in order to ensure that the user stories are clearly defined by both parties. Additionally, along with the client, they are the ones who can mark a user story within a smart contract as completed. In cases where the organization is present as the fourth main stakeholder as well, its objective is to receive the funds from the client and divide them accordingly between the employees in the form of salaries. Once the user stories are built out and assigned to the smart contract, they will be divided into sprints, which are predefined time intervals for developing the user stories. During these time intervals, payments will be due, but the payments will be made on the predefined dates only if the user stories are completed. Figure 1 will showcase all of the above-mentioned elements into a simple and user-friendly diagram:

4. Methodology

The developed methodology is not meant to alter or replace existing processes. Instead, it is meant to emphasize and enforce the aspects of Agile methodologies that we believe are most critical, such as trust and transparency. As a result, we will blend the most critical elements of the Scrum methodology into our model. This will ensure that integrating our system into the team’s daily processes will not have any negative impact. By doing so, it would simply contribute to the creation of even more trust and transparency between stakeholders. We can assume that this is the case, since our model is based upon the following characteristics: define, develop, prove and accept. There are two key aspects here that focus on building and maintaining trust amongst the key stakeholders, while the first two support these two aspects.

Our approach has been to develop a model that supports the core pieces of the Scrum methodology, and we have developed the following six main steps. These steps will work in harmony with the organization’s existing agile processes without affecting them directly.

• The client will create their own smart contract and generate a private key for it. It will assign the necessary funds to the contract in order to ensure that future payments can be made (the smart contract can be started only if the necessary amount is assigned to it). These funds can be cryptocurrencies or non-virtual currencies, depending on what the stakeholders agree on as a form of payment. Additionally, the client will define a product owner for the smart contract.
• The product owner working along with the client and the developer(s) will register user stories to the smart contract. Each user story will be composed of the following elements: user story unique identifier, state (which can be: refined, under development, development ready and done), developer (who will work on it), story requirements and acceptance criteria.
• The product owner will register the smart contract’s user story with the developer who will be working on the given task. In addition to this information, the product owner will also register the cryptographic credentials for the user story, based on the acceptance criteria.
• When each sprint starts, the product owner along with the developer(s) will assign the predefined user stories to the sprint and will set the payment due date within the smart contract for each completed user story. Each time a story is completed by the developer, they will need to generate the cryptographic credentials for the acceptance criteria. They need to include these as part of the user story. Developers will add proof of code existence to the cryptographic credential in addition to passing test cases added by the software testers, which should contain the predefined business requirements within the smart contract.
• When the user story is finished, the product owner will compare the two hash extracts of each user story with the state set to Development Ready, and if they match, will show the client the completed user story. The first hash will be the one created by the developer and tester (see step 4) and the second hash is the one within the smart contract that defines the business requirements of the developed feature (see steps 2 and 3).
• Each sprint will equal a payment transaction within the smart contract and can be initiated only if the two hash extracts from the user story are a match and the product owner, along with the client, accepts the user story as done.

Figure 2 will showcase all of the above-mentioned elements as a simple and user-friendly diagram:

Smart Contract’s Payment Transactions

As a result of the methodology that has been described above, we are now going to be focusing on two of the most critical aspects. These are transactions and how they relate to the existing working flow. Additionally, we will also focus on the relationship between the working flow itself, as well as the transaction itself as a whole. It is relatively straightforward to link transactions to user stories within a sprint, since Scrum is our chosen methodology. As soon as a user story has been completed by all stakeholders and has been accepted as the outcome by all of them, a transaction block will be executed. As soon as each user story is completed, the associated funds will be released automatically by the system. When it comes to smart contracts, the number of transactions that are waiting to be executed is equal to the number of user stories that are waiting to be processed in a smart contract. In order for the project to reach its final stage, it is necessary to accomplish this step. As a result, this has the effect of increasing the level of confidence between stakeholders in the process. It is understood by each party that funds will only be released once all tasks within a sprint have been completed. The purpose of tying a transaction to a particular user story is to ensure that the party that develops the software always has a steady flow of cash coming in. Using this method, the team member will be able to pay all the team members involved in the project without having to keep any extra cash on hand to compensate them. For the other party, it is necessary to understand that they will not have to pay anything up front or a large sum of money at once. As a result, they will simply pay the agreed amount for the services that were developed and delivered to them.

It will be possible to assign a transaction amount to each user story based on the effort that will be required to develop the feature. It is generally accepted that user stories are composed of tasks that are estimated and tracked from the perspective of time and progress as well as complexity. Consequently, this aspect further strengthens trust and enables correct and transparent estimates of tasks, as well as supporting those estimations by providing milestones to support those estimates. The software development company is able to improve its overall performance by becoming more agile in this manner, making it as efficient as possible. All parties involved in the project will be satisfied with the outcome as a result. As soon as the satisfaction level reaches a critical threshold, all the key stakeholders will be in a position to focus on other activities in order to achieve the project’s objectives, instead of having to worry about the outcome of the sprint or about the overall project. Figure 3 shows the relationship between a transaction and a user story in terms of how they relate to each other. There is no doubt that this will contribute as much as possible to achieving the desired level of satisfaction as soon as possible.

If we were to examine these two aspects, the transaction and the user story, observing them in a deeper light, we would conclude that the sole purpose of the transaction would be to trigger the transfer of funds from the defined input source to the designated output source. When the user story reaches its final state of completion, this transaction will be triggered. Therefore, the transaction will have the following attributes: an input fund source, which will be determined by the stakeholder who contracts the software agency; an output fund source, which will be defined by the stakeholder contracted by the software agency; and a story point ID, which will identify a list of tasks that need to be completed to allow the transaction transfer to take place.

Two aspects of the sprint are crucial. The first one being that it will trigger a transaction when the stories within the sprint are at their final stage. The second one is the user stories themselves. A user story is basically a project description highlighting the requirements for the project. It also outlines the steps that need to be taken in order to initiate the transaction. The following main attributes of a user story are used: a user story ID, which identifies the story itself; a requirement list, which summarizes the main objectives of the task; the story’s status, which describes how the story is progressing; the developer who is responsible for making the story happen; and finally, the acceptance test, which is the first step in ensuring that the development is ready to be presented to other stakeholders and is, of course, in accordance with the predefined objectives. Figure 4 illustrates how these user stories eventually come together to form a sprint and end up triggering a transaction. Upon completion of the user story, the transaction of funds from one predefined source to another will be triggered.

These transactions have a couple of fail-safe mechanisms in case someone tampers with them. It is because they are an organic part of the smart contract that makes them tamper-proof. Additionally, the cryptographic credentials have the purpose of scaring off possible fraudulent attempts. As the smart contract will indicate exactly who deviated away from the predefined agreement, it will be perfectly clear which side was at fault. As a result, all further transactions can be automatically blocked and the case can be taken to court with the necessary proof against the fraudulent party.

5. Algorithm

As a result of the model highlighted above, we have built the following pseudocode (Algorithm 1). This is in order to be able to demonstrate how our smart contract could be implemented via blockchain. This is what it would look like if it were put into use for a real-life application in the future. The purpose of this pseudocode is to explain the key elements that need to be included in a smart contract, with the aim of illustrating what these elements are. Additionally, it shows the main functionality of the smart contract that ends up triggering the transaction at the end.

Algorithm 1: Pseudocode for Srum Payment Contract

1 Creat scrumPaymentContract {

2  define client(name, fundSource)

3  define productOwner(productOwner, fundSource)

4  define developers(names, roles)

5  define userStories(ID, requirement, status: ready, acceptanceCriteria,

developer)

6  function initiateFundTransfer(client, productOwner, userStories) {

7   If (client.accept and productOwner.accept and

userStories.acceptanceCriteria.pass){

8   amount = userStories.acceptanceCriteria.pass.totalTimeSpent

9   startFundTransfer(client.fundSource, productOwner.fundSource,

amount)

10   }

11  }

12  function startFundTransfer(clientFund, contractorFund, amount) {

subtract(amount, clientFund)

pay(amount, contractorFund)

13  }

14 }

6. Conclusions and Discussions

We propose an approach that, at first glance, may seem counterintuitive because of the Agile mindset, where we are constantly looking for continuous changes and mutual trust. Despite this, we believe that the quintessential part of a smart contract is to create trust among its stakeholders. Because of its transparent nature, blockchain creates an environment of trust, which is enormously helpful for an agile community. As with any other technology, the sense of trust conferred from its use it is not only a result of its nature, but also of its features. The transparency of the process will help ensure that all members of the team are aware of how the project is progressing. Due to the fact that blockchains are append-only, once a smart contract has been created, it will be visible indefinitely, providing a tamper-proof record of all the work that has been completed on a specific project. Additionally, a major feature of the blockchain is the currency transaction functionality, which provides the greatest sense of trust within the project, since both parties know and understand that smart contracts work in a way that ensures their funds are strictly secured and may only be received and sent (according to the situation) if all predefined rules are met by all participants in the project.

Using the developed pseudocode, it is our overall goal to ensure that our model becomes an organic part of the Agile development process. This is in combination with the Agile Scrum team. Since we do not wish to introduce new working processes into our business process, we designed the flow to fit perfectly into the Scrum process. This is because it requires no changes or adaptations on the part of the Scrum team in order to be embedded into their daily workflow. As soon as our proposed model is integrated into the organization’s Scrum process, we are able to offer an extra level of transparency and trust. This reinforces the core principles of the Agile ecosystem. Apart from being able to leverage smart contracts in a homogeneous fashion within the Scrum methodology, we also put a great deal of emphasis on the sense of security from both parties, as one of the trigger points of enabling the transaction to be executed is the fact that all stakeholders agree that the contract was executed in accordance with the predefined set of features.

In the future, we plan to investigate different methods of software development processes that are driven by human reasoning in order to leverage smart contracts’ blockchain-empowered added values in order to maximize the level of trust in communication and collaboration between different stakeholders. Our underlying model acknowledges that human decision-making is a key point in creating trust within a group; as a result, we do not intend to remove this factor from our model. We are simply seeking to aim to maximize the level of trust among the main stakeholders within the group without disrupting their workflow. This is done by ensuring that our model can easily be adapted to each individual’s working process.