Remedy’s Product and Technical Glossary

There’s a lot of jargon in the tech world. We’ve created this resource for you to bookmark and reference in case you feel confused, overwhelmed, or need a refresher while reading a blog, talking to an industry expert, or scrolling through Remedy’s site again.

Pro tip: we recommend using Command+F to find specific terms and avoid scroll fatigue.

Agile Methodology is a dynamic and flexible software development approach that promotes adaptability through incremental, iterative work cadences known as sprints. It requires frequent adjustments and close collaboration with stakeholders. When using Agile, Remedy teams work in two-week-long sprints, conducting feature demos at least once every 2 weeks to gather feedback from our partners.

Scrum is an Agile project management framework that emphasizes collaboration, accountability, and iterative progress toward a well-defined goal. It includes a set of predefined roles, delivery cadences, and workload structure. This is the framework Remedy uses most to deliver MVPs and support growth phases of a product.

Kanban is an Agile project management framework that visualizes project workflows. Work items are represented by cards on a board that tracks team progress. This visual representation helps identify bottlenecks, improve efficiency, and ensure a steady flow of work. It’s particularly well-suited for software maintenance, support phases, and high-change environments.

Lean is a methodology focused on delivering maximum value to customers with the minimum number of resources. This could refer to number of features, size of teams, or hours worked. Lean principles emphasize understanding customer needs, reducing non-value-adding activities, and continuously improving workflows to only deliver what is needed, when it is needed. Lean helps organizations become more responsive and lower their burn rate.

A sprint is a set period, typically ranging from one to four weeks, during which a predefined amount of work is completed and prepared for review. Sprints enable teams to deliver incremental value frequently and make regular adjustments based on feedback and changing requirements. Sprints are a core component of the Scrum framework in Agile methodologies. Remedy’s sprints typically last two weeks.

Sprint Planning is a meeting held at the beginning of each sprint. During this event, the Scrum Team collaboratively discusses the objective of the upcoming sprint, decides which items from the product backlog should be completed, and breaks down the work into manageable tasks. The purpose of sprint planning is to have a clear sprint goal and a well-defined plan for achieving it.

A Sprint Daily, also known as a daily stand-up or daily scrum, is a brief 15-minute daily meeting held by the Scrum Team. Its purpose is to synchronize activities, share progress updates, and identify any impediments or blockers that need to be addressed. During a Remedy sprint daily, each team member answers three questions: What did I accomplish yesterday? What will I do today? Are there any obstacles preventing me from making progress?

The Sprint Demo or Sprint Review is a meeting held at the end of each sprint with the purpose of gathering feedback, validating assumptions, and ensuring that the delivered work meets the acceptance criteria and user requirements. During this event, the Scrum Team demonstrates the completed work to stakeholders, who then provide input, ask questions, and make decisions about the product’s future direction.

A Retrospective is the last meeting of each sprint where a team reflects on their performance and processes. The goal is to identify what went well, what didn’t, and what can be improved. This practice encourages continuous improvement by allowing the team to discuss challenges, celebrate successes, and implement actionable changes.

The Definition of Done (DoD) is a checklist of criteria that a user story or task must meet to be considered complete. The DoD ensures that all necessary work has been done — including development, testing, documentation, and review — aligning team members and stakeholders around a shared understanding of what “done” means. Meeting the DoD can mean that a work item is fully functional, tested, and ready for release or integration into the product.

Quality Assurance (QA) is the process of proactively preventing defects in a product. It involves systematic testing, validation, and verification of software to identify defects, errors, or inconsistencies that may affect functionality, performance, or usability. QA engineers work closely with developers, product managers, and other stakeholders to identify quality criteria, establish testing methodologies, and ensure that quality goals are met throughout the development lifecycle.

Quality Control (QC) is the process of detecting and correcting defects that may have escaped earlier stages of development or testing. It involves manual and automated testing, code reviews, static analysis, and performance monitoring to identify defects, errors, or inconsistencies.

Continuous Integration (CI) is a software development practice where developers frequently integrate code changes into a shared repository (think a shared Google Drive), where they are verified by automated build and test processes. The primary goal of CI is to detect integration errors early in the development cycle, allowing teams to address them quickly and maintain a stable codebase.

Continuous Delivery (CD) refers to the releasing of the material generated in Continuous Integration to production or staging environments in a reliable and repeatable manner. DevOps will automate the steps for doing this in order to save time on repeated operations and minimize space for human error.

Release Management is the process of planning, scheduling, coordinating, and controlling the deployment of software releases to production environments. It involves managing the end-to-end release lifecycle, from the initial planning stages through to deployment and post-release activities. Release management ensures that software releases are delivered efficiently, reliably, and in accordance with business objectives and customer requirements.

Product Vision is a high-level statement that outlines the long-term goals, aspirations, and intended outcomes of a software product. It provides a clear direction for the development team and stakeholders, guiding decision-making and prioritization throughout the product lifecycle.

Product Strategy is a comprehensive plan that outlines how a software product will achieve its objectives and fulfill its vision. It defines the approach, tactics, and initiatives that will be undertaken to deliver value to customers and achieve business goals. Product strategy involves market analysis, competitive research, customer segmentation, and prioritization of features and initiatives based on their impact and alignment with organizational objectives.

A roadmap is a strategic plan that serves as a tactical implementation of the product strategy, breaking it down into manageable steps and timelines. It provides a visual representation of the planned features, enhancements, and initiatives that will be delivered in future releases. Roadmaps help align stakeholders, communicate priorities, and track progress toward achieving strategic objectives.

A milestone is a significant event or achievement in the development lifecycle of a software product. Milestones are used to track progress, assess project status, and celebrate accomplishments. Examples of milestones include launching an MVP, releasing a new feature, or gaining 1,000 users.

Release planning (a part of release management) is the process of determining which features and enhancements will be included in a software release and defining the timeline for their delivery. It involves prioritizing user stories, estimating effort, and allocating resources to ensure that releases are delivered on time and within budget. Release planning balances customer needs, business priorities, and technical constraints to maximize value and minimize risks.

A user story is a brief, simple description of a feature or functionality from the perspective of an end user. It captures what a user wants and why, typically following the format: “As a [user], I want [feature] so that [benefit].” User stories help ensure that development is focused on delivering value to users and are written in a language that both technical and non-technical stakeholders can understand.

Acceptance criteria are the conditions that a story must meet to be accepted by the customer or end-user. They provide a clear definition of what success looks like for a particular user story or feature, ensuring that the development team understands exactly what needs to be achieved.

An epic is a large user story or a collection of related user stories that represent a significant piece of functionality or a large goal. Because epics are too big to be completed in a single sprint, they are broken down into smaller, more manageable user stories that can be developed incrementally. Epics help organize and prioritize large bodies of work and provide a high-level view of major initiatives or features within a product roadmap.

A theme is a collection of related epics that share a common goal or focus area. Themes help organize work around broader objectives and provide a way to group and prioritize related tasks. They offer a higher-level perspective on product development.

Product backlog is a prioritized list of features, enhancements, and bug fixes that are needed in a product. It is managed by the product owner and serves as the single source of truth for everything that needs to be done. A product backlog is a detailed and tactical list of tasks for the short term, while the roadmap is a strategic plan for long term goals.

Definition of Ready (DoR) is a set of criteria or conditions that must be met before a user story is considered ready for implementation. These criteria typically include detailed requirements, acceptance criteria, dependencies, and any necessary resources or assets. By establishing a clear definition of ready, teams ensure that user stories are well-defined, understood, and feasible before they are brought into a sprint for development.

Nonfunctional Requirements (NFRs) are criteria or constraints that focus on how the system should perform. They specify the quality attributes, performance characteristics, security measures, and other aspects of a software product that are not related to its functional behavior. Examples of NFRs include scalability, reliability, usability, security, performance, and compliance with regulatory standards.

Story Points are a relative measurement system used in Agile and Scrum methodologies that teams create to quantitatively determine the perceived size, complexity, and effort required to complete a specific task or user story — rather than assigning specific time durations. Story points are typically assigned during backlog refinement or sprint planning sessions and are based on discussions among team members and past performance.

Refinement Sessions, also known as backlog refinement or grooming sessions, are dedicated meetings held by Agile teams to review, clarify, and prepare user stories and backlog items for upcoming sprints. During refinement sessions, the team defines acceptance criteria, identifies dependencies, estimates effort, and if necessary, breaks down user stories into smaller tasks.

Product Metrics are quantitative measurements used to evaluate various aspects of a product’s performance. These metrics provide insights into how users interact with the product, its effectiveness in meeting user needs, and its impact on business objectives. Examples include user engagement (such as number of active users, session duration, and retention rate), usage (such as feature adoption and frequency of use), performance (such as response time and uptime), and business metrics (such as revenue generated, customer acquisition cost, and customer lifetime value).

Product Key Performance Indicators (KPIs) are specific product metrics that are selected as the most critical indicators of success often based on predefined benchmarks. These Product KPIs help track progress toward the most important strategic objectives, identify areas for improvement, and guide product development efforts.

The North Star Metric is a single, constant key metric that represents the primary indicator of a product’s long-term success and value to users. It serves as a guiding light for product development and strategy, aligning all efforts toward achieving a common goal. The North Star Metric is typically unique to each product and reflects its core value proposition and primary user benefit.

Originally published at https://www.remedyproduct.com on June 17, 2024.