UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INFORMÁTICOS MÁSTER UNIVERSITARIO EN INGENIERÍA DEL SOFTWARE –
EUROPEAN MASTER IN SOFTWARE ENGINEERING
Supporting the integration of User Experience Design (UXD) in Agile using Gamification:
Development of a Trello Power-up
Master Thesis
Luis Felipe Arias Farfán
Madrid, 2020
This thesis is submitted to the ETSI Informáticos at Universidad Politécnica de Madrid in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering.
Master Thesis
Master Universitario en Ingeniería del Software – European Master in Software Engineering
Thesis Title: Supporting the integration of User Experience Design (UXD) in Agile using Gamification: Development of a Trello Power-up
Thesis no: EMSE-2020-11 September 2020
Author: Luis Felipe Arias Farfán Telecommunications Engineer Military University Nueva Granada
Supervisor:
Ana María Moreno Sánchez-Capuchino Full Professor
Technical University of Madrid Department Software Engineering Computer Science School
Technical University of Madrid
ETSI Informáticos
Universidad Politécnica de Madrid Campus de Montegancedo, s/n 28660 Boadilla del Monte (Madrid) Spain
I.Acknowledgements
This page is to remember all the people who supported me on this trip, even those who in the distance always had time to listen to my stories about the unforgettable place that is Madrid, Spain.
This master's thesis is dedicated to my daughter. I want to thank my parents and my brother, who always believed in my abilities and are witnesses of my effort to achieve everything that I set out to complete. Thank you for your patience and perseverance.
To all the professors and staff of the Technical University of Madrid and the IMDEA Software Institute, thank you very much for everything.
And finally, thanks to my supervisors for supporting the development of my project.
II.Table of contents
A. Contents
I. Acknowledgements ... 3
II. Table of contents ... 4
III. Abstract ... 6
IV. Figures Index ... 7
V. Tables Index... 9
VI. Chapter 1: Introduction ... 10
a) Waterfall and Agile Methods ... 10
b) Usability ... 12
c) Agile and usability ... 13
d) Our proposed solution ... 14
e) The structure of the Master thesis ... 15
VII. Chapter 2: Background ... 17
a) Introduction ... 17
b) Explaining “GLUX – A Gamified Framework to integrate Lean UX in Scrum” ... 17
c) Introducing Trello ... 19
i. Architecture... 19
ii. Trello Power-up ... 20
VIII. Chapter 3: Results ... 28
a) Brief Description of the Project Development ... 28
b) Product Backlog ... 29
c) Sprint 1 ... 32
i. Sprint backlog ... 32
ii. Design Models ... 35
iii. Results ... 36
iv. Results of the review ... 47
d) Sprint 2 ... 48
i. Sprint backlog ... 48
ii. Design Models ... 51
iii. Results ... 52
iv. Results of the review ... 59
e) Sprint 3 ... 60
i. Sprint backlog ... 60
ii. Design Models ... 63
iii. Results ... 63
iv. Results of the review ... 68
f) Sprint 4 ... 68
i. Sprint backlog ... 68
ii. Design Models ... 75
iii. Results ... 75
iv. Results of the review ... 79
g) Sprint 5 ... 80
i. Sprint backlog ... 80
ii. Design Models ... 83
iii. Results ... 84
iv. Results of the review ... 88
IX. Chapter 4: Usability Testing ... 89
a) Introduction ... 89
b) Performing Usability Testing ... 89
c) Results of the usability testing activity ... 90
i. Participants Profile – Survey results ... 90
ii. Trello experience - survey results ... 92
iii. GLUX Usability test - Type of Card SURVEY ... 93
iv. Card Dependency Usability test - survey results ... 95
v. Scoring and Gratification Usability test – survey results... 97
d) Analysis of Results of the usability testing activity ... 100
X. Conclusions ... 101
XI. References ... 103
III.Abstract
Around a decade ago many companies have used the agile principle through implementation of development methodologies in the software industry as their flagship philosophy to deliver high quality software on the agreed time. Nowadays some evidence from appraisals has demonstrated that products are not complying with the user requirements as expected as they want it. This sense of frustration has been perceived by most of the project manager when a scrum master about product utilization. Customer and user claims that if a stricter design decision were made in previous stages, the product could be closer to their needs. That is where the principle of lean user experience is relevant but not properly integrated in the scrum methodology when it comes to implement it in a software development cycle. This work is about the implementation of lean UX as the way to ensure a better design practice in the agile methodology, using a powerful technological and pedagogical trend known as gamification. In this work a popular and robust tool to manage project has been chosen as the vehicle to implement this solution, its name: Trello, developed by Atlassian Corporation Plc.
Keywords: Lean, User experience (UX), Gamification, Agile, Scrum, Hypothesis, User Experiment, design Studio, Power-up.
IV.Figures Index
FIGURE 1PROJECT SUCCESS RATES BY PROJECT SIZE.THE STANDISH GROUP CHAOS STUDIES 2013-2017 ... 11
FIGURE 2LEAN UX AND AGILE ROADMAP. ... 17
FIGURE 3CREATING A TRELLO POWER-UP ... 21
FIGURE 4TRELLO POWER-UP SETTINGS – BASIC INFORMATION ... 22
FIGURE 5TRELLO POWER-UP SETTINGS – CAPABILITIES ... 23
FIGURE 6 INITIALIZATION OF A TRELLO POWER-UP ... 24
FIGURE 7 TRELLO POWER-UP CARD BUTTON CAPABILITY ... 24
FIGURE 8ADDING TRELLO POWER-UP CLIENT LIBRARY TO HTML FILE ... 25
FIGURE 9APPEARANCE OF A POWER-UP IN TRELLO'S MARKET ... 26
FIGURE 10 CARD CLASS DIAGRAM ... 35
FIGURE 11MOCKUPS OF EPICS ICONS - HYPOTHESIS,EXPERIMENT,DESIGN ... 36
FIGURE 12 GENERATING AN RSA-2048 KEY ... 36
FIGURE 13 GENERATING AN X509 WEB CERTIFICATE FOR TRELLO-DEPENDENCIES.LOCAL.COM ... 36
FIGURE 14 CERTIFICATE INSTALLATION IN CERTMGR ... 36
FIGURE 15APACHE SERVER VIRTUAL HOSTS CONFIGURATION ... 37
FIGURE 16 WINDOWS HOSTS FILE CONFIGURATION ... 37
FIGURE 17 T.GET FUNCTION TO GET THE CARDTYPE DATA ... 37
FIGURE 18 T.SET FUNCTION TO SET THE CARDTYPE DATA ... 37
FIGURE 19 CARD-BUTTONS CAPABILITY ... 38
FIGURE 20 CARD.HTML IFRAME SOURCE CODE FILE ... 38
FIGURE 21 T.RENDER BUILT-IN FUNCTION OF TRELLO LIBRARY ... 39
FIGURE 22 EVENTS AND FUNCTIONS TIGERED WHEN PRESSING A BUTTON ... 39
FIGURE 23 CARD-BACK-SECTION CAPABILITY ... 40
FIGURE 24 SECTION.HTML PAGE ... 40
FIGURE 25RENDERSECTION AND GETCARDVALUE FUNCTIONS ... 41
FIGURE 26 RENDERCARD FUNCTION ... 42
FIGURE 27 AUTHORIZATION-STATUS AND SHOW-AUTHORIZATION CAPABILITIES ... 42
FIGURE 28TRELLO ACCOUNT AUTHORIZATION MESSAGE ... 43
FIGURE 29TRELLO'S ACCOUNT AUTHORIZATION PAGE ... 43
FIGURE 30 PERMISSIONS AND RESTRICTIONS OF REQUIRED TO ENABLE POWER-UP FUNCTIONALITIES ... 44
FIGURE 31 CARDCOUNTERBADGE FUNCTION - SELECTS LABEL COLORS ... 45
FIGURE 32EPICS ICONS ON TRELLO OVER CARD BADGES ... 45
FIGURE 33SPRINT BURNDOWN CHART SPRINT 1 ... 47
FIGURE 34 AGILE TILES MOCKUPS TO ORGANIZE GLUX CARDS ... 52
FIGURE 35 CARD-BADGES CAPABILITY ... 53
FIGURE 36 TAKESBSNAPSHOT FUNCTION ... 54
FIGURE 37 GETHYPOTHESISOFBACKLOGLIST FUNCTION ... 54
FIGURE 38 SETINITIALSPRINTEXPBACKLOGCOUNT FUNCTION... 55
FIGURE 39PLACING A CARD ON SPRINT BACKLOG ... 55
FIGURE 40 FUNCTION SETINITIALSPRINTUSBACKLOGCOUNT ... 56
FIGURE 41 NOTIFYING CARD-FINISHED USING TRELLO ALERT BUILT-IN FUNCTION ... 56
FIGURE 42GETTING BOARD MEMBERS ... 57
FIGURE 43AUTHORIZATION-STATUS CAPABILITY ... 57
FIGURE 44SPRINT BURNDOWN CHART SPRINT 2 ... 59
FIGURE 45 REWARDING POINTS IN SCORE BOARD ... 63
FIGURE 46 SCOREBOARDCLICK FUNCTION ... 64
FIGURE 47 GETTING POINTS IN MODAL FILE ... 64
FIGURE 48DRAWING FIVE POINTS VALUE IN THE SCORE BOARD ... 65
FIGURE 49SPRINT BURNDOWN CHART SPRINT 3 ... 67
FIGURE 51MOCKUP OF LEAN UXACHIEVEMENTS BOARD ... 75
FIGURE 52IMPLEMENTATION OF ALERT NOTIFICATIONS OVER TRELLO BOARD ... 76
FIGURE 53IMPLEMENTATION OF ACHIEVEMENTS BOARD ... 76
FIGURE 54 SPRINT BURNDOWN CHART SPRINT 4 ... 79
FIGURE 55 SCORE AND BADGES BUTTON ON BOARD ... 83
FIGURE 56 USER EXPERIMENT HYPOTHESIS FORM PROTOTYPE... 83
FIGURE 57 SCORE AND BADGES BOARD BUTTONS ... 84
FIGURE 58 RESPONSIVE BADGES BOARD ... 84
FIGURE 59 RESPONSIVE SCORE BOARD ... 84
FIGURE 60 RESULT OF IMPLEMENTING CARD-BACK-SECTION CAPABILITY IN A USER EXPERIMENT CARD ... 85
FIGURE 61RESULT OF IMPLEMENTING CARD-BACK-SECTION CAPABILITY IN A USER EXPERIMENT CARD ... 85
FIGURE 62 SPRINT BURNDOWN CHART SPRINT 5 ... 87
FIGURE 63 PARTICIPANTS PROFILE QUESTION 1 PIE CHART RESULTS ... 90
FIGURE 64 PARTICIPANTS PROFILE QUESTION 2 PIE CHART RESULTS ... 91
FIGURE 65 PARTICIPANTS PROFILE QUESTION 3 PIE CHART RESULTS ... 91
FIGURE 66 PARTICIPANTS PROFILE QUESTION 4 PIE CHART RESULTS ... 91
FIGURE 67 TRELLO EXPERIENCE QUESTION 1 PIE CHART RESULTS... 92
FIGURE 68 TRELLO EXPERIENCE QUESTION 2 PIE CHART RESULTS... 92
FIGURE 69 TRELLO EXPERIENCE QUESTION 3 PIE CHART RESULTS... 93
FIGURE 70 TYPE OF CARD USER FEATURE ACCEPTANCE QUESTION 1 BAR CHART RESULTS ... 93
FIGURE 71 TYPE OF CARD USER FEATURE ACCEPTANCE QUESTION 2 BAR CHART RESULTS ... 94
FIGURE 72 TYPE OF CARD USER FEATURE ACCEPTANCE QUESTION 3 BAR CHART RESULTS ... 94
FIGURE 73 TYPE OF CARD FEATURE USER ACCEPTANCE QUESTION 4 BAR CHART RESULTS ... 95
FIGURE 74 CARD DEPENDENCY USER FEATURE ACCEPTANCE QUESTION 1 BAR CHART RESULTS ... 95
FIGURE 75 CARD DEPENDENCY USER FEATURE ACCEPTANCE QUESTION 2 BAR CHART RESULTS ... 96
FIGURE 76 CARD DEPENDENCY USER FEATURE ACCEPTANCE QUESTION 3 BAR CHART RESULTS ... 96
FIGURE 77 CARD DEPENDENCY USER FEATURE ACCEPTANCE QUESTION 4 BAR CHART RESULTS ... 97
FIGURE 78 SCORING AND GRATIFICATION FEATURE QUESTION 1 PIE CHART RESULTS ... 97
FIGURE 79 SCORING AND GRATIFICATION FEATURE QUESTION 2 BAR CHART RESULTS... 98
FIGURE 80 SCORING AND GRATIFICATION FEATURE QUESTION 3 BAR CHART RESULTS... 98
FIGURE 81 SCORING AND GRATIFICATION FEATURE QUESTION 4 BAR CHART RESULTS... 99
FIGURE 82 SCORING AND GRATIFICATION FEATURE QUESTION 5 BAR CHART RESULTS... 99
V.Tables Index
TABLE 1VALUES OF AGILE PHILOSOPHY ... 11
TABLE 2REQUIRED FIELDS TO SETUP A POWER-UP ... 22
TABLE 3 TRELLO POWER-UP SETTINGS – BASIC INFORMATION EXPLAINED ... 23
TABLE 4LISTINGS FIELDS ... 25
TABLE 5PRIVACY AND COMPLIANCE FIELDS... 27
TABLE 6PRODUCT BACKLOG ... 32
TABLE 7 SPRINT 1 BACKLOG ... 32
TABLE 8 ESTIMATED AND REAL EFFORT PER EACH EPIC AND USER STORY OF SPRINT 1 ... 46
TABLE 9ESTIMATED EFFORT AND REAL EFFORT PER DAY OF SPRINT 1 ... 46
TABLE 10RESULTS OF RETROSPECTIVE ACTIVITY SPRINT 1 ... 47
TABLE 11 SPRINT 2 BACKLOG ... 49
TABLE 12 PROMISE RESULT AND ITS USE IN THE CARD-BADGES CAPABILIT ... 54
TABLE 13 ESTIMATED AND REAL EFFORT PER EACH EPIC AND USER STORY OF SPRINT 2 ... 58
TABLE 14 ESTIMATED EFFORT AND REAL EFFORT PER DAY OF SPRINT 2... 58
TABLE 15RESULTS OF RETROSPECTIVE ACTIVITY SPRINT 2 ... 59
TABLE 16 SPRINT 3 BACKLOG ... 60
TABLE 17 ESTIMATED AND REAL EFFORT PER EACH EPIC AND USER STORY OF SPRINT 3 ... 66
TABLE 18 ESTIMATED EFFORT AND REAL EFFORT PER DAY OF SPRINT 3... 66
TABLE 19RESULTS OF RETROSPECTIVE ACTIVITY SPRINT 3 ... 67
TABLE 20 SPRINT 4 BACKLOG ... 69
TABLE 21 ESTIMATED AND REAL EFFORT PER EACH EPIC AND USER STORY OF SPRINT 4 ... 78
TABLE 22 ESTIMATED EFFORT AND REAL EFFORT PER DAY OF SPRINT 4... 78
TABLE 23RESULTS OF RETROSPECTIVE ACTIVITY SPRINT 4 ... 79
TABLE 24 SPRINT 5 BACKLOG ... 80
TABLE 25 ESTIMATED AND REAL EFFORT PER EACH EPIC AND USER STORY OF SPRINT 5 ... 86
TABLE 26 ESTIMATED EFFORT AND REAL EFFORT PER DAY OF SPRINT 5 ... 86
TABLE 27RESULTS OF RETROSPECTIVE ACTIVITY SPRINT 5 ... 87
TABLE 28 RESULTS OF THE USABILITY TESTING ACTIVITY ... 100
VI.Chapter 1: Introduction
a) Waterfall and Agile Methods
Software development methodologies provide a set of adequate solutions to the common problems of software engineering.
In the decade of the seventies Bell and Thayer proposed the term the waterfall to name a methodology that consists of a sequential model of processes. [1]
The waterfall model proposes a sequence of stages. The first stage is a requirements specification stage, the result of which is traditionally a document that organizes the functional and non-functional requirements of the project. The second stage begins when a specification is complete and approved, the development team can begin to design the blueprint for use by developers, so hopefully they can implement it with as few bugs as possible. The third stage is implementation, this stage consists of writing code to meet the requirements specification. When the implementation stage is almost finished, it is necessary to achieve a correct integration between modules and components using their interfaces. The fourth stage is the verification and validation stage. The objective is to verify that all functional and non-functional requirements were covered during the design and implementation stages. Likewise, it is necessary to validate that the product is optimal to meet the expectations of the stakeholders. When the system responds as expected, it can be installed, then the process enters a maintenance stage.
Despite the benefit that the waterfall model provides in helping to avoid problems that can be more costly in later stages, there are some perceived problems when a requirement is unclear.
Under this perspective, a solution was conceived as a mindset and philosophy that describes a set of principles in the Agile Manifesto. [2]
Agile aspires to define the principles and values used to develop software in a more concrete way, close to the client's needs, and make it more adaptable to the changes that may arise during the development of a project.
The agile philosophy is made up of values, resumed in table 1:
Values
Individual and Interactions over Process and Tools Working Software over Comprehensive documentation
Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
TABLE 1VALUES OF AGILE PHILOSOPHY
In addition, the agile philosophy proposes some principles, but they are self-explanatory and delving into each one deserves a lot of attention, which is not the essence of this work. They were mentioned for reference.
Figure 1 shows the result of the Chaos resolution by style, where a graph showed a notorious difference in the number of the failed project, with agile resulting at least 2 times with respect to the waterfall approach. More details can be found in the following picture:
FIGURE 1PROJECT SUCCESS RATES BY PROJECT SIZE.THE STANDISH GROUP CHAOS STUDIES 2013-2017 Chaos Manifesto states the following quote:
“The Agile process is the universal remedy for software development project failure.
Software applications developed using the Agile process have three times the success rate of the traditional waterfall method, and a much lower percentage of time and cost overruns”. [3]
b) Usability
Usability affects things that people use. From the beginning of the history the ease of use has been a need that complemented with the intuitive design and the error reduction, have promoted the creation on the objects from weapon to cookware.
The term usability engineering was used to describe the interaction of human with computers [4]. As well usability became important in the designing of the first intuitive computer interfaces.
A definition provided by the International Organization of Standardization [5], is the following:
“The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction, in a specified context of use.”1
If we start by breaking apart that definition into the three key components, we can model usability to normal situations, to test the experience of some specified users utilizing a product in a context.
We would measure usability by evaluating (metrics) if and how well they can adjust to some attributes of the product (effectiveness), how quickly they can adjust these attributes (efficiency), and how satisfied they are with the attribute of the product (satisfaction).
One interesting approach to evaluate usability is proposed by Romano and Geissen [6], known as iterative usability testing, where the changes would be made to the product based on the usability testing findings, and then it would be necessary to test the product again with a new set of participants, using the same tasks and metrics. Finally compare metrics in each round of testing to the previous round, and if usability improves, so would our metrics. This iterative process would continue until optimal usability is achieved.
1 ISO 9241-11:2018(en) Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts
c) Agile and usability
In Agile based frameworks like SCRUM, an iteration is done in short work periods, usually a week or two, called sprints. In sprints, design teams work to design and code a function or a group of functions. The overall goal is to deliver software early and often.
Agile usability engineering is a method created from a combination of agile software development and usability engineering practices [7]. Its mission is trying to apply the principles of rapid and iterative development to the field of user interface design.
In recent years, the goal of trying to adapt usability techniques for user-centric agile design has been a topic of interest even at relevant companies like Autodesk. They realized that when using new Agile UCD methods they got better designed products compared with the "waterfall" versions of the same techniques. [8] They bet for Agile communication modes to reduce modifications to the product when discovering usability issues.
Some limitations of traditional SCRUM process about usability are proposed by Singh [9]
and are explained here:
1. Setting product goals requires further study of user needs and context. It implies that maybe the user stories selected are not adequate from the usability perspective.
2. User stories of usability import can be prioritized in a better way
3. It is difficult for the development team to get a realistic view of the desired product or features when the product owner prioritizes delivering an MVP as soon as possible.
However, several problems have arisen when trying to integrate usability engineering techniques into an agile environment. A summary of the main problems experienced by User Experience practitioners while doing Agile UCD, are mentioned by Lynn Miller and Desirée Sy. [10]
d) Our proposed solution
The purpose of this work it to provide a tool or plugin integrated to a project management platform to extend the SCRUM framework capabilities, by applying concepts of Lean UX to improve designs.
Lean UX is presented as an evolution of product design, that, according to popular book authors, “takes the best parts of the designer’s tool kit and recombines them in a way that makes them relevant to this new reality.” [11]. The power of Lean UX is that in this day market feedback is more accessible than ever before and encourages teams to be more collaborative and cross-functional.
The main goal of this project is to motivate the software development teams to improve their practices to design and reduce as much possible the refactorization of their software projects due to design defects or less complaining regarding the user expectations about software usability.
In this work, we present a new tool to implement a framework that considers the needs found in the industry and helps the teams to achieve the best performance when requiring to avoid errors in their designs associated to bad user experience while taking advantage of the benefits of an agile software development methodology like Scrum.
This tool is essentially a plugin that should be used with one of the most popular collaborative platforms, because we want that many people be able to know this solution. This section explains some of the most important characteristics that a software should include to implement the intended solution.
Some of the features of this tool, are listed below:
• Card type: this feature is necessary to assign an identification to each specific task should be made to carry the proposed lean UX framework in a Scrum project. Creating a card, placing a card in the backlog, finishing a card, and deploying a card, are actions that shall be intrinsically related to the type of card.
That is going to be logic employed to implement the scoring an achievement system as stated in other feature of this section.
• Card dependency: The framework works well when the users can identify a relationship between the task that should be done to implement lean UX in their project. For instance, to prove a hypothesis you should be able to carry on some experiments and designs. These tasks have a life cycle that ends when a hypothesis is proved to work well or not. The output of this life cycle should be related with the parent hypothesis.
• Scoring and achievements systems: The main reason of implementing this work systems is to motivate to improve the performance of the team. It is also useful when the managers want to promote a competitive culture in the company by making visible the status of the work between teams of the same company.
• Privacy complying: The tool shall integrate to gather team members information in a protected way. By receiving and sending information, the user shall be secure that the his or her information is transmitted using secure protocols, encrypting sensible data, and the accessibility to some information is limited the necessary for his or her participation in the project.
Considering the previous high-level feature requirements, we consider that using power-ups of the Trello platform, that are like plugins to extend the capabilities of the board, can be feasible to implement a modifications and make out solution the more accessible to the general public that is interested in achieving better results when the idea is to implement a Lean UX approach on their software development project driven by scrum methodologies.
In the coming chapter we present the in details the proposed solution based on the LEAN UX gamification framework by Manal Mubarak Alhammad, that worked as the inspiration for developing a power-up in Trello with the mentioned features.
e) The structure of the Master thesis
Considering this first chapter as an introduction to this project, the following chapters will be organized as following:
In chapter 2, we will talk about a framework used to apply Lean-UX principles into agile environment. Our framework is Scrum. We all present an introduction to the Trello platform and the technologies behind it. As well the main functions of Trello power-up.
In chapter 3, we are presenting details of the development process applying Scrum framework. We put into practice the concepts learnt during the theorical and practical course AGILE PRACTICES AND AGILE USABILITY, as part of the software engineering master program, taught during the autumn semester of 2019.
In chapter 4, we present usability tests that were carried out to verify the user experience of the tool of some features of the application. We tested user acceptance and performed usability test method A / B Testing as well.
Finally, in chapter 5 we presented some remarkable conclusions about the development of the project. They summarize the experiences learned, as well some of the most significant contributions and probable improvements.
VII.Chapter 2: Background
a) Introduction
This chapter is dedicated to explaining the proposed framework known as GLUX that states as Gamification Lean UX (user experience), which is though as a didactical methodology but also as ready to industry solution to encourage the implementation of best practices of usability engineering into Scrum methodology. This chapter introduces the collaborative platform that we used to develop a tool or power-up which enables the implementation and gamification of lean UX in a regular scrum project
b) Explaining “GLUX – A Gamified Framework to integrate Lean UX in Scrum”
In this framework, Alhammad [12] proposes the adoption of Lean UX tactics, to collect badges and points by carrying out some task and beating challenges. Figure 2 shows a roadmap of Lean UX tactics and Scrum integration and serves as the inspiration to design the life cycle that each Lean UX task or tactic, should follow to be useful during the regular Scrum project.
FIGURE 2LEAN UX AND AGILE ROADMAP.
The good thing about this framework is that it barely touches the known roadmap, by adding some tasks or tactics to improve existent steps of the process but not significantly
impacting the spirit of agility of Scrum. This integrated Lean UX tasks or tactics are:
Hypotheses, Design Studio, Experiment Stories, MVP, and Weekly User Experiments.
Hypotheses are created by development team based on their assumptions about the needs of potential users and discuss it with the product owner. This is made during the product backlog refinement.
Design studio is the activity of sketching and discussing design ideas about the selected hypothesis. This is made before the sprint planning meeting.
Experiment story is a weekly activity to validate the team’s hypotheses and collect constant feedback to improve the product. These is activities are planned during sprint planning in addition to choosing user stories.
One important aspect of this framework is that it encourages the cooperation of the team members. Every activity carried out by two or more people is rewarded.
Badges are awards that are obtained by the team when running a weekly activity for first time and for three sprints in a row.
The gathered points and badges are shown in a board used to track the application of framework. Each team has their own boards and it should be updated automatically once users perform a task that deserves to be awarded. The board must remain in the same state after receiving a gratification.
Hypothesis is intended to identify the needs of potential users and what can add value to the business. To create a hypothesis, a template is used:
“We believe that [business outcome] will be achieved if [user] attains [benefit] with [feature]"
• Business outcome: a goal the team would like to accomplish and believe as a measure of success for them. It is also the team’s definition of done.
• Target users: a type of potential users you are focusing on first. Using Proto personas is an option.
• Benefit to the user: what will the end users/customers benefit if the feature is well designed and implemented? What is the user trying to accomplish? Or what does he want to feel during and after using this feature?
• Feature: which key features or services of the product (or improvement of a feature) will help in this situation to achieve the business outcome.
c) Introducing Trello
This section explains the fundamentals of Trello platform2. This section is based on the getting started tutorial of Trello [13]. It is mandatory background that every reader of this document should read to understand the basics of Trello platform. It is also necessary to comprehend in depth the “get started building” blog entry on Trello [14]
to effectively create a power-up that implements most of the lean UX gamification framework explained in section a of this chapter.
First, we provide a definition of the collaboration platform. Trello [15] is a web platform that enables the users to be involved in a seamless collaboration by incorporating flexible task setup, project status tracking, team’s communication, ubiquitous real-time updates, privacy management, secure REST API and extensible functionality using power-ups.
Power-ups are custom applications that add extra functionalities inside of Trello. It helps the user to extend cards functionalities and enhance its or her project management experience.
Using power-ups it is possible to add buttons to cards and boards, show previews of attachments, design collaboration rules and much more. It is possible through a set of already done functions known as Capabilities. This will be explained further in this section.
i. Architecture
This section explains the Trello architecture and technologies behind this platform, according to entries found in the early Tech Trello Blog. [16] First, Trello is a web platform that enables people to collaborate by organizing their schedule in a Kanban
2 A complete user guide can be found in https://blog.trello.com/es/como-usar-trello
model that has received much attention in recent years. This application is composed of a set of technologies that have been improved and redesign through the life of the tool.
According to a blog of 2012 written by Brett Kiefer, a main developer, Trello was started as an HTML mockup made by the original Trello design Team. In those days, the challenge for the development team was to keep the snappy feeling of the initial mockups while creating a solid server and a maintainable client.
In their beginning the code was pure JavaScript, but in the short time it was replaced by CoffeScript, to enable compilation. In the side of the client son remarkable technologies were employed. BackboneJs, HTML5, LESS and Mustache, served from Amazon’s CloudFront CDN, to get low latency loads in many locations.
At the same time, they kicked off an AJAX data load for the first page’s data content and try to establish a WebSocket connection to the server, using a modified version of Socket.io. It is important to produce real-time updates when changes in the board are made by other people. In case it does not work there is an alternative using Ajax; this is useful when the running browser is internet explorer.
On the server side, Nodejs was adequate to handle a lot of non-blocking connections.
The complete their stack by adding MongoDB, mongoose, Express, Connect, Cluster and node Redis for ephemeral data. With the pass of the year they moved to RabbitMQ to publish message to the cluster, but due to questionable behavior of this framework when network partitions occur, the Trello team decided to move to Apache Kafka.
Kafka allows a master-client architecture, where the master receives all delta updates and does its filtering locally based on which models the clients need to forward to users.
It demonstrates, memory usage dropped by about 33%, at a cost of CPU usage increased to approximately 2x. They found that this change reduced costs in 5x.
Finally, to manage load balancing between webservers, they used HAProxy.
ii. Trello Power-up
Trello Power-ups are similar to plugins to extend the basic featured of this collaboration platform and allows integration with another apps. [17] Power-up allow the users to integrate with Trello or create their own custom features, either as public Power-Ups –
available to the entire Business Class community – or as custom private Power-Ups for their own Business Class team. In the next subsections we explain the procedure to create a power-up. This information was taking from Trello’s developer guide. [14]
1. Adding a new power-up
To add a new Power-Up to a team and make it available to be enabled on all of that team's board, start by clicking the "Create New Power-Up" in the top right of the Power- Up admin portal.
FIGURE 3CREATING A TRELLO POWER-UP
To see more details about required fields to setup a Trello power-up, check table 2.
Field Name Description
Name The name to display to user's when viewing the Power-Up in the directory.
Team The Trello team that owns the Power-Up. The Power-Up will be available on the boards of the team selected.
iframe Connector URL
The URL for the iframe connector that will be loaded when the Power-Up is enabled.
TABLE 2REQUIRED FIELDS TO SETUP A POWER-UP
2. Basic Information
Once the system has notified that the Power-Up creation is complete, a form appears with the title Basic Information as shown in figure 4. Those fields are mandatory, and they are explained in detail in table 3.
FIGURE 4TRELLO POWER-UP SETTINGS – BASIC INFORMATION
Field Name Description iframe Connector
URL
The URL for the iframe connector that will be loaded when the Power-Up is enabled.
Icon This will be the icon displayed to users when viewing a Power-Up in the directory.
Categories These categories will be used when searching and filtering Power- Ups in the directory.
Email Use this to email developer with questions if when submit the Power-Up for review.
Support Email Use this email when questions arise from users regarding a Power-Up or if Atlassian needs to contact the developer regarding changes to the Power-Up platform.
Author The name to be displayed as the author in the directory.
TABLE 3 TRELLO POWER-UP SETTINGS – BASIC INFORMATION EXPLAINED
3. Capabilities
In Capabilities section, users can specify which Power-Up capabilities want to use by turning on the toggles. A detailed description of the functionality that can be triggered when they are enabled.
FIGURE 5TRELLO POWER-UP SETTINGS – CAPABILITIES
When a capability is turned on, the power-up announces to Trello that something is going to be done. So, when this capability is invoked, Trello will ask to the power-up what it is supposed to do now. This conversation is held via the connector html page.
To implement the functionality of this capability, it is necessary to include an initialization of the Trello client library on the connector, as shown in figure 6.
FIGURE 6 INITIALIZATION OF A TRELLO POWER-UP
For example, figure 6 is a snippet of the essential code to run a card-buttons capability and render using t.popup(), that is a callback function of the Trello client library to display new iframe, in this case estimate.html with a title passed as argument.
A callback function is a function that Trello will call at the point in time that it should be invoked. In the case of card-buttons, when a user views the back of a card, Trello will call the function we have defined above. This capability expects the end-result of the function call to be an array of objects with each object representing a button to include on the card back. In this example, it is showing a single button with an icon and text like figure 7.
FIGURE 7 TRELLO POWER-UP CARD BUTTON CAPABILITY
4. Connector
The connector is used to point to a HTML page that Trello will load onto the page as a hidden iframe and then Trello will use it to communicate to our Power-Up via window.postMessage. It shall include the power-Up client library as it is needed to interact with Trello. It can be found in https://p.trellocdn.com/power-up.min.js, just like in figure 8.
FIGURE 8ADDING TRELLO POWER-UP CLIENT LIBRARY TO HTML FILE
5. Listings
The Listings section allows to manage how Power-Up will be displayed to end users in the Power-Up directory. Listings are an important part of Power-Up as they are often the first interaction a user has with it. The Overview and Description fields of the listing should be used to communicate what a Power-Up does, and why users should use it.
Table 4 explains listing fields.
Field Name Description
Overview A short description to intro the Power-Up and its features. This will be shown when users search for Power-ups and when Atlassian needs a short one-liner about a Power-Up. The overview field does not support markdown.
Description This will be shown to the users when they view more information about a Power-Up in the directory. This description should include what the Power-Up does, links to more information, and images of the Power-Up in action. The description field supports markdown.
TABLE 4LISTINGS FIELDS
As a result, the recently created power-up is displayed in the Trello’s power-up market.
Figure 9 shows an example of the Bitbucket’s Cloud power-up listing.
FIGURE 9APPEARANCE OF A POWER-UP IN TRELLO'S MARKET
6. Trello’s REST API
Trello has a powerful API that permit to interact with to interact with the multitude of concepts and models that make up Trello. Its documentation is very complete, because it contains sections that explains the all the parameter values and request params used to query, as well it states if a field is mandatory or not.
This API is also concerned about security, as it contains some features to implement authentication and authorization, that is delegated so that an application never has to deal with storing and handling usernames or passwords. Two data structures are used to gran access to a rest client.
API key: it is used to identify the application. It is passed to Trello when the user chooses an account and signs in. It is a 32-character generated in this link:
https://trello.com/app-key
API token: if sign is successful, Trello will hand the user and control back to the application, along with an API Token.
This token, along with the API key, can be used to read and write in the entire Trello account. Tokens should be kept secret. On the same page of API key (https://trello.com/app-key), click the hyperlinked "Token" under the API key. First, the user should press Allow to grant the app identified via the API key, then access to his or her account and the user will be redirected to a page that contains the API token.
To make a GET request to the 1/members/{memberId}/boards resource and list all the boards associated with a member:
curl 'https://api.trello.com/1/members/me/boards?key={Key}&token={Token}'
Replace the {Key} and {Token} parameters with the key and token values from above.
7. Privacy and Compliance
The Privacy and Compliance section contains a form with fields that are related to how a Power-Up manages personal data. Table 5 provides more information about those fields.
Field Name Description
Privacy Policy URL If user has a privacy policy that would like to share with users of his or her Power-Up, user can include a link to it.
Does this Power- Up store any Trello user personal data?
Head over to Personal Data Storage and GDPR for more information on storing personal data in Power-Ups.
API Key The API key to be associated with the Power-Up.
TABLE 5PRIVACY AND COMPLIANCE FIELDS
VIII.Chapter 3: Results
a) Brief Description of the Project Development
In this project we followed the SCRUM framework to deliver incremental results of software. The main goal of this project is to motivate the software development teams to improve their design practices and reduce as much as possible the refactorization of their components or modules, due to design defects or complains concerning the user experience.
We want to enriching Trello by providing Lean UX tactics and gamification elements, according to GLUX explained in chapter 2. In this chapter we emphasize in the tools used in agile methodology to manage a software project, like the product backlog to list the user stories to complete the project.
Those user stories are divided and organized in sprint backlogs to look for a functional MVP as soon as possible. They were chosen depending on the priority and the value that apports to the final solution.
Then presents a set of results in form of iterations, that includes data about the effort expended and burndown chart.
We also included a retrospective ceremony to control the project development process and keep an incremental quality improvement, as well some regular meetings to report progress and issues.
b) Product Backlog
This is the product backlog that contains agile epics and their respective user stories, with an initial estimation of story points and a reasonable value for the project. Table 6 lists a total of 22 epics and 67 stories.
Epic 1: Set Up local environment Story 1: Create a
web certificate using private and public keys
Story 2: Install certificate in operating system
Story 3: Install a web server like apache or express
Story 4: Create a
separate virtual host as proxy for web server
SP: 8 V: 5 SP: 3 V: 5 SP: 8 V: 5 SP: 13 V: 5 Epic 2: Identify card types
Story 5: design a card type data structure
Story 6: create an iframe to place a card type form
Story 7: Allow to get and set card type data by mean of a REST
SP: 2 V: 5 SP: 5 V: 5 SP: 8 V: 5
Epic 3: Linking related cards Story 8: create data
structures for board cards and lists
Story 9: get information of cards and board when is available
Story 10: create a feature to associate cards in a parent- children relationship
SP: 3 V: 5 SP: 2 V: 3 SP: 13 V:5
Epic 4: Reward user when writing or reviewing hypothesis for each sprint Story 11: Keep record
of about creation of a hypothesis card
Story 12: update Scoring board with new score
Story 13: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 5: Reward user when running a design studio each sprint Story 14: Keep record
of about creation of a design studio card
Story 15: update Scoring board with new score
Story 16: notify new goal achieved
SP: 5 V: 3 SP:3 V:5 SP:2 V:2
Epic 6: Reward users when running a user experiment each sprint Story 17: Keep record
about creation of a user experiment card
Story 18: update Scoring board with new score
Story 19: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP:2 V:2
Epic 7: Card's members participation rewarding Story 20: Save fetched
board members data
Story 21: Save fetched card members data
Story 22: Compare board members to card members
SP: 5 V: 3 SP: 3 V: 5 SP: 8 V:2
Epic 8: Reward user when producing an experiment story for hypothesis
Story 23: Record creation of a hypothesis card
Story 24: update Scoring board with new score
Story 25: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP:2 V:2
Epic 9: Reward user when delivering an MVP before the weekly user experiment Story 26: Record
delivery of MVP before the weekly user experiment
Story 27: update Scoring board with new score
Story 28: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 10: Reward user when running a user experiment weekly Story 29: Keep record
of running of user experiment weekly
Story 30: update Scoring board with new score
Story 31: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 11: Reward user when delivering a working MVP before the weekly user experiment
Story 32: Record delivery of working MVP before the weekly user experiment
Story 33: update Scoring board with new score
Story 34: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 12: the team is awarded with the “Thinkers” badge for brainstorming hypotheses during first backlog refinement
Story 35: Track users’
actions to achieve a thinker’s badge
Story 36: Update badges board with a new thinker’s badge
Story 37: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 13: The team is awarded with the “Philosophers” badge for reviewing hypothesis 3 Sprints in a row
Story 38: Track users’
actions to achieve a Philosophers’ badge
Story 39: Update badges board with a new Philosophers badge
Story 40: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 14: the team is awarded with the “Designers” badge for running a design studio during first sprint
Story 41: Track users’
actions to achieve a Designers badge
Story 42: Update badges board with a new Designers badge
Story 43: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 15: the team is awarded with the “Senior Designers” badge for running a design studio for 3 sprints in a row
Story 44: Track users’
actions to achieve a Senior Designers badge
Story 45: Update badges board with a new Senior Designers badge
Story 46: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 16: the team is awarded with the “Makers” badge delivering a working MVP on first sprint
Story 47: Track users’
actions to achieve a Makers badge
Story 48: Update badges board with a new Makers badge
Story 49: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 17: the team is awarded with the “Builders” badge for delivering an MVP for 3 sprints in a row
Story 50: Track users’
actions to achieve a Builders badge
Story 51: Update badges board with a new Builders badge
Story 52: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 18: the team is awarded with the “Tester” badge for conducting an experiment for the first sprint
Story 53: Track users’
actions to achieve a Tester badge
Story 54: Update badges board with a new Tester badge
Story 55: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 19: the team is awarded with the “Senior Testers” badge for carrying out user experiments for 3 sprints in a row
Story 56: Track users’
actions to achieve a Senior Testers’ badge
Story 57: Update badges board with a new Senior Testers’ badge
Story 58: notify new goal achieved
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 20: implement the badges board Story 59: create a
desktop button to enable the badges board pop-up
Story 60: show badges dynamically
Story 61: implement responsive design to the badges board
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 21: implement the score board Story 62: create a
desktop button to enable the badges board pop-up
Story 63: show points dynamically
Story 64: implement responsive design to the score board
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
Epic 22: improve power-up application presentation Story 65: implement
descriptions for the experiment and design cards
Story 66: personalize notifications setting colors to awarded or rewarded
Story 67: implement a form to set and clear the hypothesis in the experiment card
SP: 5 V: 3 SP: 3 V: 5 SP: 2 V: 2
TABLE 6PRODUCT BACKLOG
c) Sprint 1
In this first iteration, we settled the local environment necessary to run a power-up hosted in the local environment. Then, we began the development of the application by implementing the card type selection functionality, because we considered that it would be better to differentiate the type of card from the beginning and adding functionalities depending on this attribute of the card. As an prove of this theory, is that implementing the following feature, linking related cards, could be easier when we already know the type of card to create a correct relationship of parent children between hypothesis card and design studio or user experiment cards.
i. Sprint backlog
Table 7 shows the list of epics and user stories proposed for implementation in sprint 1 of the power-up development project.
Epic 1: Set Up local environment Story 1: Create a
web certificate using private and public keys
Story 2: Install certificate in operating system
Story 3: Install a web server like apache or express
Story 4: Create a separate virtual host as proxy for web server
SP: 8 V: 5 SP: 3 V: 5 SP: 8 V: 5 SP: 13 V: 5 Epic 2: Identify card types
Story 5: design a card type data structure
Story 6: create an iframe to place a card type form
Story 7: Allow to get and set card type data by mean of a REST
SP: 2 V: 5 SP: 5 V: 5 SP: 8 V: 5
Epic 3: Linking related cards Story 8: create data
structures for board cards and lists
Story 9: get information of cards and board when is available
Story 10: create a feature to associate cards in a parent- children relationship
SP: 3 V: 5 SP: 2 V: 3 SP: 13 V:5
TABLE 7 SPRINT 1 BACKLOG
The following is a detailed list of the points, description and task related to user stories of sprint 1.
• Story 1: Create a web certificate using private and public keys o Points: 8
o Description: As a developer I want to create a web certificate from a private key
o Tasks
▪ Generate an RSA-2048 key
▪ Create a root SSL certificate
• Story 2: Install certificate in operating system o Points: 3
o Description: As a developer I want to install a web certificate in my local environment
o Tasks
▪ Trust the root SSL certificate
• Story 3: Install a web server like apache or express o Points: 8
o Description: As a developer I want a server so that I can run my application and serves HTTPS
o Tasks
▪ Install Apache server using XAMPP
• Story 4: Create a separate virtual host as proxy for web server o Points: 13
o Description: As a developer I want a server so that I can run my application and serves HTTPS
o Tasks
▪ Install Apache server using XAMPP
• Story 5: design a card type data structure o Points: 2
o Description: As a developer I want to model a card type data structure o Tasks
▪ Design a JavaScript object called card
▪ Add card Type attribute to this card object
• Story 6: create an iframe to place a card type form
o Points: 5
o Description: As a developer I want to create an iframe to place a card type form
o Tasks
▪ Create an iframe to with a dropdown with the type of card
▪ Add a button to submit selected card type
▪ Add a button to reset card type
• Story 7: Allow to get and set card type data by mean of a REST o Points: 8
o Description: As a developer I want to post and get the card type in Trello using its REST API
o Tasks
▪ Create a query to execute post and get methods
▪ Authenticate the query to REST API
▪ Map the response in JSON to a JavaScript object
• Story 8: create data structures for board cards and lists o Points: 3
o Description: As a developer I want to create data structure to save information about the board, the array of cards and the array of lists in the board
o Tasks
▪ Design a JavaScript object for Board
▪ Design a JavaScript object for Cards
▪ JavaScript object for Lists
• Story 9: get information of cards and board when is available o Points: 2
o Description: As a developer I want to implement an asynchronous object to get data about board and cards
o Tasks
▪ Create a callback function or a promise for board object
▪ Create a callback function or a promise for cards arrays
• Story 10: create a feature to associate cards in a parent-children relationship
o Points: 13
o Description: As a developer I want to create a parent-children relationship and show the status
o Tasks
▪ Identify cards
▪ Allow to input the number of the father card
▪ Show the parent card ID in the children cards
▪ Update the status of the relationship in the parent card
ii. Design Models
To run a power-up it is mandatory to do it over HTTPS. The certificate should be based on an RSA-2048 key to enable maximum confidentiality. This is related to user stories 1 to 4.
We proposed a couple of data structures to extend the framework awarding system this task is related to user story 5.
A typical card object should have an ID, a card type, a current list ID, a creation a Boolean flag to indicate if it was place on the sprint backlog and the sprint number. See figure 10.
Card +cardID +cardType
+placed +sprint
FIGURE 10 CARD CLASS DIAGRAM
We also designed the appearance of the card. It should include an icon to identify card type by the first letter of the word, as shown in Figure 11.