LabSync – Simplify the lab testing procedure by Inspectorio

About the Business

Customer Segments

Our customers include Brands, Retailers, Suppliers, and Factories, with a primary focus on those who sell/produce apparel, hard goods, and soft goods products. As we already have an established customer base for other mature products, we primarily target this customer group.

Value proposition

The existing lab testing procedure lacks organization, with each vendor/supplier typically working with multiple internal and external labs to ensure product requirements are met for the brand/retailer or importing country.

Our solution standardizes lab testing data points, which are typically collected and stored differently by each lab, and centralizes test requests and reports in one place. By standardizing and centralizing data, we’ve created an analytics module enabling users to gain valuable insights into the testing process. This is a feature that has not been available to users previously.

Key partners/stakeholders

We work closely with multiple clients to understand their pain points and requirements. We also collaborate with Labs to gain insight into their processes and system, which helps us to integrate our solution. Additionally, we partner with various product teams and supporting teams within the company.

Revenue streams

Our product is subscription-based, with customers paying for each user subscription. The subscription price varies depending on the package chosen, which includes Standard, Professional, and Enterprise options. Our solution adds significant value to the company’s product suite, increasing the overall value of our quality management products, indirectly boosting the value of our other offerings.

My role as a Business Analyst

At Inspectorio, I was fortunate to have had the opportunity to work with multiple clients and product teams on a large scale. Some of my key responsibilities included:

• Facilitating the Scrum team
• Leading a team of six developers, two QA testers, and one designer from diverse backgrounds and facilitating the Scrum team.
• I hosted sprint events, including Daily Standup, Review, Retrospective, and Grooming sessions, ensuring the team was well-coordinated and on track to deliver quality features on time.
• Preparing Product Requirement Documents for new features/tasks and validating them with customers while collaborating with designers and copywriters.
• I also supported the Scrum team by testing newly released tickets on Feature Branch and Staging environments and preparing release notes for sprints.
• Prepared the release note every sprint and every month for the new features
• Planning the product roadmap with the PM and creating a prioritization framework using the WSJF. This framework helped us to organize client feedback and prioritize features and functionalities needed for the product to meet clients’ needs.
• Acting as a bridge between the team and the customer voice and improving the team’s workflow to work more effectively and efficiently.
• Improved the workflow of the team to work more effectively and efficiently.
• Working with Customers/Clients
• Conducting pilot testing and discovery meetings with global brands and retailers, such as Target, DICK’S Sporting Goods, and Crocs. This allowed us to gather feedback and tailor the product to meet their specific requirements.
• I prepared surveys for pilot testing, summarized/analyzed the feedback, and gained insights for product enhancements.
• Collaborating with the Target team to integrate LabSync with their system, harmonizing processes and data points of four lab test agencies. This ensured seamless integration between LabSync and their existing systems.
• Conducting several demos of LabSync, showcasing its capabilities to potential clients. Demonstrating the product’s value resulted in generating interest from potential new clients. It’s worth mentioning that demos were sometimes conducted outside of typical working hours to accommodate multiple time zones.
• Collaborating with the marketing, sales, and customer support teams to facilitate their respective duties. This ensured that the entire team was aligned and working towards common goals.

How I built LabSync

The product was built using the Agile methodology and the Scrum Framework. Let’s dive into more detail below.

Team structure

Fortunately, we have a robust and well-structured Scrum team in place, comprising of various roles. Let me introduce you to each member of our team:

• 1 Product Manager: He is the visionary behind the product and oversees all the goals and roadmap of the product. With his guidance, we ensure that we are heading in the right direction and meeting the expectations of our internal and external customers.
• 2 Business Analysts:
• I and another BA take care of the lower level of product development. We specialize in understanding user requirements, capturing user stories, breaking them down into smaller tasks, and prioritizing them.
• Working closely with the developer team, we facilitate Agile ceremonies such as Sprint Planning, Daily Stand-Ups, Retrospectives, and Sprint Reviews.
• We also discuss with the PM about the product roadmap and quarterly goals.
• Engineering teams: We have two squads, each led by a BA with four team members. Within each squad, we have:
• 1-2 Front-end developers: They specialize in developing UI/UX that aligns with user needs and product vision.
• 1-2 Back-end developers: They are responsible for building and maintaining the product’s backend functionalities, architecture, and scalability.
• 1 QA: He/she verify release features, track bugs and ensure product quality.
• Scrum Master: Our Scrum Master is a coach, facilitator, and mentor. She doesn’t involve much in the day-to-day activities but occasionally hosts training sessions about Scrum principles, practices, and methodologies to help the team work more effectively. She also acts as an enabler by removing impediments and ensuring the smooth progress of the team.

Product Backlog Preparation

Our team typically follows a 2-week sprint cycle, starting on Wednesday and ending on Tuesday. The reason we decide to start a sprint on Wednesday is because team members are more likely to take a day off on Monday or Friday to extend their weekend. Additionally, we’ve found that Monday can often be a slow or unproductive day, whereas Wednesday allows everyone to hit the ground running for the new sprint.

Before a sprint start, I am responsible for collecting user stories for each sprint cycle. I gather these from a few different sources:

• Client’s request: The product was still young so there are a lot of feature gaps. We review all client requests and prioritize based on severity and the client’s importance to our business.
• Product roadmap: These are the big features that we have planned for the quarter. Based on the timeline, we’ll pick what to do next.
• Team OKRs: Each team member is assigned a few OKRs to enhance product performance (not just building new features), which we should include in our sprint as well.

When preparing the PRD for new features, I work collaboratively with our designer and copywriter when needed. If a feature requires minor changes to the UI/UX, I update the design myself. For more complex features, I schedule a design meeting to discuss the proper design with our team’s designer. We then go through a few design iterations to finalize the design.

In certain cases, I will also involve the copywriter to help with the text on the design. In these scenarios, I invite them to the design meeting, but I am careful to walk them through the use case and user story slowly and clearly. This ensures that everyone involved understands the project’s objectives and requirements.

It also worths noting that, the earlier we involve our developers in this stage, the fewer changes we would have later on. Hence, I usually as for the comments from 1-2 developers before a move on to the next stage.

The output of this stage is the ‘Awaiting for Refinement’ tickets. These tickets should be aligned with the team’s Definition of Ready, which includes:

• Has the Business Background
• Has the User Story
• Acceptance criteria are well-defined by the Given-When-Then structure
• Ticket is peer-reviewed within product team
• And more.

Sprint grooming

During a sprint, we would have grooming sessions for ‘Awaiting for Refinement’ tickets. By holding these grooming sessions regularly, we can ensure that our team is always up-to-date on the project’s status and that we are prepared for any upcoming workload. Prior to each grooming session, I share a list of all the upcoming tickets with the team to review in advance.

During the grooming, I would go through one ticket at a time, and explain it in detail. We would discuss any questions or concerns the team may have. If necessary, we update the Product Requirements Document (PRD) to ensure that everyone is clear on the specifications and requirements. Once we have a clear understanding of each ticket, we use Planning Poker to estimate the ticket’s complexity and workload. I like this method because it allows for anonymous voting, which ensures that team members won’t influence each other’s votes.

Daily Standup

To keep everyone on the team informed about each other’s progress and any potential blockers, we hold daily standup meetings during sprints. These meetings typically last no more than 15 minutes and are hosted by our Tech Lead.

During these meetings, we check the sprint goal progress. Each team member provides an update on their progress, highlighting any potential blockers they may be facing. This allows us to address any issues as a team and ensure that we are working efficiently towards our goals.

If any issues are raised during the meeting, Business Analysts are available to jump in and provide assistance in resolving the issue. Additionally, we can provide business updates that may help the team better prioritize their workload.

Sprint Review

The Sprint Review is hosted at the end of the sprint. During this ceremony, I present the team with sprint statistics, including actual versus completed story points, velocity, burn-down chart, and bug rate. This allows us to assess our progress and determine any areas where we can improve.

After that, we move on to the demo, which is undertaken by a team member who has been appointed in advance. During the demo, team members are encouraged to ask questions about the feature being presented to ensure that everyone has a clear understanding of the project’s objectives and requirements.

Retrospective

Immediately following the Sprint Review, our team holds a Sprint Retro meeting. During this meeting, we discuss what we did well during the sprint, things we should stop doing, and new ideas that we should consider implementing in the upcoming sprint. Rather than relying on fancy tools or complicated software, we have found that using a simple and intuitive tool like Miro keeps the focus on the content of our discussions.

Sprint Planning

This meeting typically begins immediately after the Retro. During the meeting, I present the goals for the upcoming sprint. These goals are stated as objectives, such as “Supporting integration with the Labs”. Once the objectives are established, we select the relevant tickets needed to achieve those goals.

The Tech Lead generally leads the latter part of the meeting. Based on the estimated story points and team velocity, the Tech Lead selects just enough tasks for the team to fulfill the sprint objectives.

Achievements

Within 6 months, I and the team were able to achieve the following results:

• Launched LabSync, starting from an MVP state, and secured Target and Crocs to join the Dry run/Pilot Test before making their final decision to adopt us. Target, with about 5000 vendors/factories, and Crocs, with about 100 vendors/factories.
• Demoed LabSync for more than 10 clients with multiple vendors/factories, triggering their interest in adopting our software.
• Defined the harmonized online test request form, saving vendors’ time and money compared with traditional offline methods by ensuring the accuracy of information.
• Gained expertise in API integration and documented the GET, POST, and PUT APIs for lab agencies. This research and documentation translated to easier integration with lab agencies, increasing LabSync’s efficiency and speed of operation.

And the biggest personal achievement is the love from my colleagues.

“I think you’re exceptional at what you do. I can honestly say that with your enthusiasm, proactiveness, and the speed at which you learn and adapt, you have potential far beyond most. Inspectorio made a mistake by letting you go.”

Alex Ryan – Technical lead – Senior Software Engineer @ Inspectorio

Key takeaways

Here are some lessons I learned from this awesome position:

• Working with top-notch clients from around the world requires excellent communication and negotiation skills:
• Communicating across different time zones and languages can be challenging. To ensure effective communication, we had to find ways to make it more efficient, such as scheduling meetings twice to accommodate the Asia and Western teams. It was also crucial to make sure everyone was on the same page to avoid any misunderstandings.
• Negotiating with big companies that have cumbersome procedures and many requirements requires a great prioritization framework. It’s essential to ensure that the requests received are industry-generic after negotiating and fulfilling all the necessary requirements.
• When doing demos for clients, we must communicate with them using their terms. As it’s often the first time they see the platform, we should explain the details slowly and carefully, like talking to a baby. By doing this, we can ensure that the clients understand the platform’s capabilities and how it can help them.
• Developers should be involved in the early stages of product development, such as customer interviews and designing, and not just coding. By involving developers from the early stages, we can utilize their expertise and potential fully.
• Collaborating requires clear alignment on all aspects of the project in advance. We can use the 5W1H method to ensure that everyone is aware of the goals and the specifics of the project to avoid any issues down the line.
• To prepare an effective PRD, we can use a checklist to ensure that most of the essential details related to grooming the team are covered. Doing this helps maintain clarity throughout the development of the product and allows for more efficient progress toward the final product.

‍