> ## Documentation Index
> Fetch the complete documentation index at: https://www.scrums.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Guides & Best Practices

> Practical guidance and recommended practices for getting the most from the Scrums.com platform.

## Overview

These best practices come from Scrums.com's experience across 400+ client engagements. They are the habits that consistently separate high-performing teams from those that struggle to gain traction.

***

## Start every engagement with a clear scope

The most common source of delivery friction is unclear scope. Before your first sprint begins, ensure your team has:

* A prioritised backlog with estimated items
* Defined acceptance criteria for the top 10 backlog items
* Agreement on what "done" means for the first milestone
* Confirmed tech stack and access to all required tools and repositories

Your Enablement Partner will facilitate a scope alignment session before kickoff. If anything feels ambiguous, raise it then — not mid-sprint.

***

## Use analytics weekly, not quarterly

Delivery data is most valuable when acted on quickly. Set a weekly habit of reviewing:

* Sprint completion rate vs. target
* Open blockers and their age
* PR cycle time (is it growing?)
* Defect rate this sprint vs. last sprint

Use your Enablement Partner's monthly report as a retrospective input, not your primary visibility mechanism. By the time a monthly report arrives, the issue has already affected two sprints.

***

## Treat your Scrums.com team as an extension, not a vendor

The clients who get the most value from Scrums.com treat their delivery team as genuine colleagues — including them in product discussions, roadmap reviews, and retrospectives.

Engineers who understand the business context make better decisions and deliver better software. A team that only sees tickets — never the product or the customers — will deliver to spec but rarely beyond it.

***

## Scale proactively, not reactively

Request additional capacity before you need it. Onboarding a new engineer mid-sprint disrupts flow and reduces the value of the sprint.

If you can see a major workload increase coming in four to six weeks, raise it with your Enablement Partner now. Matching and onboarding takes up to 21 days — plan accordingly.

***

## Use Outcome Driven Sprints to validate before committing

Before committing to a large engagement, use an Outcome Driven Sprint to reduce risk:

* Run an **Engineering Discovery** before starting a major build
* Run a **Code Audit** before taking on a legacy codebase
* Run a **DevOps Health Check** before investing in pipeline improvements
* Run an **AI Readiness Assessment** before deploying AI Agents into your workflows
* Run an **Architecture Sprint** before making structural technology decisions

These fixed-scope engagements deliver a clear output in weeks, giving you the confidence to make larger investment decisions.

***

## Connect your tools from day one

Integrating Jira, GitHub (or GitLab), and your CI/CD pipeline from the start unlocks the full value of SEOP's analytics layer. Teams that connect tools later often have a gap in their DORA metric history that makes it harder to establish baselines.

See the [Integration Setup](/docs/integrations/integration-setup) guide to get connected quickly.

***

## Use governance controls, not heroics

Delivery governance is most effective when it is systematic, not ad hoc. Set up:

* Definition of Done criteria for your project types
* Required reviewer roles before status advancement
* Escalation thresholds for blocked tickets

These controls in **Administration > Governance** ensure that delivery standards are maintained without requiring constant manual oversight. They also create the audit trail that regulated clients need.

***

For more in-depth guides, visit [scrums.com/guides](https://www.scrums.com/guides).