{
  "format": "sf-survey-template-example",
  "version": 1,
  "order": 15,
  "slug": "dora-devops-performance",
  "name": "DORA: maturity of practices influencing delivery performance",
  "description": "A self-assessment of delivery and operations maturity inspired by DORA. This template combines factual questions about key delivery metrics with questions about the practices that influence those outcomes; the technical foundations block should be interpreted separately from the DORA metrics themselves.",
  "type": "custom",
  "blocks": [
    {
      "name": "Deployment Frequency",
      "weight": 1,
      "questions": [
        {
          "text": "How often does the team deploy changes to production?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Several times a day" },
            { "value": 4, "label": "About once a day" },
            { "value": 3, "label": "Several times a week" },
            { "value": 2, "label": "Once a week" },
            { "value": 1, "label": "Once a month or less" }
          ]
        },
        { "text": "The team deploys to production regularly and frequently.", "answer_type": "scale" },
        { "text": "Deployments are automated and require minimal manual effort.", "answer_type": "scale" },
        { "text": "The team can deploy on demand without depending on a fixed release schedule.", "answer_type": "scale" },
        { "text": "Changes are shipped to production in small, incremental batches rather than large releases.", "answer_type": "scale" },
        { "text": "The deployment pipeline is fast enough that it does not block daily delivery.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Lead Time for Changes",
      "weight": 1,
      "questions": [
        {
          "text": "How much time does it usually take from merge or commit to production?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Up to 1 hour" },
            { "value": 4, "label": "Within the same day" },
            { "value": 3, "label": "1-3 days" },
            { "value": 2, "label": "Up to 1 week" },
            { "value": 1, "label": "More than 1 week" }
          ]
        },
        { "text": "From the moment code is committed, it reaches production quickly.", "answer_type": "scale" },
        { "text": "The CI/CD pipeline runs automatically on every commit and completes in a reasonable time.", "answer_type": "scale" },
        { "text": "Code review and approval processes do not create significant bottlenecks.", "answer_type": "scale" },
        { "text": "The team uses trunk-based development or short-lived branches merged frequently.", "answer_type": "scale" },
        { "text": "Manual testing or approval gates before production are minimal and targeted.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Change Failure Rate",
      "weight": 1,
      "questions": [
        {
          "text": "What percentage of production deployments usually leads to an incident, rollback, or urgent fix?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Almost never or very rarely" },
            { "value": 4, "label": "Rarely, but it happens" },
            { "value": 3, "label": "Sometimes" },
            { "value": 2, "label": "Regularly" },
            { "value": 1, "label": "Frequently" }
          ]
        },
        { "text": "Most deployments to production complete without causing incidents or requiring rollbacks.", "answer_type": "scale" },
        { "text": "Automated tests catch most defects before changes reach production.", "answer_type": "scale" },
        { "text": "The team has a clear and practiced rollback or forward-fix strategy.", "answer_type": "scale" },
        { "text": "Code and configuration changes go through structured review before every deployment.", "answer_type": "scale" },
        { "text": "Test coverage is sufficient to give the team confidence to deploy at any time.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Recovery After a Failed Change",
      "weight": 1,
      "questions": [
        {
          "text": "How long does it usually take to recover after a failed change or deployment that required intervention?",
          "answer_type": "single",
          "options": [
            { "value": 5, "label": "Up to 1 hour" },
            { "value": 4, "label": "Within the same working day" },
            { "value": 3, "label": "Up to 1 day" },
            { "value": 2, "label": "1-3 days" },
            { "value": 1, "label": "More than 3 days" }
          ]
        },
        { "text": "After a problematic change, the team detects the issue quickly and starts responding right away.", "answer_type": "scale" },
        { "text": "Monitoring and alerting are in place and provide early warning of post-deployment issues.", "answer_type": "scale" },
        { "text": "The team has documented runbooks or playbooks for common deployment-related incidents.", "answer_type": "scale" },
        { "text": "Postmortems for failed changes are conducted regularly and lead to concrete improvements.", "answer_type": "scale" },
        { "text": "On-call responsibilities are clearly defined and distributed without overloading individuals.", "answer_type": "scale" }
      ]
    },
    {
      "name": "Technical Foundations and Capability Practices",
      "weight": 1,
      "questions": [
        { "text": "All code and infrastructure configuration is stored in version control.", "answer_type": "scale" },
        { "text": "The team uses feature flags or similar techniques to decouple deployment from release.", "answer_type": "scale" },
        { "text": "All environments are consistent, and infrastructure is managed as code.", "answer_type": "scale" },
        { "text": "Database schema changes are automated and part of the deployment pipeline.", "answer_type": "scale" },
        { "text": "Security and compliance checks are built into the pipeline rather than handled manually.", "answer_type": "scale" }
      ]
    }
  ]
}