Practices

Improve your own software delivery practice by selecting new capabilities to implement as part of your continuous delivery pipeline.

  • BuildCreate new features, correct defects, and standup supporting infrastructure.
  • DeployInstall changes in staging and production environments.
  • OperateTrack the effect of changes, capture feedback, and help customers succeed.
  • PlanCombine metrics with customer feedback and professional intuition to prioritize and describe the next round of changes.

Detailed Table of Practices

  • BuildCreate new features, correct defects, and standup supporting infrastructure.
    • Bootstrapping Infrastructure - Build
      • Password ManagerAll resource credentials are kept in a secure, shared repository, such as LastPass.
      • Email Alerts All systems are enabled for email alerts, and all email alerts go to a shared chat room, forum, email account, or distribution list. For a distribution list, to provide transparency, the alerts should also be available in a chat room or forum. (TBD)
      • Version Control SystemAll source materials used to create and distribute products or customizations are kept under some form of version control with a history of changes.
      • Post-Launch Subscriber Configuration(sf) To provide longterm support, subscriber metadata is kept under version control, so that post-launch changes can be reviewed. (TBD)
      • Issue TrackerAll new work and modifications are made according to a request logged to a common system that assigns a unique identity to each item, such as an issue tracker or agile project management tool. 
      • TraceabilityAll changes can be traced from the Issue Tracker to the Version Control System, or from version control (Bitbucket) to the change request (Jira issue) to the original requirement (in Confluence). (TBD)
        • Issue IDs in Commit LogsEach and every commit references an issue ID, so that we can trace from the commit to the issue tracker (and vice versa).  Ideally, this practice is enforced by a pre-commit hook so that the Version Control System will not accept a commit that does not reference an issue tracker ID. (TBD)
      • Collaborative PlatformRequirements and changes are specified using a collaborative environment, such as Confluence, which is integrated with development tools, such as the JIRA issue tracker and Git version control system. (TBD)
      • Agile MethodologyDevelopment work is managed using a well-defined Agile process, where progress on open items is visible on a shared Agile board, and the team continuously improves through blameless retrospectives. (TBD)
      • Designated WorkspaceUsing a template, a separate Confluence workspace is created for each customer implementation or major release series (such as Winter, Spring, Summer, for Salesforce) in order to aggregate the resources generated for each release and to avoid creating a future maintenance burden. (TBD)
      • BuildOps MaintenanceThe infrastructure used by the build pipeline is regularly maintained according to a set schedule and checklist, including pruning abandoned task branches. (TBD)
      • Resource ChecklistsTo ensure consistency and quality, checklists walk through the initial setup of recurring resources, such as managed packages, Trialforce orgs, workspaces, requirements, and internal scripting tools, as well as onboarding and offboarding resource users. (TBD)
      • On-board/off-boardThe access new employees require is defined by role, and work instructions include removing access from business resources and development resources when an employee leaves. (TBD)
      • Shared Two-Factor VerificationFor shared and standing development orgs, the verification text number is tied to a Google Voice number that posts to a chat room (such as HipChat or Slack), for shared access. 
      • Topic BranchingWithin the Version Control System, topic branches are created from the default branch to represent individual change requests (Jira issues). The branches are short-lived and merged back into the default branch when the task is done. An alternative to Topic Branching ("Git Flow") is Trunk Based Development. (TBD)
      • Resource ManagementKey resources shared across packages or implementations (such as the ant-salesforce.jar or SFDX CLI) are maintained in a common managed location, and not in the individual source repositories. (TBD)
      • Managed v Unmanaged(sf) When to use an unmanaged or managed package is clearly defined by a decision tree or matrix. When to submit a package for security review is also supported by a decision tree. (TBD)
      • Resource Naming ConventionsCommon resources share a strong naming scheme, so that new resources with a similar scope are easy to locate, regardless of which team member creates the resource. This practice applies to version control repositories, named packages, shared usernames, development environments, and so forth. (TBD)
      • Trunk Based DevelopmentWithin the Version Control System, new development is committed directly against the trunk, and checked in at least daily. An alternative to Trunk Based Development is Topic Branching. (TBD)
      • Branching ModelA high performing development team selects a branching model that works well in their own environment. The two most popular models are Topic Branching and Trunk Based Development. Branching is a core practice. Each team member must understand the branching model being used, and should understand why the selected model is the best choice for their team.  (TBD)
      • Configuration Management SystemAll server operating systems and application software are setup and updated using automated configuration tools, such as Puppet, Chef, or AWS Cloud Formation.  (TBD)
      • Resource RunbookOutline the lifecycle of each infrastructure resource, and any operational parameters, in a runbook or set of runbooks. (TBD)
      • Equivalent Staging and Production EnvironmentsTo properly test ongoing changes to the work increment, we need a staging environment that matches the production environment as closely as possible. 
      • Continuous Integration Build ServerA build server integrates with other resources, such as the Version Control System, Configuration Management System, and other tools, in order to execute routine builds, launch automatic tests, and undertake other housekeeping tasks.  (TBD)
      • Deploy to Staging on Every MergeOn any change to the head of development, deploy the updated work increment to staging environment.  (TBD)
    • Provisioning Environments
      • Disposable Dev and Demo EnvironmentsSingle-use development or demo instances are provisioned from source control, used briefly for a single task or feature, and then discarded. For Salesforce, environments may be provisioned from an Enterprise Edition Org with Sandboxes, a Scratch Org Dev Hub (beta), or a Trialforce Source Org (partners). (TBD)
      • Build Request FormSupplemental builds can be launched from the business org or secure web site, without visiting external sites or servers. (TBD)
      • Mock DemosSales demos are based on a thoughtfully designed mock customer, complete with realistic mock data, designed to be used with trials. (TBD)
      • MP Task Orgs(sf) For managed packages, Trialforce is used to create new environments from on a secure Visualforce page, or DX is used at the command line by Platform Developers. (TBD)
      • CS Task Sandboxes(sf) For consultants, developer sandboxes are provisioned and populated with a scrubbed subset of the customer's production data, and a full sandbox is used to integrate changes for customer acceptance testing. (TBD)
      • Org Request FormEnvironment requests can be launched from the business org, or secure web site, without visiting external sites or servers. (TBD)
      • ChatOpsEnvironments can also be provisioned by querying a robot service in a chat room (Doggles in HipChat).  (TBD)
      • Clean Orgs(sf) DX Scratch Orgs are used, or spurious metadata is scrubbed from other development environments, so that the environment only contains components found in the target package. (TBD)
      • Mock OrgsFor MPs, the development environment is based on the primary Sales Demo and includes realistic mock data bundled with the trial. For CSs, the development sandboxes include a subset of customer production data loaded with a build agent. (TBD)
      • Mock PackageThe core Sales Demo is handled as a package so that it can be redistributed to more than one environment type. (TBD)
      • Role OrgsMP staff and partners can provision different types of trials according to each person's role, with either source code or packages installed (development, testing, training, and/or sales use). (TBD)
      • Cohort OrgsMP environments are provisioned to represent different segments of its subscriber base, pre-configured with settings and data appropriate to each segment. (TBD)
      • Development Environments on DemandA working development environment can be automatically provisioned by developers, as needed, either through an online request form or ChatOps. 
    • Working with Environments
      • Demo Orgs Ready to UseSales demos and other trials also arrive pre-configured and ready to go, without routine manual steps. (SF orgs are configured by using Proxy Signup to modify the trials in-flight.) (TBD)
      • Dev Orgs Ready to UseMP development environments arrive ready-to-go. Developers sign-in-and-go without so much as setting a password.  (TBD)
      • Start New TaskAutomated Task Branching - Task branches and pull requests can be managed by running a build when development work begins, without special knowledge of Git. (TBD)
      • Ready to ReviewAutomated Pull Requests - Any changes made to the development environment can be automatically committed back to version control, without special knowledge of GitThis task automatically updates the package manifest (by retrieving the package by name). (TBD)
      • Data to GoReady to Review includes changes to the mock sample data. (TBD)
      • Ready to Use IDE Support(sf) IDEs can be attached to development environments without cloning the Git repository to a local workstation. The native developer UIs can also be used to make changes to be placed under version control. (TBD)
    • Managing Change - Build
      • Permissions(sf) User access to new components is handled through permission sets and an optional stub profile. For MPs, updating customer permsets or profiles is handled through Direct Deployment. (TBD)
      • Report ExamplesNew reporting examples are included with new features, as appropriate, and distributed through Direct Deployment. (TBD)
      • External ID Fields(sf) External IDs are included with standard and custom objects to support capabilities like data conversion, sample data import, and staging refresh. (This item does not include implementing the capabilities, only the External ID fields.) (TBD)
      • Proxy BaseFor extension packages being developed alongside a base package, to support base API changes for the extension, the base is represented by a proxy package using a different namespace prefix so that the base can be updated incrementally during the development sprint.  (TBD)
      • Proxy Upload(sf) For managed packages using Proxy Base, a new version is automatically uploaded and installed into an integration or development environment, after every change to the mainline or on a nightly basis. (TBD)
      • Flows for the Win!(sf) Flows are available for use in managed packages and local extensions. (TBD)
      • Cache Partitions(sf) Platform cache partitions are used in managed packages and local extensions where needed.  (TBD)
      • Customer CollaborationCustomers have access to an issue tracker and wiki (such as JIRA and Confluence) that can be used to collaborate between themselves and with the implementation team. (TBD)
      • Unit TestsAs part of coding an item, include light-weight automated tests that exercise the internal interface for individual classes or components. A unit test provides a strict contract that the piece of code must satisfy.  (TBD)
      • Team Agile BoardA team agile board is a work and workflow visualization tool that optimizes the flow of work during an iteration. The board provides columns to represents phases of work, such as To Do, In Progress, and Done. Each work item is represented on the board as it moves across the columns. An agile board can be used with Scrum, Kanban, and other methodologies, and be physical or virtual. (TBD)
      • Feature Agile BoardA feature agile board tracks the progress of a feature from inception to adoption. The board provides columns to represents phases of work, such as To Do, Plan, Build, Operate, Evaluate. Other agile board may track the progress of each feature with the top-level phases.  (TBD)
      • Continual Builds of Complete Test VersionsAt least once a day, automatically build a complete release candidate, including dependencies, documentation, and automatic tests. Deploy build to a staging or test environment. (TBD)
      • Short Running TestsDuring code review both Apex unit test coverage and Apex unit test duration on new components is confirmed to be within expectations (less than five seconds per method). (See also ApexUnit https://github.com/forcedotcom/ApexUnit.) (TBD)
      • Go/NoGo Milestone Checkpoints​At the close of each iteration, stakeholders jointly determine whether to proceed with the next milestone version.  (TBD)
      • Peer Review and TestingPeer developers review and test all changes before code and sample data is merged back to version control, following a test plan that is created for each issue in Confluence. (TBD)
      • Static AnalysisOnce a pull request is created, changes are verified through static analysis, including quality scans and security scans. (TBD)
        • Security ScanCommon security issues are checked as part of peer review or static analysis (TBD)
          • Quality ScanOnce a pull request is created, changes are verified through static analysis and by running the Apex unit tests. (TBD)
      • Coding Style GuideDocument the set of conventions about how to write code for your project. It is much easier to understand a large codebase when all of its code is presented in a consistent style. (TBD)
    • Documenting Change
      • ApexDocsGlobal classes are documented with ApexDocs and available through the help site. (TBD)
      • API DocumentationDescribe what services your application programming interface offers and how other people can use those services. (TBD)
      • Context HelpHelp for this Page is extended for new tabs, updated as needed, and linked to Help Site. (TBD)
      • Developer Design DocumentsDocument key aspects of the application design for the benefit of other developers, and your future self. (TBD)
      • Evergreen Help SiteThe Preview and GA help sites are updated within each sprint to cover new tasks, topics, and references meaningful to end-users.  (TBD)
      • Help SiteHelp topics are provided for all subscriber-facing capabilities. (TBD)
      • OctoDocsOther shared components are documented with Octopus https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B5cEKEAZ. (TBD)
      • Technical Change LogItemize each work item merged into a given work increment, and provide a standard description of the change. (TBD)
        • Jira Change Log in your Confluence WikiUpdate the change log to list the issues for the new version. (May be done in GNG Baseline.)
          • Change Log FieldsIn the JIRA issue, fields are available for developers to summarize the actual change being made, and to indicate the need for any Upgrade Steps or Feature Toggles. (These fields are included in the change log generated for each version.) (TBD)
          • Setup Change Log
        • New ComponentsOnce the new increment is deployed, update the change log to list any new components (classes, fields, and so forth) being added to the version, by using a Javascript macro to scrape the package details page.
      • Troubleshooting ArticlesCapture how unusual and everyday problems were solved, in case the issue reoccurs. (TBD)
      • Value Stream MapA value stream is the series of activities used by an organization to deliver a product or service to an external or internal customer. A value stream map breaks down the process time for each activity, the lead time between activities, and the success rate. The map is depicted as a flow chart annotated with key metrics. Key metrics are lead time, process time, activity ratio, rolled % complete & accurate. Often a current state map is used to derive a future state map with process improvements.
    • Integrating Change - Build
      • CheckOnly Before Merge(sf) The full set of Apex tests on the task branch is automatically validated (checkOnly) against the packaging org or production org when the pull request is created. (TBD)
      • CheckOnly After Merge(sf) On merge to develop, the updated develop branch is validated (checkOnly) with the packaging org or production branch. (TBD)
      • You Break ItFailed builds are raised up in email alerts for handling by the developer responsible for the last change. (TBD)
  • DeployInstall changes in staging and production environments.
    • Bootstrapping Infrastructure - Deploy
      • Master and Patch Branches(sf) Individual package branches are stood up under a master folder in the Version Control System, where each branch under master represents the main packaging org or a patch org. (TBD)
      • Pilot, Beta, and GA RolloutsNew capabilities are often available as an optional Pilot, followed by a public beta, before being designated Generally Available (GA). (TBD)
      • Preview ChannelDevelopment and validation of new practices is staged so that designated early adopters can use changes and enhancements first before the capability is available to all subscribers. (TBD)
    • Integrating Change - Deploy
      • Batch Size of OneSuccessful builds are automatically uploaded to a proxy test package, push deployed to a firewall sandbox instance, and subjected to a full set of regression tests. (TBD)
      • Dev TSO Template Refresh(sf) At the end of the sprint, a new development TSO templates is provisioned, in case it is needed for patch development. (TBD)
      • GNG BaselineJust prior to the sprint retrospective, a master pull request and an updated change log are generated, for review at the retrospective and Go/NoGo meeting.  (TBD)
      • Go/NoGoFollowing the Sprint Review and Retrospective, stakeholders meet to determine if the new work increment is potentially releasable, or whether there are known impediments. (TBD)
      • TSO Template BotA Selenium script automates provisioning the templates, and the confirmation email is processed as an inbound message and parsed. New template ID is captured in an object and made available to ChatOps and Visualforce Request form. (TBD)
      • UI RegressionsSelenium Nightwatch tests are included where appropriate to assure that the user interface will continue to work as expected. (TBD)
    • Preparing New Versions
      • Milestone TSO Source Template(sf) When creating a transient branch, a new trial template is provisioned to represent the new version. (TBD)
      • New Version Agile BoardThe version creation and validation process is tracked in a shared checklist and/or Agile board, and included in the issue tracker. (TBD)
      • Transient BranchTo freeze the work increment being released, a temporary branch is created from develop, and a pull request created from the transient branch to packaging or production. (TBD)
      • Tag IssuesIdentify the changes for the new version by tagging the corresponding JIRA issues. (May be done in GNG Baseline.) (TBD)
      • Automatic Change LogThe change log is determined by observing the Git pull request, with little or no human intervention. (TBD)
      • Merge and DeployThe new increment is merged, and deployed to the packaging org or production (using the Ant Migration Tool or SFDX tool). All metadata in the repository is deployed using a blank manifest (TBD)
      • Tag RepositoryThe packaging or production branch in Git is tagged using the JIRA version ID. (TBD)
      • Firewall Install TestInstall the new version into the firewall sandbox environment.  (TBD)
      • Upgrade Install TestUpgrade a GA trial environment to the latest version.  (TBD)
      • Upgrade Preview TSOInstall the new version into the Preview TSO, which generates production-like environments. (TBD)
      • One Button Milestone InstallThe Firewall and Upgrade Sandbox Install and Test tasks are automated, and, on success, trigger the GA Trial success, and ultimately the TSO install. (TBD)
      • No Pull Request Left BehindPrior to merging a new work increment, open pull requests from prior sprints are reviewed, to ensure completed work is not left outstanding. (TBD)
      • Version Agile BoardA version agile board tracks the progress of a set of changes from build to operate. The board provides columns to represents phases of work, such as To Do, Building, Certifying, Deploying. The board may include preview, general, and maintenance releases.  (TBD)
    • Validating New Versions
      • Graceful degradationApex unit tests can make configuration changes during a test run to confirm features work as expected when enabled or disabled. (TBD)
      • Health CheckThe packaging and business orgs continue to pass the Salesforce Security Health Check following each major release, with a score of 80% or above. New subscriber orgs are reviewed with the Salesforce Optimizer before launch. (TBD)
      • Release ReadyThe packaging and pre-launch production orgs kept in a state of continual release readiness.  (TBD)
      • Scope / DocsValidation includes the relevant help topics and other documentation (ApexDocs, Developer Guides). (TBD)
      • Scope / TestsValidation includes both regression tests and feature acceptance tests, in automated and exploratory form. #TestLikeACustomerr (TBD)
      • Toggle TestsValidations are performed with all features toggled off, all features toggled on, and with only new features toggled on. (TBD)
      • ValidationThe latest work increment, is examined at the close of each sprint, to determine whether the version is ready-for-primetime. For MPs, a milestone version is validated. For CSs, a full staging sandbox is validated. For MPs, patch versions are run through the same gauntlet as major versions. (TBD)
      • Version CertificationEach new version is validated following a detailed checklist and exploratory test plan. If all checklist items pass, the version is certified for production use. Uncertified versions are deprecated. (TBD)
      • Version Issue ResolvedThe issue for the version is resolved in the New Version issue tracker and indicates its resolution status (failed certification, certified but not deployed, certified and deployed). (TBD)
    • Deploying Versions
      • Configuration WizardNew implementation setup is streamlined through use of a configuration wizard that collect and updates settings. (TBD)
      • Connected DeploymentDirect deployment leverages a connected application (and user credentials are not required). (TBD)
      • Deploy From Hub(sf) Using a secure Salesforce app in our business org, any certified version can be pushed to subscriber staging or production orgs, individually or in groups, typically with the latest features disabled, and other needed updates automatically applied. (TBD)
      • Direct Deployment(sf) New permissions and reports are deployed post-upgrade by Connected Deployment or by leveraging user credentials. (TBD)
      • Feature Configuration Audit TrailAny change to feature configuration (including validation rules) is recorded in a supplemental audit trail log and made available as part of Push Metrics. (TBD)
      • Feature Toggles(sf) Custom metadata feature toggles may be hidden from the subscriber and activated through the LMA. (TBD)
      • Jumpstart Org(sf) To assist with implementing a package for new subscribers, a Jumpstart trial is maintained with the latest GA versions for use by new implementations. (TBD)
      • Org Details Object(sf) To track additional detail about subscriber orgs, a custom object in the business org is linked to the LMA and the subscribers Account object. The org details aggregates the API applications installed for each subscriber, the instance, the my domain name, the production org ID, as well as the staging/preview sandbox IDs, and refresh history. Ideally, an automation posts an alert whenever a new org is added, to queue followup actions. (TBD)
      • Patch Org Validation(sf) Prior to re-launching the preview channel, the GA patch orgs are provisioned early and tested with a deploy to be sure the org provisioned correctly. (TBD)
      • Push Major UpgradesQueue automated deployments of new versions from build server o to individual subscribers or subscriber groups. On Force.com, Deploy Fom Hub queues deployments form the business org. (TBD)
      • Rock Steady API(sf) Global components are stable with a low regression rate, including behaviors of Global Apex class methods and variables, Apex triggers, custom metadata, custom objects, fields, validations, and workflows. (TBD)
      • Rollout TrackingThe progress being made on a major version rollout is tracked in a shared checklist and/or Agile board. (TBD)
      • Scalable DeploymentWhen Direct Deployment is used, scale agents on a platform like AWS, so that many subscribers can be upgraded at once. (TBD)
      • Sharpen the AX(sf) The AppExchange entry is updated to the latest version for each new GA major version, without concern of prompting a security review.  (TBD)
      • Toggle OffOptional features promoted to GA or Beta in a release can be deployed in an activated or deactivated state and toggled on or off by the subscriber. (TBD)
      • Upgrade Slot SelectSubscribers can select their own upgrade slot within a window, or accept a default upgrade date. (TBD)
      • Zero Step Tolerance(sf) Any upgrade steps are automated or optional and can be invoked by subscribers. (TBD)
    • Managing Change - Deploy
      • External Regression Test SuiteNew regression tests for Global API methods are created in an external package as part of the development task, and UI changes include modifications to the Selenium Nightwatch scripts. (TBD)
      • Staging Data RefreshExternal IDs are included with standard and custom objects so that updated records can be pulled from production at any time. (TBD)
  • OperateTrack the effect of changes, capture feedback, and help customers succeed.
    • Monitoring and Measuring
      • AuditingSetupAuditTrails for subscribers are aggregated via the API and scanned for unhealthy changes. (TBD)
      • Defect AnalyticsDefect dashboards and reports are available in the business org. (TBD)
      • Defect KPIDefect reports and repairs are closely monitored and used as a key performance indicator. (TBD)
      • Defect ResolutionCrucial defects are quickly repaired and (MP) made available as patch versions to affected subscribers. (TBD)
      • Defect TimeboxRather than assign story points, initial work on a defect proceeds within a predefined standard timebox. If the defect cannot be resolved within the timebox, then whether to proceed is reviewed at standup. For example, the timebox may be based on how long it takes to resolve 80% of the defects (TBD)
      • Error Email Logging(sf) Application error emails are forwarded to an inbound email service in the business org. (TBD)
      • Fail Events(sf) Issues found by failing Apex Unit tests or Selenium tests are posted to cloud-based logging systems, just like production errors and messages. (TBD)
      • Feature Auditing(sf) FeatureSetupAuditTrail for subscribers are aggregated as part of Push Metrics. (Needs to be considered in the context of the Feature Management pilot.) (TBD)
      • Hammer Tests(sf) Subscriber Apex tests are run periodically to detect any new failures.  (TBD)
      • Heath PredictorsDefect Magnets; Hidden Features; Unilateral Changes (TBD)
      • Information RadiatorDisplay key statistics, performance indicators, and inspirational messages in a highly visible location, for the benefit of team members and passers-by. (TBD)
      • Known IssuesDefects are reported to a public site for awareness and feedback that all subscribers can access. (TBD)
      • Production Immune SystemUsage metrics and logs are continually scanned to detect statistically significant variations in error volume, creating a "production immune system". (TBD)
      • Push MetricsFeature usage and adoption is automatically monitored and subscriber orgs push configuration settings, logs, and statistics back to the MP business org. For Salesforce, the metrics include data storage used, installed packages, and Lightning adoption. For Communities, metrics include license counts and Community logins. (TBD)
      • Remote Event Logging (TBD)
        • Log RolloverRecent usage and error logs are combined maintained both in the business org (primary storage) and a data warehouse (secondary storage). Older logs are routinely pruned from the business org and maintained in the data warehouse for long-term analysis. (TBD)
      • Root Cause AnalysisTo ensure the quality and improvement of our change management process, and to prevent previously discovered problems from recurring, we perform a root cause analysis (RCA), by asking five whys. (TBD)
      • Score CardA set of leading and lagging metrics are used to predict and then review the success of a CS project or MP major version and compared with actual results prior to the next event. (TBD)
      • Trust DashboardWhen reliability issues are detected, the incident is posted to a system health dashboard that all subscribers can access. (TBD)
      • Usage MeticsFor each subscriber, tally record creation volume, page access volume, and page render times, and summarize on a dashboard. (TBD)
    • Managing Change - Operate
      • Alert Capture(sf) Error alerts raised by email are captured in a business org object for analysis, reporting, and followup action. (TBD)
  • PlanCombine metrics with customer feedback and professional intuition to prioritize and describe the next round of changes.
    • Learning and Planning
      • Acceptance CriteriaAs part of the definition of done, acceptance criteria lists the main points or business rules to consider when coding and testing a user story. Acceptance criteria is often used as the basis for Acceptance Test Suite.  (TBD)
      • Acceptance Test SuiteInclude a set of tests that describe how a feature or story will be used in practice. Acceptance tests often walk through the item's acceptance criteria with hands-on exercises and Sample Feature Data. (TBD)
      • Actionable KPIsKey performance indicators measure activity to determine whether a system is achieving it's defined objectives. Not all metrics are KPIs. KPIs should pass the IPA test – Important, Potential for improvement, and Authority (does the system have the means to improve this KPI?).   (TBD)
      • Adoption AnalyticsFeature adoption is visible from the business org in the form of dashboards and reports, drawing on usage metrics and the configuration audit logs.  (TBD)
      • Analytics ConsideredActual and projected feature adoption rates are compared and used as input to roadmap planning. (TBD)
      • Collaborative RequirementsUser stories, use cases, wireframes, and other supporting materials, are maintained in a collaborative authoring platform, such as Confluence, or specified directly in a JIRA story or task. (TBD)
      • Definition of DoneThe definition of done is the standing set of acceptance criteria for all work items, in addition to the specific Acceptance Criteria for each item. It is a comprehensive checklist of necessary, value-added activities that assert the quality of any feature and not the functionality of that feature. A DoD often includes unit test coverage, coding to standards, peer review, and passing its own Acceptance Test Suite.  (TBD)
      • Extensibility FirstNew changes are specified with extensibility for multiple subscribers in mind, including the mock customer. (TBD)
      • Feature AdoptionEvery new feature is a hypothesis, and we track feature adoption to determine whether to pivot or persevere.  (TBD)
      • Ideas ConsideredSubscribers Ideas play a strong role in steering the future roadmap, along with a strong internal vision of the product's future. (TBD)
      • Ideas SolicitedSubscribers are able to post feature enhancement requests ("Ideas") to a forum for peer and product management review. (TBD)
      • Production Data SubsetIdentify a representative subset of production data to extract into development environments. (TBD)
      • Ready to Develop Checklist(Help text, error messages, sample data ...) (TBD)
      • Results Driven RoadmapBased on adoption feedback, subscriber ideas, prospect needs, and other inputs, additional changes are specified, closing the loop. (TBD)
      • Sample Feature DataNew features provide new sample data to use with new components when appropriate. (TBD)
        • Sample Data Updated for New FeaturesDuring initial development, the Sample Feature Data set is extended to include new features, and the updated data set follows the feature as it goes into the GA and Preview channels. (TBD)