Glossary

24/7 support

A passive support structure where the passive support window is defined as 100% of time.

Acceptance criteria

Requirements set by the client and agreed to by the HTD team. Can be in relation to the whole product, epic, user story or other items.

Agile framework or approach

Agile is an iterative approach to project management and software development. An agile team delivers work in small increments delivered through sprints of one to two weeks. The agile approach leaves room for flexibility throughout the course of a project.

Agile Leader

The HTD manager responsible for each project’s success. The Agile Leader oversees team work, mentors team members, and helps the team make strategic decisions throughout the course of a project. The Agile Leader is the first escalation point in case of issues and is responsible for making sure the problems are resolved.

Bug

A bug is an unexpected problem with software or hardware.

Clickable prototype

A Clickable Prototype shows a visual representation of the user interface of a website or software application. Unlike static wireframes or mockups, it can show several states of the application—for example, a drop-down menu, or initially hidden additional information or fields that may appear. It can contain and combine multiple screens into a flow.

Debugging

Debugging is the process of finding and fixing errors or bugs in the source code of any software. When software does not work as expected, developers study the code to determine why errors occurred.

Definition of Done

The definition of done applies to a user story at the scrum team level. A user story is considered done when all the acceptance criteria are met and the product owner reviews and accepts the user story.

Definition of Ready

The Definition of Ready is a set of agreements that let everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint.

Delivery Manager

Manager and a part of HTD Leadership responsible for HTD project portfolio. Delivery managers are the second level of escalation in case of project issues. They oversee the work of multiple teams and Agile leaders and are focused on all aspects of customer success.

Delivery Phase

The phase of the product life cycle that usually starts after the discovery phase and is followed by maintenance. This phase is usually the most intensive and leads to the design and development of the majority of product features.

Development environment

The development environment might include local development (also called DEV), staging (also called STAGE), and a live production environment (also called PROD). Together, the entire ecosystem supports the process from end to end and allows development team members to work on and test changes without interrupting the live experience of end users. Number and types of environments will vary depending on specific use cases.

Figma

Figma is a design platform that helps with designing websites, applications, logos, etc. Figma is used for product UX/UI design in most HTD projects. Website: https://www.figma.com/

Fixed price

A fixed cost pricing model requires defining a project scope, team, and cost upfront before work begins. This model for software delivery is less flexible than an ongoing time and materials engagement which can make it a poor fit for new products that likely need to adapt to user input and initial learnings when going to market. In a fixed cost project, any changes will require additional estimation and change orders amending the original SOW which can be cumbersome and can result in additional cost.

While less efficient on the basis of cost of implementation of each feature, this method has lower risk of budget expansion and can be a good choice for implementations that require very strict cost controls or are funded by grants or one time line items.

FTE

Full-time equivalent (FTE) is a unit of measurement that indicates the workload of an employed person. It is equivalent to one team member’s 40-hour week at HTD.

GitHub

GitHub, Inc. is an Internet hosting service for software development and version control using Git. It provides the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration, and wikis for every project. Git is used to store the source code for a project and track the complete history of all changes to that code. Website: https://github.com/

Happy path

A singular flow from the application (e.g. onboarding, scheduling, payment, or care plan creation) that presents potential user paths, going through a part of the app without focusing on edge cases, validation, or other potential obstacles.

HTD Discovery process

A user-centric and iterative process used to identify, define, and validate product ideas and features, taking into consideration target group needs and pains, business goals, market context, and technological opportunities. It consists of two major phases: Strategy Discovery & Scoping Discovery. The discovery process in most cases serves as a preparation for the Delivery Phase to make sure we have a plan for key decisions to be made using available resources in the most efficient way.

Jira

Jira is a task management platform that is widely used in the software development field for workstream planning, bug tracking, and agile project management. At HTD Jira is used to define and distribute work, store product backlogs, automate team metrics and much more.

Kick-off

A kickoff meeting is the first meeting with the project team and the client of the project. This involves defining the base elements for the project, introducing the roles of team members, and other project management activities (schedule, status reporting, etc).

The kickoff meeting includes a summary of project goals agreed upon by HTD and our client stakeholders. By displaying and discussing goals and steps on how to reach them, the team (HTD + Client) can align on how best to deliver the work. Kickoff indicates the work has started.

Local (environment aka Dev)

A local (DEV) development environment is a suite of software applications that developers store locally – meaning the application running there is on the engineer’s computer or device. This allows engineers to work on developing software or websites without a hosting service or an internet connection.

Maintenance

Software maintenance is the modification of a software product after the delivery phase to correct issues and improve performance. This is usually a phase of work after active development when the team is focused on maintaining proper performance of the product, rather than implementing new features. In most cases, this is a much less work-heavy period of the product life cycle. Maintenance work can be coupled with ongoing enhancements to the product, platform, or application.

MVP

A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development. It is customary for new companies or products to go to market with an MVP in order to demonstrate product market fit and gather impressions from initial users before adding features.

North Star workshop

A North Star Workshop focuses on defining crucial flows in the product (usually presenting unique business value – a North Star product) and then presenting it as a happy path in the form of a high-fidelity clickable prototype. Such prototypes are a mockup of the flow, usually not ready for development, with generic branding, focused on marketing purposes.

Passive Support

The availability of HTD employee(s) to support issues with software products. This usually covers partner business working hours or windows that are particularly critical in the customer’s business. During these passive support windows, the HTD team maintains an “on call” rotation that ensures someone is available to respond to issues as they arise. The response time while responding to issues that arise during passive support windows should be defined in the statement of work which describes the passive support service.

Product Roadmap/ Plan

A product roadmap is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time.

Product Strategy Discovery

The process of defining product strategy, including understanding target groups and identifying new business opportunities. The ultimate goal of strategy discovery is to make high-level hypotheses on potential solutions that can address users’ needs along with business goals and technical possibilities.

Production (environment)

The production environment is where the latest versions of software, products, or updates are available live for the intended users.

Proof of Concept (PoC)

A proof of concept (PoC) is a demonstration of a product in which work is focused on determining whether an idea can be turned into a reality. A proof of concept is usually a small piece of work, which may or may not make up part of a final product.

QA/Testing (environment)

The QA environment is where the build is deployed so that QA engineers can test the existing functionality, log bugs, and retest fixed bugs.

Response time (usually in relation to maintenance and support)

Response time refers to the time taken by the HTD team to get familiarized with an inquiry or issue, process it, and then respond to it. Response time does not mean that something is going to be fixed or implemented within the response time frame.

Risk

Project risk refers to any unknowns that may affect a project. This may be related to people, processes, technology, and resources. HTD always tries to present project risks upfront to keep stakeholders aware of unpredictable elements that may impact project delivery.

Risk matrix

A risk matrix is an analysis tool to assess risk likelihood and severity during the project planning process. Once you assess the likelihood and severity of each risk, you can chart them along the matrix to calculate risk impact ratings.

Risk probability

Risk Probability is the determination of the likelihood of a risk occurring. This likelihood can be based on historical project information or it can come from interviews or meetings with individuals who would have knowledge of the probability of risks occurring.

Scope

Scope can refer to either product scope or project scope. It’s important to know the difference:
– Product scope is defined as the functions and features that characterize a product or a service
– Project scope is the work that must be done in order to deliver a product according to the product’s scope (required functions and features).

Project scope is the common understanding among stakeholders about what goes into a project and the factors that define its success. This is typically what’s described in the Statement of Work.

Scoping discovery

Process of defining the final shape of the Product including the system architecture, user experience, and scope of work to be implemented. This discovery phase also results in a project plan for how HTD will deliver the given scope with a set timeline and team.

Scrum & Scrum events

Scrum is an Agile framework used in software development. It consists of Scrum events, such as daily standups, retrospectives, or sprint reviews—each serving very specific purposes. More can be found in the Scrum guide: https://scrumguides.org/index.html

Sprint

In Agile product development (especially Scrum), a sprint is a set period of time (usually 2 weeks in HTD) during which specific work has to be completed and made ready for review.

Staging (environment)

A Staging environment is the last step before software goes into production. A staging environment’s main purpose is to ensure that all new changes deployed from previous environments are working as intended before they hit the production environment.

Statement of Work – SOW

SOW refers to a transactional document (which may also be called “Work Order”, “Statement of Work” or “Scope of Work”) that is entered into by and between HTD Health and a Client. The document defines the scope of work to be completed, project deliverables, timelines, work location, payment terms and conditions, and others. This is formally defined in our Master Professional Services Agreement.

System Architecture

System architecture describes the behavior of applications used in a business, focused on how they interact with each other and with users. It is focused on the data consumed and produced by applications rather than their internal structure.

The system architecture is specified on the basis of business and functional requirements. This involves defining the interaction between application packages, databases, and middleware systems in terms of functional coverage. This helps identify any integration problems or gaps in functional coverage.

System architecture tries to ensure the suite of applications being used by an organization to create the composite architecture is scalable, reliable, available, and manageable. System architecture defines how multiple applications are poised to work together. System architecture is presented in the form of technical designs of how a system is built.

Tech Lead

Usually the most experienced / knowledgeable developer on the team who ensures appropriate architecture setup, helps make decisions with the client about third party tools and libraries, performs code review for less experienced team members, and provides support to whole team as needed.

Third-party services

Any paid or non-paid services used in product development – this might include cloud services (e.g. AWS), code repositories (e.g. GitHub), or a wide range of digital health SaaS solutions including EMRs, clinical workflow builders, messaging services, revenue cycle management solutions, etc. While these third-party services are not built or maintained by HTD, our team often works with clients to make selections and integrate these disparate solutions into one system.

Time and Materials (T&M)

Time and materials (T&M) is a type of contract where the price reflects the actual time spent by the HTD team working on the project based on hourly rates and the resources used in the process (if any). This is the most typical project arrangement, especially for new technology projects that benefit from a more iterative, agile approach.

UAT (User acceptance testing) environment

Development environment where certain states of application are available to the client, users or other important stakeholders to test the system. The environment typically closely mirrors the production environment.

User flow

User flows illustrate the experience of using an application or product, mapping out steps and actions the user takes through screen designs. It is typical early in a project to design just a few core flows that represent limited paths through an application (e.g. user onboarding flow or checkout flow) before designing all screens and all states required for development.

User Interface (UI)

User Interface (UI) refers to the screens, buttons, toggles, icons, and other visual elements that a user interacts with when using a website, app, or other electronic device. Designing the UI for a new product typically involves creating a component library in design software like Figma to ensure that these elements are consistent across each screen or device. Designing with reusable components also saves time during the development phase of work.

User journey mapping

User journey mapping is the process of visualizing and documenting the steps that a user goes through in order to achieve a specific goal. It helps to identify the pain points and areas for improvement in the user experience and can be used to inform the design and development of products, services, or digital experiences.

The process typically involves creating a visual representation of the journey, such as a flow chart or diagram, and may involve interviews or other forms of user research in order to gather insights.

User story

In software development and product management, a user story is an informal, natural language (text) description of the features of a software system. They are written from the perspective of an end user or user of a system and represent a single source of truth for software system functionality.

User story mapping

User story mapping is a technique used to organize and prioritize the work that needs to be done in order to deliver a valuable product or service. It is used to help teams understand the overall structure of the product or service they are building, and to identify and organize the different components of the user journey.

UX

User Experience (UX) refers to the entire interaction users have with a product, including how users feel about the interaction. In product design, UX Design refers to the high-level interaction between end user and product, which is often visualized through wireframes. Once team members are aligned on the UX of a product, additional stylistic or visual choices can be layered on to for the User Interface (UI) of the product.

Wireframe

A wireframe is a basic, two-dimensional visual representation of a web page, app interface, or product layout. Wireframes typically depict only functionality, not the true style and visual elements of the final product. It’s why most wireframes look simple: grayscale instead of colors, placeholders for images, and Lorem Ipsum for text.

Wireframe: High Fidelity

A high fidelity wireframe is a realistic image that more closely resembles the final design of a project. It can include typography, colors, images, icons, and CTA buttons. High-fidelity wireframes take longer than low-fidelity versions, which means more resources are usually allocated to complete them.

Wireframe: Low fidelity

Low-fidelity wireframes are basic wireframes that outline blueprints for web pages or app screens. They help communicate a product’s big idea or validate a common understanding of a flow, rather than focus on the specific details. It usually includes greyscale, placeholders, and Lorem ipsum text.