With the requirement document from product owner, the team analysed the requirement and categorized them based on the priority which is prioritized by product owners. At the beginning of the development process, communication between development team and product owner was significant value in order to deliver the desired product. User stories are used as a mean for reflecting all requirements of Peter’s point of view. The development team could ensure that the desired product will be developed without missing any important values as well as the team could articulate all product functionality. In addition, the user stories also facilitate the clarity communication of the team with product owners in simple languages. The users could use success criteria of each user story to test either the feature is met the requirement.

At the beginning, the team drafted some user stories based on the initial understanding. Below are some evidences: Example:

However, the above version is too general and complicated, difficult to understand, not specified to the requirement of product owner, the success criteria was not clarity. Then, the team rewrote as well as stick to the recommended format “As a , I can <goal/need> so that ”. Below are some of user stories after rewriting: Example:

We expected that after rewriting, the user stories should be heard the requirement of product owner and could be used for well communication, but we received solid feedback that the written language is technical which is very difficult for product owner or stakeholders to understand. Then we updated some languages and sentences again in the user stories. Below are some of them:

As following the format of user stories “As a , I can <goal/need> so that ” for communication between product owners and development team. The specific requirement can be captured in the general language. Success criteria is the most important indicators whether the user stories are testable or not. The success criteria should be written in a testing point of view and not be more than five criteria for a story otherwise the story need to be separated. For instance, the non-testable user story is “As a searcher, I want to get the result of searching articles very fast”. This example could be rephrase to “As a searcher, I want to get the result of searching articles less than 30 seconds after hitting the search button”.

In accordance with requirements as well as product backlogs from the product owners, a mock-up was created to show how the search screen of SERLER look like, result of search could be displayed and possible interaction among different users and product. It is essential for obtaining mutual understanding with team members as well as product owner. During the development stage, the mock up was used as a guide for programming the layout of search screen, list of data fields, operators and filter parameters to be placed. It helps the team to ensure that all required data attributes are implemented as requirements.

Four main user types for SERLER repository (submitters, moderators, analysers and searchers). Submitters could be any registered user that he/she could submit articles into the SERLER. One of the most significant characters of submitters in general is that simply process of article submission is desirable as well as key elements of articles are well uploaded into the repository without errors. Consequently, the status of submission must be notified shortly. These preferences influenced the team to critically think the design of user interfaces (UIs) to make sure that submission layout and processes are simple for all different background of submitters.

Moderators is a type of users to use SERL repository in validation process to ensure that the quality of articles is valid. One of the important character of moderators is that he/she prefers the submitted articles are automatically informed, placed in the queue, rejected or ready or analysts to process. He/she should be able to retrieve, perform checking quickly. The moderators’ point of views could significant help the team to design the back-end tasks of the SERL. One example of the back-end task is that SERL need to be designed how the auto rejection could be done when the old rejected articles are resubmitted by submitters.

Analyst is a type of SERL users to handle the data extraction once the articles are passed by moderators .He/she values the information identification of articles either in auto or manual way before appending into the SERL database. These requirements help the team to critically think about the design of input screen as well as storing appropriate values in the drop-down list in order to facilitate the analyst for data appending process. Searchers is the main target end users of SERL. The most significance of searchers is about retrieving the desired articles from the SERL quickly and less effort. With this value, the team spent the most effort on the design of searching screen and identification the elements of articles in order to display on the search screen. The team considers

These are some of the non-functional requirements in the product. Some of them were implemented.

1.Responsive user interface. When changing the size of the window of the browser or accessing the product from a mobile device, the main application menu transforms according to the used viewport size. This feature was tested by accessing the product through mobile phone. However, the test was failed due to some bugs need to be fixed.

2.Saving the state of all controls while switching between pages. This feature is planned to test by login the system and perform the switching from first page of product to second page. Then switch back to first page again. All the previous control status of the first page must be remaining the same.

3. Not using cookies. All saving logic has been implemented using the browser local storage. So the product does not have the privacy problems related to using the cookies. The feature is planned to test by login the SERLER with user name and password. After logging out the system, then check the cookies on the server site. The personal information must be not stored on the cookies.

4.User-based security. Because of the existence different kind of users of the product is necessary to implement user-based story. Working on the project we have not got user stories about security, but multi-user mode has been claimed in the description of the product. We include user-based security on preparation phase (before Sprint1) because embedding the feature on the late stages is problematic. This feature is planned to test by login to the system in different role of users. The appropriate features should be visible to each user role.

5.Availability: the SERLER must be accessible 24/7. Business continuous plan is documented and it has to be regularly tested. This feature is planned to test by running the SERLER a week up to 24 hours in a day. The system log need to be check to ensure that no interruption incur during the day.

According to the actual progress of product development and how team work together, top three risks are identified due to they have delayed the success of product development.

Using development tools: A number of the development tools is new to the team although who already has some good programming language still encountering some issues during the coding and taking time to figure out. Learning new tools (frameworks), understanding built-in libraries of tools as well as make use them in the product development is really the critical issue. For instance, NodeJS, React, MongoDB, Travis CI, Heroku and some testing tools like cucumbers. The integration between these tools in order to make the product works is another critical time consuming and delay the process. In order to mitigate this risk, as one of the team members is good at using these tools, he may spend time to give quick explanation as well as demonstrate how to use these tools. One or two hours should be spent with teammates to illustrate how the tools work and make use its libraries. This could build the fundamental understanding for the teammates then he/she could continue himself-learning.

• Communication: It is true that many tools are used for internal team communication as well as communicate with product owner. However, online communication is not enough to have same understanding especially among teammates. It is difficult to understand each other when writing somethings in different English writing style. Different teammates has different level of English writing ability. It is hard and spend more time to obtain the same understanding for a story. Some technical terms are more worst and sometimes unable to understand each other via online communication scheme .To improve the communicate in the team, more face to face communicate is required. The body language and giving example during explanation could help to obtain the correct understanding.

• Time constraint: with the limitation of teammate capacity on using the new development tool and communication for product development, the longer time is necessary for development the product to meet the first priority of product owner. In addition, every teammate has another assignment from other papers which have to complete simultaneously. It seems to be the big issue to schedule the right time for everyone. To improve this, a time management strategy is requires. Teammates should share tasks of other papers with expected time consumption and completion date, then plan together how to allocate times for SERLER product development.

Despite not all risks were figured out during the development, some of them were improved. Using the new development tools was better progressed after obtaining the explanation and exploring different ways of explanation from internet. For instance, using the cucumber for unit test, the teammate could configure the cucumber framework with selenium to do the unit test for front-end of the product.

• Communication: After spending more time on face to face meeting rather than online chatting in the sprint review as well as retrospective, teammates can gain better understanding on how to work as a team. Some limitation of a teammate was improved and could contribute to the entire team’s effort. For instance, one of the tasks was about data uploading for the mock test. Some articles were loaded into the database by using executing the prepared java script files (study-service.js)

• As the earlier stage of the development, the team had different available time and impact the scheduling of face to face meeting. Later on after sprint 2 review with PO and lecturer, the face to face meeting was conducted more than an hour. For instance, the sprint planning meeting for sprint 3 was held more than an hour and the meeting produced the final list of user stories for the sprint 3 and submit to PO.

One of the obstacles during the daily planning was about availability time, the matching available time is one of the main issues for team to commit the completion of project tasks. To solve this problem, teammates had sharing dedication and help each other to solve some assigned tasks. For instance, Stone and Oleg spent the most effort to the product development as both of them have good programming language skills, while they also guide Chris and Khounkham to complete some of the assigned tasks (mock data preparation and Unit test). One of the “standing up meeting” concerns is about how to deliver the high priority feature of product, entire requirements were written as user stories but insufficient time to implement them, whereas team should focus on development the highest priority requirements of SERLER. To overcome this problem, team review the feedback from the lecturer and then re-prioritized the highest user stories for development.

More frequent face to face communication between development teams and product owners, the more risks could be mitigated. It is essential to have quick process of development, and seek feedback from product owners or even fast failed then fast fixed. In order to be avoid off track the main purpose of PO, the team has to bear in mind that what is the most value of product owner. This could definitely guide development to be on track and do not miss the core part of product. For instance, in the first sprint review meeting with PO, the team present the login screen of the SERLER which is not stated in the product backlog. This misunderstanding was solved after PO pointed out that the team MUST deliver the core value of the product as priority rather than others.

• Daily communication helps all members of the team understand the objectives and scope of the entire system and function. If the project has been started, but the team does not understand the objectives and scope of the whole system and function, and does not reach a consensus on the requirements of the system and function, the direction of project development will gradually deviate with the passage of time. To make the team reach a consensus, we cannot do without the communication and cooperation of each role of the team.

• Daily communication can promote team members to help each other and solve problems. A member of the team has a problem. He can ask for help in the team and save a lot of time. Team members can solve problems together and learn a lot from it.

• Planning meetings can help teams plan and assign tasks for the next sprint. At the start of a new sprint, the team holds a planning meeting to plan the tasks to be completed in the sprint and assign them to different members.

In addition to hosting our code, the main attraction of GitHub is that it is a collaboration tool.

• Pull requests are a good way to contribute independently to the repository. Then we can send a pull request to merge our code changes.

• Each repository can create GitHub wiki, making it easy to put source code and documents in the same repository. We use GitHub Wiki to store our files and data, such as team agreement.

At team meetings, if everyone is involved in the discussion, we are more likely to reach a consensus.

• From the first meeting, we reached a consensus that participation is not only welcome, but also an integral part of the decision-making process.

• We would like to thank each team member for every participation. Each of us will respond accordingly to show that we have heard and understood each other's contributions, such as "I'm glad you asked this question" or "this is a good proposal" to praise others. In addition, team members also use some non-verbal ways such as eye contact and nodding to thank team members for their participation.

Our main purpose is to learn and practice, so everyone is not limited to a specific role. Each team member can play any role, including project manager, developer, tester and scrum master. This means that everyone on the team can write user stories, code, test and even organize meetings. For example, if a member of the team needs help from other members on some work, he or she may need face-to-face communication. Then he or she can suggest a team meeting.

We clearly know that in order to reach an agreement, the team must have a discussion guideline or guidance. Therefore, at the first meeting, we agreed on a set of guidelines for making decisions:

• Listen to others
• Don't interrupt.
• Ask clear questions
• Welcome new ideas
• No personal attack
• Treat every contribution as valuable

We adopt consensus based group decision-making method to reach consensus on decision-making. Consensus based group decision-making is a cooperative process, in which each of us proposes or supports a decision that best suits the whole team. The group discusses as many alternatives as possible until all team members agree on a "final" solution, even if it's not everyone's favorite.

When there is a conflict or disagreement in the team due to a decision or proposal, we will listen to each other's opinions, give each other enough time to express their opinions, and then give our own opinions or opinions accordingly. Try each other's proposals in a friendly manner. In fact, team members are making progress in dealing with conflicts and disagreements.

The use of team agreements improves our communication and collaboration efficiency, reduces communication costs and errors and misunderstandings, and ultimately brings us efficient team work.

For example, face-to-face meetings. Our team agreement provides for at least two face-to-face meetings in a sprint: sprint planning and sprint review. This agreement saves us the energy to discuss the meeting time and purpose.

We also have an agreement about user stories. The team decides which stories to develop in the current sprint based on the story priority. This agreement allows each team member to have a clear understanding of the current sprint development sequence, eliminating unnecessary questions and communication.

Code Craft

Capability with Tools