Everything you need to install, configure, and get the most out of ScrumChum.
ScrumChum installs in one click from the GitHub Marketplace. The entire setup takes under a minute, and ScrumChum begins working on your repository immediately -- no server provisioning, no API keys, and no CI pipeline changes required.
When you complete the installation flow, GitHub sends an installation.created webhook to the ScrumChum server hosted on Fly.io. At that point the following happens automatically:
.scrumchum.yml file from the repository root via the GitHub Contents API. If the file exists, its settings are used; otherwise smart defaults apply.Issues: Read & Write
Required to create triage labels, post standup and retro comments, apply story-point labels, and update issue descriptions during /sc enhance. ScrumChum never deletes issues.
Pull Requests: Read
Used to gather merged-PR data for daily standups, compute velocity metrics across sprints, and detect blockers such as PRs awaiting review or PRs with stale requested changes.
Contents: Read
Read-only access used exclusively to fetch your .scrumchum.yml configuration file from the repo root. ScrumChum never reads source code, secrets, or any other file in your repository.
Metadata: Read
Provides basic repository information (name, default branch, visibility) so ScrumChum can include repo context in AI prompts and correctly scope standup and velocity reports.
First-run behavior
ScrumChum only processes issues created after installation. It does not back-fill triage comments on existing issues to avoid flooding your notification inbox. If you want to triage an older issue, comment /sc triage on it and ScrumChum will analyze it on demand. Daily standups begin on the next scheduled weekday after install. If you add or update your .scrumchum.yml file later, ScrumChum picks up the new settings on the very next event -- no restart or re-install required.
Drop a .scrumchum.yml file in the root of any enabled repository to customize behavior. All settings are optional -- ScrumChum uses sensible defaults if the file is missing or a field is omitted. The config is read fresh on every webhook event, so changes take effect immediately without re-installing the app.
Below is a complete example showing every available option with inline comments. Free-plan options work on all installations. Options marked Pro are ignored on the Free plan and activate automatically when you upgrade.
# ── Core Features ─────────────────────────────────
# Auto-triage new issues (label, estimate, prioritize)
triage: true # default: true
# Post async daily standup as a GitHub issue
standups: true # default: true
# Cron schedule for standups (UTC, cron syntax)
standup_schedule: "0 9 * * 1-5" # default: weekdays at 09:00 UTC
# Score every issue for clarity and completeness
quality_coach: true # default: true
# Minimum quality score before suggestions appear (1-10)
quality_threshold: 7 # default: 7
# Story point scale: "fibonacci", "linear", or "tshirt"
point_scale: "fibonacci" # default: "fibonacci"
# fibonacci → 1, 2, 3, 5, 8, 13
# linear → 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
# tshirt → XS, S, M, L, XL
# Custom label names for triage categories
labels:
bug: "bug"
feature: "enhancement"
docs: "documentation"
chore: "chore"
# ── Pro Features ──────────────────────────────────
# Auto-generate retrospective when a milestone closes
retros: true # default: true [Pro]
# Detect stale issues and stuck PRs
blockers: true # default: true [Pro]
# Days before an issue is considered stale
blocker_days: 7 # default: 7 [Pro]
# Track story-point velocity across sprints
velocity: true # default: true [Pro]triage
Enable or disable auto-triage on new issues. When enabled, every newly opened issue receives labels, a story-point estimate, a priority level (P0-P3), and a quality score. Default: true
standups
Enable or disable daily standup posts. When enabled, ScrumChum opens a new issue summarizing activity from the past 24 hours. Default: true
standup_schedule
Cron expression controlling when standups are posted (UTC). Accepts standard 5-field cron syntax. Default: "0 9 * * 1-5" (weekdays at 09:00 UTC)
quality_coach
Enable or disable quality scoring on issues. Each issue receives a score from 1-10. Issues below the threshold receive inline improvement suggestions. Default: true
quality_threshold
Minimum quality score (1-10) before ScrumChum suggests improvements. Issues scoring at or above this value pass silently. Lower values mean fewer suggestions; higher values enforce stricter standards. Default: 7
point_scale
The estimation scale used for story points. "fibonacci" uses 1, 2, 3, 5, 8, 13. "linear" uses 1-10. "tshirt" uses XS, S, M, L, XL. Default: "fibonacci"
labels
Custom label name mapping for triage categories. Override any of the default label names (bug, feature, docs, chore) to match your existing label scheme. If a label does not exist on the repo, ScrumChum creates it automatically.
retros Pro
Enable or disable automatic sprint retrospectives. When a GitHub milestone closes, ScrumChum generates a structured retro covering velocity, highlights, and action items. Default: true
blockers Pro
Enable or disable proactive blocker detection. ScrumChum scans for stale issues and stuck PRs on a daily schedule and surfaces them with actionable context. Default: true
blocker_days Pro
The number of days of inactivity before an open issue or PR is flagged as a potential blocker. Applies to issues with no comments and PRs with no review activity. Default: 7
velocity Pro
Enable or disable sprint velocity tracking. ScrumChum records completed story points per milestone and builds a velocity trend over time, which powers the /sc metrics and /sc sprint commands. Default: true
Every new issue is automatically analyzed and triaged the moment it is opened -- no manual intervention needed. ScrumChum reads the issue title, full description, any existing labels, and considers historical patterns from previously triaged issues in the same repository to build context.
The AI engine (Anthropic Claude) then produces four outputs in a single comment: category labels (bug, feature, docs, chore, or custom labels from your config), a story-point estimate on your configured scale, a priority level from P0 (critical) through P3 (low), and a quality score from 1-10 rating how well-written the issue is.
Edge cases are handled gracefully. Issues with very short descriptions still receive a best-effort estimate with a note that more detail would improve accuracy. Issues that are clearly duplicates or questions are labeled accordingly. If the AI is uncertain about a category, it assigns its best guess and explains the reasoning in the triage comment so a human can adjust if needed.
ScrumChum posts an asynchronous standup summary as a GitHub issue on your configured schedule. The default schedule is weekdays at 09:00 UTC, but you can set any cron expression via the standup_schedule config option -- for example, "0 14 * * 1-5" for 2 PM UTC on weekdays.
Each standup gathers data from the last 24 hours across the repository: recent commits pushed to the default branch, pull requests opened or merged, issues opened and closed, and any label or milestone changes. The AI synthesizes this raw activity into a concise, human-readable standup report organized into three sections: What was completed, What is in progress, and Blockers or risks.
Standups are posted as GitHub issues with a standup label for easy filtering. If no activity occurred in the last 24 hours, ScrumChum posts a brief "no activity" note rather than skipping the standup entirely, so your team always has a consistent rhythm.
Every issue is scored from 1 to 10 across four dimensions: clarity (is the problem or request stated unambiguously?), acceptance criteria (are there testable conditions for "done"?), actionability (can a developer start working on this without further questions?), and scope (is the issue appropriately sized rather than a multi-sprint epic?). The composite score is included in the triage comment.
Issues scoring below your configured quality_threshold (default 7) receive specific inline suggestions explaining what is missing. For example, if an issue lacks acceptance criteria, ScrumChum will recommend adding a checklist of expected behaviors. If scope is too broad, it may suggest splitting into smaller issues.
Use the /sc enhance command to go further: ScrumChum will rewrite the issue description with improved clarity, add structured acceptance criteria, include reproduction steps for bug reports, and append a scope definition -- then post the enhanced version as a comment for review.
Sprint retrospectives are triggered automatically when a GitHub milestone is closed. ScrumChum analyzes every issue and pull request attached to that milestone, including story points completed versus planned, cycle time per issue, label distribution, and contributor activity.
The generated retro is posted as a new issue and follows a structured format: What went well (highlights fast-closed issues, high-quality PRs, and consistent velocity), What could improve (flags issues that missed the sprint, PRs that sat in review too long, or quality scores that trended down), Action items (concrete suggestions for the next sprint), and a Velocity delta comparing this sprint's throughput to the rolling average.
Retros are labeled with retro for easy filtering. You can disable them per-repo by setting retros: false in your config.
ScrumChum proactively scans for work items that are stuck before they derail your sprint. Three conditions are detected: stale issues that have been open for more than blocker_days (default 7) without any comment or label change, PRs awaiting review that have had no reviewer activity in the threshold period, and PRs with requested changes where the author has not pushed an update.
Detected blockers are surfaced in a daily blocker report posted as a GitHub issue. Each flagged item includes context: how many days it has been stale, who is assigned, and a suggested next action (e.g., "request a review", "close as stale", or "break into smaller tasks"). The report is labeled blocker for easy filtering.
Adjust sensitivity by changing blocker_days in your config. A lower value (e.g., 3) catches blockers faster but may flag items that are simply waiting for a scheduled review cycle. A higher value (e.g., 14) reduces noise for teams with longer review cadences.
ScrumChum tracks story points completed per sprint by mapping issues to GitHub milestones. When an issue with an assigned story-point label is closed within a milestone, those points are recorded in velocity history stored in Upstash Redis.
Over time, ScrumChum builds a velocity trend that powers capacity planning. The /sc metrics command surfaces the rolling average velocity, a sprint-over-sprint comparison, and a breakdown of points by category (bugs vs. features vs. chores). The /sc sprint command shows the current sprint's progress against its planned capacity, so your team can see at a glance whether the sprint is on track.
Velocity data is also included in sprint retros, providing a concrete benchmark for continuous improvement discussions.
Type any command in a GitHub issue or PR comment. ScrumChum responds inline within seconds. Commands use the short prefix /sc (short for /scrumchum). The command must be the first text in the comment -- leading whitespace is fine, but do not put other text before the command.
Free commands work on every installation. Pro commands are available on the Pro plan and are ignored (with a friendly upgrade prompt) on the Free plan.
| Command | Description | Plan |
|---|---|---|
/sc estimate |
Estimate story points for the current issue | Free |
/sc summarize |
Summarize a long issue thread into key points | Free |
/sc label |
Suggest and apply labels based on content analysis | Free |
/sc triage |
Full triage: labels + points + priority + quality score | Free |
/sc help |
Show all available commands for your plan | Free |
/sc enhance |
Rewrite issue for clarity, add acceptance criteria | Pro |
/sc groom |
Full grooming: estimate + label + enhance + quality score | Pro |
/sc metrics |
Sprint velocity and metrics summary for the repo | Pro |
/sc sprint |
Show current sprint progress vs. planned capacity | Pro |
/sc progress |
Show milestone completion progress and burndown | Pro |
/sc estimateAnalyzes the issue title and description to produce a story-point estimate on your configured scale. The estimate is posted as a comment and a corresponding label (e.g., points:5) is applied to the issue. If the issue already has a point label, it is replaced. Useful when the scope of an issue changes and you want a fresh estimate.
# In an issue comment:
/sc estimate
/sc summarizeGenerates a concise summary of a long issue thread. Reads the original issue description and all comments, then distills the discussion into key points: the core problem, proposed solutions, decisions made, and open questions. Particularly useful for issues with 10+ comments where catching up is time-consuming.
# Summarize a lengthy discussion:
/sc summarize
/sc labelAnalyzes the issue content and suggests appropriate labels based on your repository's existing label set and the triage categories configured in .scrumchum.yml. Labels are applied automatically. If a suggested label does not exist on the repository, ScrumChum creates it with a default color.
# Re-label after the issue scope changed:
/sc label
/sc triageRuns the full triage pipeline on demand: labels, story-point estimate, priority level, and quality score. This is the same analysis that runs automatically on new issues, but you can invoke it manually on older issues or after significant edits to the issue description.
# Triage an issue that was opened before ScrumChum was installed:
/sc triage
/sc helpLists all available commands for your current plan with brief descriptions. Pro commands are shown with a badge so you can see what is available on upgrade.
/sc help
/sc enhance ProRewrites the issue description for maximum clarity. ScrumChum produces an enhanced version that includes a clear problem statement, structured acceptance criteria as a checkbox list, reproduction steps (for bug reports), scope boundaries, and technical notes where applicable. The enhanced description is posted as a comment so you can review it before adopting the changes.
# Improve a vague issue:
/sc enhance
/sc groom ProRuns a complete backlog grooming pass in a single command. Combines /sc estimate + /sc label + /sc enhance + quality score into one response. Ideal for backlog refinement sessions where you want to process many issues quickly.
# Full grooming in one shot:
/sc groom
/sc metrics ProDisplays sprint and velocity metrics for the repository. Includes the rolling average velocity (story points per sprint), a sprint-over-sprint comparison, points completed by category (bug, feature, chore), and the current sprint's completion percentage. Data is sourced from velocity history stored in Redis.
# Check team velocity trends:
/sc metrics
/sc sprint ProShows the current sprint's progress against its planned capacity. Displays total points planned, points completed, points remaining, completion percentage, and a list of open issues still in the sprint. Uses the active GitHub milestone as the sprint boundary.
# Check sprint status mid-sprint:
/sc sprint
/sc progress ProShows milestone completion progress with a percentage bar, issues closed vs. open, and an estimated completion date based on current velocity. Useful for stakeholder updates and release planning. Works with any GitHub milestone, not just sprint milestones.
# Share progress with stakeholders:
/sc progress
/sc estimate, /sc summarize, /sc label, /sc triage, /sc help
/sc enhance, /sc groom, /sc metrics, /sc sprint, /sc progress
| Feature | Free | Pro |
|---|---|---|
| Repositories | 1 | Unlimited |
| AI calls | Unlimited | Unlimited |
| Auto issue triage | Yes | Yes |
| Daily standups | Yes | Yes |
| Quality coach | Yes | Yes |
| /sc estimate, summarize, label, triage, help | Yes | Yes |
| Sprint retros | -- | Yes |
| Blocker detection | -- | Yes |
| Sprint velocity | -- | Yes |
| /sc enhance, groom, metrics, sprint, progress | -- | Yes |
All billing is handled through the GitHub Marketplace -- no separate accounts, credit cards, or payment methods needed. Your existing GitHub billing method is used. Charges appear on your GitHub invoice alongside any other Marketplace subscriptions.
Upgrading: When you upgrade from Free to Pro, Pro features activate immediately on all selected repositories. You are billed a prorated amount for the remaining days in the current billing cycle. The per-repo charge ($4/repo/month) applies to every repository you have granted ScrumChum access to.
Downgrading: You can cancel or downgrade at any time from your GitHub billing settings (Settings → Billing → Plans and usage). On cancellation, your account continues to have Pro access until the end of the current billing period, then automatically reverts to the Free plan. No data is lost -- velocity history, triage records, and configuration are preserved. Pro commands simply stop responding and Pro automated features (retros, blockers, velocity) pause.
Changing repositories: You can add or remove repositories from ScrumChum at any time via your GitHub installation settings. On the Pro plan, per-repo charges adjust automatically on the next billing cycle. On the Free plan, only the first selected repository is active.
ScrumChum is designed with a minimal-data architecture. It processes only what is necessary to provide AI-powered Scrum features and retains as little data as possible. Here is exactly how your data flows through the system.
The vast majority of data is ephemeral -- it passes through ScrumChum's server during processing and is never persisted. The only data stored in Upstash Redis is:
Issue content, PR bodies, comment text, and source code are never written to any persistent store. They exist only in server memory during the seconds it takes to process a webhook.
Minimal permissions
Only requests the access it needs. Never modifies your code, reads source files, or accesses secrets.
Webhook verification
Every incoming webhook is verified using HMAC-SHA256 signature validation provided by the Probot framework. Requests with invalid or missing signatures are rejected.
HTTPS everywhere
All communication is encrypted in transit: GitHub-to-Fly.io, Fly.io-to-Anthropic, and Fly.io-to-Upstash Redis. No data is ever transmitted over plaintext HTTP.
Data deleted on uninstall
When you uninstall ScrumChum from your account, an installation.deleted webhook triggers automatic cleanup of all stored data (installation records, velocity history, usage counters) from Redis.
Anthropic's no-training policy
AI calls go through Anthropic's commercial API. Per Anthropic's data usage policy, data sent through the API is not used to train or improve their models. Your issue content remains private and is not retained by Anthropic after the API response is returned.
For full details, see our Privacy Policy and Terms of Service.
We are a small team and we take support seriously. Whether you are running into a bug, have a feature request, or need help configuring ScrumChum for your workflow, we are here to help.
Email support
Reach us at [email protected]. We aim to respond to all emails within 24 hours on business days. For urgent issues affecting production workflows, mention "urgent" in the subject line.
GitHub Issues
For bug reports and feature requests, open an issue on the ScrumChum GitHub org. Using GitHub Issues helps us track, prioritize, and reference bugs publicly so other users can see if a known issue affects them and follow progress toward a fix.
Configuration help
If you need assistance setting up your .scrumchum.yml or understanding how a feature works, email us with your repo name and we will help you get the optimal configuration for your team's workflow.
Response times
We aim for a first response within 24 hours on business days for email support and GitHub Issues. Critical production issues (e.g., ScrumChum posting incorrect data or failing to respond to commands) are prioritized and typically addressed within a few hours. Bug fixes are shipped as rolling deployments to Fly.io -- no action is needed on your end.