Medical Appointment Booking System

The business analyst, in cooperation with the software architect, finalized the functionality set for the project. Generally, the BA covers the business needs while SA ensures the feasibility of the technical implementation of the corresponding functionality for the medical appointment app.

All the project-related activities were entered into JIRA and Confluence. These tools were used to keep track of software development processes.

The documentation was placed in Confluence for one common knowledge base and access was shared with the client.

The functional specification was adjusted a couple of times during the project development. This was due to some changes in tech requirements and some misinterpretation of a few necessary features.

The major task was to create an online appointment booking system with doctors and medical centers that would be very convenient, quick, and intuitive for patients. Either way, the user should be able to find a doctor first or select the medical service, or even check the available time slot for a doctor consultation.

The approved visual interfaces and the functionality described earlier helped our BA to reevaluate functionality requirements and reorganize priorities. As well, our BA created a project mindmap in the Coggle tool that outlined system functions across all user roles (patient, doctor, admin).

For a project of similar scope, it is necessary to properly plan the database structure, plan the cases of information transferring and recording to the database, and prevent any data misuse (control the process of who is going to add new data and when).

The software requirements and objectives that have some significant impact on the architecture are as follows:

Our SA planned to use our standard tools and tech stack for the system architecture since this combination has great performance, which was suitable for the project.

The architecture applied the 4+1 model, which describes architecture if there are multiple and concurrent users. The system combines many views, dynamic and static aspects, and makes the documentation complete and consistent. The system can be illustrated from the view of different project stakeholders like end-users, developers, and project managers.

In addition, the chosen use cases (scenarios) serve as an extra view of the architecture. These scenarios describe the order of the interconnection between objects and processes.

Based on the functional specifications, our UX/UI Designers, in cooperation with the Business Analyst, created a software interface for a medical appointment app on mobile and web platforms simultaneously. The design style was approved earlier during the preparatory stage and was followed throughout the Discovery.

The Business Analyst, who was engaged in structuring the final product backlog, always worked 1-2 days ahead. This allowed the designers to receive the approved functionality and continue working on the web and app interfaces.

There were minor adjustments during the design phase since our team was able to match with the client's vision right away. All the design deliverables were created in Figma.

The design deliverables consisted of the client part (iOS, Android apps), doctor web, and admin web part.

The PM set up a calendar and invited the client to the daily scrum meetings, which were held each day from Monday to Friday at 5 pm.

Each sprint started with a Sprint Planning meeting. Aside from sprint planning, from the second week on, the team had a retrospective meeting lasting around 2 hours. In this meeting, the team clarified new requirements if they appeared, specified the old requirements by taking new data into account during the project implementation process, and updated these dependencies, connections, and blockers to keep the documentation up to date and prevent further issues.

All these factors allowed the development team to clearly understand what was required of their work and organized the teamwork effectively.

The development stage was divided into 2-week interactions involving a cross-team (frontend, backend, mobile developers, QA engineers, Business Analyst). As well, we created a specific UAT environment precisely for the client to check the results after each sprint.

During each sprint, our team added a new piece of completed work (an increment) to the UAT environment, which was previously tested by QAs. Then, we conducted the internal demo to validate if everything worked accordingly and further presented the updates to the client along with access and the list of test cases to complete for user-testing.

The client usually had 2 weeks to work with this environment and provide us with changes, bugs, and similar feedback.

In the end, we summarized how many cases passed and which did not pass, how many were approved but with a comment, defects relieved, and so on. This information was taken for the client report and served as a basis for the next sprint planning meeting.

Since the service is complex and there are lots of interconnections among functionality and users, our PM, along with the team, groomed through all of the project backlog, and defined which tasks appeared to be blockers and which were enablers.

Furthermore, the PM created a scheme where these dependencies were shown (Gantt chart). Let’s say if feature A is not completed, feature B cannot be started.

This allowed the developers to work on the most necessary functionality (blockers) first, set priorities, plan the development efficiently, and not block other members of the development team.

The PM was directed to check on any possible improvement, identify any weak points and bottlenecks, and pursue the goal of creating a pleasant working environment for all team members.

All the communication with the client was mostly held by the Project Manager and the Demo of the completed work was presented by QA engineers. Our PM had regular project status calls with the client, where they discussed the delivery metrics of the completed sprint.

After the sprint, the PM provided a detailed report on the project consisting of the following information: