Agile Storyboard and Software Development Leveraging Smart Contract Technology in Order to Increase Stakeholder Confidence
Round 1
Reviewer 1 Report
The introduction is very short and must be extended.
The paper structure at the end of the introduction is absent.
The problem statement and motivation are absent.
The main contributions are absent.
More recent references must be discussed and cited.
Improve the quality of figures.
Author Response
The introduction is very short and must be extended.
Dear reviewer, thank you for your suggestion. We have rewritten the introduction of the article to better describe the reason why we made this study and the motivation behind it. The article was revised by native English lector.
The paper structure at the end of the introduction is absent.
We have incorporated this aspect as well in the article.
The problem statement and motivation are absent.
We have incorporated this aspect as well in the introduction part of the article.
The main contributions are absent.
We have incorporated this aspect as well in the introduction part of the article.
More recent references must be discussed and cited.
We have added more recent references to the article.
Improve the quality of figures.
We have corrected it.
Author Response File: 
Author Response.docx
Reviewer 2 Report
Title: A Simple way of Improving Confidence with Partners within a Software Development Project by Leveraging Different Tools.
Summary: The authors of this study propose a Blockchain-based method for managing scrum IT projects in order to promote trust and transparency in the implementation of IT solutions through agile stories. A smart contract implements the logic to define requirements, compensate the developers to implement the IT changes, and fund other stakeholders such as the product owner once the requirements are satisfied. The use case is demonstrated via a prototype in the form of an pseudo algorithm.
I consider this study to be incredibly unique, innovative, and intriguing. However, the authors must address a number of significant issues before the publication can be considered a quality research article.
Review comments:
1) Title: The title of an article is crucial for the article to reach a broad audience in a short amount of time. The current article's title is "A Simple way of Improving Confidence with Partners within a Software Development Project by Leveraging Different Tools." It is unclear from the article title whether or not the authors propose a Blockchain-based software development solution. I would suggest that the authors include either "blockchain" or "smart contract."
My proposed title is "Agile storyboard and software development leveraging Blockchain technology." However, you are not required to use this exact title.
2) Abstract: In the abstract, the authors state, "If any changes were made to the contract, all parties involved would need to accept these changes." Will it not result in significant software implementation delays?
3) Introduction: The introduction as it stands is rather brief and has no impact. The driving force behind the current study is completely absent. The literature review's subsection 2.3 provides a clear explanation of the reason behind this research. The precise content, though, cannot be moved straight to the introduction section. It's not quite accurate for the authors to claim that the deployment of smart contracts addresses the issue of trust in this study. In most current agile implementations, a group of developers, a scrum master, a product owner, testers, and other stakeholders come to an agreement on the complexity of the projects, the complexity of the stories, the number of points to give the stories, and the number of stories to be chosen per sprint. Trust is therefore not a major issue. I do not, however, entirely disagree that the implementation of the blockchain is not necessary. Innovation and boosting productivity through speedy development are the two main focuses of agile initiatives. The smart contract's ability to function as a gamification platform expands the number of creative ways to record user stories and acceptance criteria. Therefore, rather of focusing just on the trust issue, I urge the authors to emphasize the gamification aspects of agile development through smart contracts.
Also, it is better to add some references to showcase that this is the gap identified by prior studies.
4) Background: The literature review for this paper is a real gem. There are a couple of places where more explanation is needed. In sub-section 2.1 “Blockchain Technology Overview”, the authors have mentioned that “In the permissionless blockchain, the cryptocurrency holder can remain totally anonymous until the currency is converted to fiat currency, after which the blockchain holder’s identity will be revealed.” It is not clear why the identity will be revealed and to whom it will be revealed. The bitcoin network is a permissionless network and anyone can transact on it. The transactions are open for public to see. However, all someone could see is the from and to addresses and the transaction value in the transaction. Therefore, this statement requires more explanation.
5) Later in the background section, the authors mentioned that “the automated contract is made up of four fundamental steps: first, it includes the agreement …, it releases the funds to the entitled party.” Not all smart contract transactions involve cryptocurrencies. The smart contract may occasionally be empty of all cryptocurrency. Only the Blockchain nodes can start transactions, and the network nodes are responsible for paying the gas required to complete transactions. Hence, these statements needs to be refined.
6) Model Implementation: Why is it suggested that cryptocurrencies and smart contracts be used to fund developers and product owners? If no vendor or consulting firm is engaged in a typical IT project, the developers are full-time employees of the corporation and are paid wages in a typical manner (monthly, bi-weekly, or weekly). Are the authors trying to suggest paying the stakeholders in cryptocurrency if there are vendors or contractors involved? It is important to consider the digital currency's volatility.
7) The majority of the steps in the "advantages of leveraging a smart contract" can be left in place if the authors are changing the setting or attempting to make the gamification to encourage involvement in a software development. However, the gamification that is connected with givers and receivers in the form of various virtual currencies should be mentioned.
8) What is the self-verification (discussed in "Advantages of Leveraging a Smart Contract" step 6)? How does self-verification relate to both the process before and the process after a user story is finished?
9) In the “key stakeholders of a smart contract”, customer is mentioned as one of the three stakeholders of the scrum process. However, it is a client who funds the projects and customers are not involved in the product development.
10) Methodology: In the third step of the six main steps, cryptographic credentials are mentioned. It is also mentioned that “each time a story is completed by the developer, they will need to generate the cryptographic credentials.” What are these cryptographic credentials? Who will generate them and how are these credentials generated?
11) In the next step, there is a mention of comparing two hash extracts to verify that the story is ready for demo. It is better to use a simple bool flag on a smart contract to say that the story is ready for demo or a uint to hold multiple statuses?
12) "Figure 2" illustrates the steps mentioned in the implementation. However, it might be challenging to comprehend all of the procedures that go into implementing a smart contract. I found a relatively recent article showcasing several smart contract features. I believe the writers should look at the context diagram and adjust figure 2 as necessary. https://dl.acm.org/doi/pdf/10.1145/3571290
13) Sub-section: “Smart Contract’s Payment Transactions”: The following is the text from manuscript:
“Due to scrum being our chosen methodology, it is relatively straightforward to link transactions to sprints, and once a sprint has been completed and accepted as the outcome by all stakeholders, a transaction block will be executed, and funds which are associated with each sprint will be automatically released.” The sprint typically lasts about two weeks, and according to the statement, two transactions are produced per month. It is not a practical option to create a Blockchain application that can only record two transactions each month. The authors should be explicit about what they mean by transactions in this context. This point is entirely related to Figure 3. As a result, it applies to the whole subsection. Additionally, creating a smart contract solely to track the progress of a sprint and reach agreement via a voting mechanism is not a workable solution. The smart contract implementation makes more sense if the full agile implementation is carried out on the Blockchain smart contract to capture the logical flow of story development during the daily standups, development and testing status, and finally the implementation on smart contract.
14) The last thing is of minimal priority. What if the stakeholders decide to game the system in order to make easy money and approve the story's acceptance requirements without actually working on the story? Will the smart contract release the funds? The writers ought to go into detail about how system tampering on purpose might be prevented.
15) Currently, there is only a prototype or idea provided. The proposal is in the form of a pseudo algorithm. If possible, I recommend the authors to develop a bare-bones version of smart contract to demonstrate the transactions and various functionalities.
16) Conclusion and discussion looks fine for me.
I applaud the authors for their original thought and proposal. However, because the manuscript requires a substantial amount of effort, I would recommend a major revision on this paper.
Comments for author File: 
Comments.pdf
Author Response
Review comments:
1) Title: The title of an article is crucial for the article to reach a broad audience in a short amount of time. The current article's title is "A Simple way of Improving Confidence with Partners within a Software Development Project by Leveraging Different Tools." It is unclear from the article title whether or not the authors propose a Blockchain-based software development solution. I would suggest that the authors include either "blockchain" or "smart contract."
My proposed title is "Agile storyboard and software development leveraging Blockchain technology." However, you are not required to use this exact title.
Dear reviewer, thank you for your suggestion, we carefully considered it and decided that it is a really good idea to change the title. Also thank you for your proposed title as well it helped us tremendously in choosing the right direction. The article was revised by native English lector according to the required style.
2) Abstract: In the abstract, the authors state, "If any changes were made to the contract, all parties involved would need to accept these changes." Will it not result in significant software implementation delays?
Within our proposed model we would require agility from all stakeholders to act on a change as soon as possible. We have also updated the text to indicate that stakeholders will be automatically notified in order to engage with that newly proposed change. However our proposed solution is not limiting developers to choose their own technical solution which they deem to be best for the developed feature. We merely require confirmation on the business requirements which is ultimately the important bit for the organization itself.
3) Introduction: The introduction as it stands is rather brief and has no impact. The driving force behind the current study is completely absent. The literature review's subsection 2.3 provides a clear explanation of the reason behind this research. The precise content, though, cannot be moved straight to the introduction section. It's not quite accurate for the authors to claim that the deployment of smart contracts addresses the issue of trust in this study. In most current agile implementations, a group of developers, a scrum master, a product owner, testers, and other stakeholders come to an agreement on the complexity of the projects, the complexity of the stories, the number of points to give the stories, and the number of stories to be chosen per sprint. Trust is therefore not a major issue. I do not, however, entirely disagree that the implementation of the blockchain is not necessary. Innovation and boosting productivity through speedy development are the two main focuses of agile initiatives. The smart contract's ability to function as a gamification platform expands the number of creative ways to record user stories and acceptance criteria. Therefore, rather of focusing just on the trust issue, I urge the authors to emphasize the gamification aspects of agile development through smart contracts.
Also, it is better to add some references to showcase that this is the gap identified by prior studies.
We have rewritten our introduction to include the missing pieces. However we don’t feel that gamification is the best direction for our proposed model although indeed it is a really good suggestion and we will consider it in a future article. At this point we think that the payment issue would be the problem to put it like that that we would like to solve.
4) Background: The literature review for this paper is a real gem. There are a couple of places where more explanation is needed. In sub-section 2.1 “Blockchain Technology Overview”, the authors have mentioned that “In the permissionless blockchain, the cryptocurrency holder can remain totally anonymous until the currency is converted to fiat currency, after which the blockchain holder’s identity will be revealed.” It is not clear why the identity will be revealed and to whom it will be revealed. The bitcoin network is a permissionless network and anyone can transact on it. The transactions are open for public to see. However, all someone could see is the from and to addresses and the transaction value in the transaction. Therefore, this statement requires more explanation.
We have added extra explanation to this. Basically it will b revealed to everyone (the word) as it will be transferred to the users bank account.
5) Later in the background section, the authors mentioned that “the automated contract is made up of four fundamental steps: first, it includes the agreement …, it releases the funds to the entitled party.” Not all smart contract transactions involve cryptocurrencies. The smart contract may occasionally be empty of all cryptocurrency. Only the Blockchain nodes can start transactions, and the network nodes are responsible for paying the gas required to complete transactions. Hence, these statements needs to be refined.
We have added the fourth step as an optional one, one thing that we would like to highlight is that those funds aren’t necessarily cryptocurrency as it could be other sources as well.
6) Model Implementation: Why is it suggested that cryptocurrencies and smart contracts be used to fund developers and product owners? If no vendor or consulting firm is engaged in a typical IT project, the developers are full-time employees of the corporation and are paid wages in a typical manner (monthly, bi-weekly, or weekly). Are the authors trying to suggest paying the stakeholders in cryptocurrency if there are vendors or contractors involved? It is important to consider the digital currency's volatility.
Dear reviewer, indeed your concerns are correct. We have introduced a fourth stakeholder as well which is the company. It will act as an umbrella for the product owner and the developers. However we made it optional in case the client would end up working with a freelancer directly to make our proposed model a bit more brouder.
7) The majority of the steps in the "advantages of leveraging a smart contract" can be left in place if the authors are changing the setting or attempting to make the gamification to encourage involvement in a software development. However, the gamification that is connected with givers and receivers in the form of various virtual currencies should be mentioned.
We have added a 7th step which specifies what type of funds can be used in our proposed model.
8) What is the self-verification (discussed in "Advantages of Leveraging a Smart Contract" step 6)? How does self-verification relate to both the process before and the process after a user story is finished?
We added extra explanation around the self verification part as it will include proof of code existence and test cases which should match the predefined business requirements within the smart contract.
9) In the “key stakeholders of a smart contract”, customer is mentioned as one of the three stakeholders of the scrum process. However, it is a client who funds the projects and customers are not involved in the product development.
Indeed it should have been client instead of customer, thank you a lot for your note dear reviewer.
10) Methodology: In the third step of the six main steps, cryptographic credentials are mentioned. It is also mentioned that “each time a story is completed by the developer, they will need to generate the cryptographic credentials.” What are these cryptographic credentials? Who will generate them and how are these credentials generated?
Added extra explanation for this, the cryptographic credentials will contain proof of code existence added by the software developer and passing test cases around the defined business logic around the smart contract added by the software testers.
11) In the next step, there is a mention of comparing two hash extracts to verify that the story is ready for demo. It is better to use a simple bool flag on a smart contract to say that the story is ready for demo or a uint to hold multiple statuses?
Added extra explanation for this, for why we need to compare two hashes and not use just a simple flag. The reason is that the first hash will contain the data created by the developer and tester and the second one the business logic from the defined task.
12) "Figure 2" illustrates the steps mentioned in the implementation. However, it might be challenging to comprehend all of the procedures that go into implementing a smart contract. I found a relatively recent article showcasing several smart contract features. I believe the writers should look at the context diagram and adjust figure 2 as necessary. https://dl.acm.org/doi/pdf/10.1145/3571290
We have changed the images, with the hope of making them clearer. Dear reviewer, we would like to thank you for the provided example.
13) Sub-section: “Smart Contract’s Payment Transactions”: The following is the text from manuscript:
“Due to scrum being our chosen methodology, it is relatively straightforward to link transactions to sprints, and once a sprint has been completed and accepted as the outcome by all stakeholders, a transaction block will be executed, and funds which are associated with each sprint will be automatically released.” The sprint typically lasts about two weeks, and according to the statement, two transactions are produced per month. It is not a practical option to create a Blockchain application that can only record two transactions each month. The authors should be explicit about what they mean by transactions in this context. This point is entirely related to Figure 3. As a result, it applies to the whole subsection. Additionally, creating a smart contract solely to track the progress of a sprint and reach agreement via a voting mechanism is not a workable solution. The smart contract implementation makes more sense if the full agile implementation is carried out on the Blockchain smart contract to capture the logical flow of story development during the daily standups, development and testing status, and finally the implementation on smart contract.
We have updated the image to better reflect how we envision the transaction. And also modified the text accordingly.
14) The last thing is of minimal priority. What if the stakeholders decide to game the system in order to make easy money and approve the story's acceptance requirements without actually working on the story? Will the smart contract release the funds? The writers ought to go into detail about how system tampering on purpose might be prevented.
Dear reviewer, thank you for your suggestion. We have added it as a small paragraph at the end of the Smart Contract’s Payment Transaction chapter.
15) Currently, there is only a prototype or idea provided. The proposal is in the form of a pseudo algorithm. If possible, I recommend the authors to develop a bare-bones version of smart contract to demonstrate the transactions and various functionalities.
Dear reviewer, thank you for your suggestion, however we would like to share the practical implementation of this proposed solution in another article. That is the reason why we haven’t included it into this one.
16) Conclusion and discussion looks fine for me.
I applaud the authors for their original thought and proposal. However, because the manuscript requires a substantial amount of effort, I would recommend a major revision on this paper.
Author Response File: Author Response.docx
Reviewer 3 Report
The authors are off to a good start in hopes of combining software methodologies and smart contracts from blockchain to form a decent, yet inquisitive idea in making a better agile development process. My only suggestion/tip would be take this paper a step further to have the practical implementation done for the said experiment. Having a pseudo code for a smart contract and without the practical implementation; it is hard to see the results of the experiment.
Author Response
The authors are off to a good start in hopes of combining software methodologies and smart contracts from blockchain to form a decent, yet inquisitive idea in making a better agile development process. My only suggestion/tip would be take this paper a step further to have the practical implementation done for the said experiment. Having a pseudo code for a smart contract and without the practical implementation; it is hard to see the results of the experiment.
Dear reviewer, thank you for your suggestion, however we would like to share the practical implementation of this proposed solution in another article. That is the reason why we haven’t included it into this one.
The article was revised by a native English lector.
Author Response File: Author Response.docx
Round 2
Reviewer 1 Report
It can be accepted.
Reviewer 2 Report
Thank you for responding to my comments. The manuscript has been impressively revised. Best wishes for your research.
