User guide

This guide is the same as CHIPS's built-in Help (the ? button).

Getting started

For: Everyone

CHIPS — Collaborative Heuristic for Iterative Planning and Story-pointing — is a web application for estimating user stories together, in real time, from any browser. Nothing needs installing on anyone's device.

There are three kinds of people:

If you are a team member: open the link your scrum master sent, type your name and press Join room. That's it — see For team members.

If you are a scrum master:

1. Sign in on the welcome page (your administrator gives you an account, or you Create account if self-registration is on). The very first time, the administrator sets CHIPS up — see Setting up CHIPS.
2. On Projects, press New project, then type a room name and press Create room.
3. Press Copy link and send the link to your team.
4. Add user stories at the bottom of the room (or Import them).
5. Press Start on a story — everyone picks a card — press Reveal cards — Save estimate.

flowchart TD
    A([Scrum master signs in]) --> B[Create or open a project]
    B --> C[Create a room and choose its rules]
    C --> F[Add user stories: type them, upload a CSV file or import from Jira]
    F --> D[Share the room link]
    D --> E([Team members open the link and type their name])
    E --> G{How to estimate?}
    G -->|one story at a time| H[Pick a technique: planning poker, Fibonacci, t-shirt or three-point]
    H --> J[Everyone votes in secret]
    J --> K[Scrum master reveals the cards]
    K --> L{Agreement?}
    L -->|no: discuss| J
    L -->|yes| M[Record the final estimate]
    G -->|many stories at once| I[Affinity board: the team sorts stories into size columns]
    I --> M
    M --> N{More stories?}
    N -->|yes| G
    N -->|no| O[End the session]
    O --> P[History, CSV download and recording playback]
    M -.->|optional| Q[Update Jira: story points, assignee, priority, versions, labels]

Every button describes what it does when you hold the mouse over it.

Setting up CHIPS

For: Administrators

After CHIPS is installed, the welcome page shows Set up CHIPS. Setting up is done once, by the person who installed it, in six steps:

1. Setup code. So that nobody else can take over a new installation, the wizard asks for a one-time code. The installer prints it; it is also in the server log (sudo journalctl -u scrum-poker, docker compose logs app, on Windows C:\ProgramData\CHIPS\logs\chips.log). On the server, python -m scrumpoker.manage setup-code makes a new one (Linux: sudo /opt/scrum-poker/deploy/setup-code.sh; Windows: deploy\windows\setup-code.ps1 in an elevated PowerShell). A code is valid for 24 hours and stops working after 10 wrong tries. The step then shows checks of the server: the database, the site secret, HTTPS, secure cookies and the integrity of the installation.
2. License agreement. Read and accept it for your organisation.
3. Administrator. Username, display name, email and password (long, not a common password, not containing the username).
4. Installation options. Organisation name, the public address people use (for share links), the default time zone, the language (American or British English spelling), whether administrators must use two-factor sign-in, whether anyone may create an account, password length, how long a sign-in lasts, people per room, the default technique, how long the activity log is kept, and whether the REST API and Jira are available.
5. License key (optional). Without one, CHIPS runs as the Community edition.
6. Review and install. Nothing is saved before this step; then everything is saved at once and you are signed in as the administrator.

Everything can be changed later under Admin → Settings, which also shows the checks again.

Security and two-factor sign-in

For: Scrum masters and administrators

Two-factor sign-in

Account → Two-factor sign-in → Set up: scan the QR code with an authenticator app (Microsoft Authenticator, Google Authenticator, 1Password, Authy …) and enter the 6-digit code it shows. From then on, signing in asks for your password and then a code from the app.

You also get 10 recovery codes. Each signs you in once if you do not have your phone — keep them in a password manager or printed. New recovery codes replaces them. If you lose both, an administrator can turn two-factor sign-in off for you (Admin → Users, or manage reset-2fa NAME on the server).

Administrators can make two-factor sign-in required for administrators (Admin → Settings). An administrator without it can still sign in, but administration stays locked until it is set up.

Wrong passwords

After 5 wrong passwords within 15 minutes an account is locked for a minute, then longer with every further wrong try (at most an hour). Even the right password waits. An administrator can unlock it at once (Admin → Users → Unlock, or manage unlock NAME). Many wrong passwords from one network address block that address the same way.

How CHIPS protects itself

• Passwords are stored as salted scrypt hashes; sessions, invitation codes, access tokens and recovery codes only as hashes; Jira tokens, OAuth secrets and two-factor keys encrypted with the site secret.
• CHIPS does not start without a long STORAGE_SECRET.
• Pages are sent with a strict content security policy, cannot be framed by other sites, and are not cached. Behind HTTPS, cookies are sent over HTTPS only.
• Error pages show a reference number instead of technical details; the details go to the server log.
• Customer builds are compiled and signed. If files are changed, CHIPS notices and switches off licensed features (see Editions and licensing).
• Every sign-in, failed sign-in, lock and security change is in the activity log.

How CHIPS works (flowcharts)

For: Everyone

These flowcharts show how CHIPS operates. Solid arrows are the usual path; dotted arrows are optional.

The whole process

flowchart TD
    A([Scrum master signs in]) --> B[Create or open a project]
    B --> C[Create a room and choose its rules]
    C --> F[Add user stories: type them, upload a CSV file or import from Jira]
    F --> D[Share the room link]
    D --> E([Team members open the link and type their name])
    E --> G{How to estimate?}
    G -->|one story at a time| H[Pick a technique: planning poker, Fibonacci, t-shirt or three-point]
    H --> J[Everyone votes in secret]
    J --> K[Scrum master reveals the cards]
    K --> L{Agreement?}
    L -->|no: discuss| J
    L -->|yes| M[Record the final estimate]
    G -->|many stories at once| I[Affinity board: the team sorts stories into size columns]
    I --> M
    M --> N{More stories?}
    N -->|yes| G
    N -->|no| O[End the session]
    O --> P[History, CSV download and recording playback]
    M -.->|optional| Q[Update Jira: story points, assignee, priority, versions, labels]

One estimating round

Votes stay secret until the scrum master reveals them — not even the scrum master sees other people's cards before that.

flowchart TD
    S[Story in the backlog] -->|Start| V[Voting: cards face down]
    V -->|each person picks a card or gives three numbers| V
    V -->|Reveal, or automatically when everyone has voted| R[Revealed: cards, statistics and a suggestion]
    R -->|Vote again| V
    R -->|Save estimate| D[Estimated]
    D -->|Vote again| V
    D -.->|Update Jira| J[(Jira issue)]

The affinity board

flowchart TD
    A[Scrum master opens an affinity board and picks the columns] --> B[Every story without an estimate starts in Not sorted yet]
    B --> C[Anyone in the room moves stories into size columns]
    C -->|everyone sees each move at once| C
    C --> D{Scrum master decides}
    D -->|Accept board| E[Each sorted story gets its column as final estimate]
    D -->|Close without saving| F[Nothing changes; the board stays in the history]

Updating Jira

flowchart TD
    A[Update Jira] --> B{Which stories?}
    B -->|this story| T[The story]
    B -->|the room| R[All Jira stories in the room]
    B -->|JQL query| Q[Issues found in Jira, paired with stories by key]
    T --> F[Choose the fields to send]
    R --> F
    Q --> F
    F --> P[Preview: what will be sent, and what not and why]
    P --> U[Update Jira]
    U --> X[Result per issue: updated, partly updated or failed]

How the parts fit together

Everyone uses a browser; the CHIPS server shows the pages, applies the rules and pushes every change to everyone in the room at once. Everything is kept in a PostgreSQL database.

flowchart LR
    subgraph devices [Any device with a web browser - nothing to install]
        P1[Scrum masters and administrators]
        P2[Team members]
    end
    P1 --> APP
    P2 --> APP
    APP[CHIPS server - pages, rules, live updates] --> DB[(PostgreSQL database)]
    APP -->|personal access token| JIRA[Jira]
    APP -->|OAuth 2.0 / OpenID Connect| IDP[Your sign-in provider]
    S[Scripts and tools] -->|REST API with an access token| APP

For team members

For: Team members

Joining

Open the link the scrum master sent you, type your name and press Join room — or Join as watcher to only observe (you see everything but do not vote, add notes or react). Your browser remembers you for that room, so you can close the tab and come back. If the scrum master added you by name, they sent you a personal link instead — it signs you straight in; don't share it.

Voting

When the scrum master starts a story, pick a card. You can change it until the cards are revealed; click your card again to take it back. The table shows who has voted, but nobody — not even the scrum master — sees the cards before Reveal.

• ? is the pass card: you abstain. It counts as having voted, but is left out of the average, the consensus and the outliers. ☕ means "I need a break" (if the room uses them).
• A countdown shows when the room has a timer; when it runs out the cards may be revealed.
• Anonymous voting: after the reveal the cards are shown without names — nobody, not even the scrum master, sees who voted what (you still see your own card).
• Three-point estimation: instead of a card, enter three numbers — optimistic, most likely and pessimistic — and press Submit. You see your own PERT estimate at once.

After the reveal everyone sees the cards, the distribution, the average, median and whether there is a consensus — unless the scrum master hides the results, in which case you only see who voted. Cards far from the rest are ringed in red: if yours is, the team would like to hear why.

Reactions

During the discussion, the emoji buttons under the story (👍 🎉 🤔 …) show a reaction next to your name for a few seconds.

The affinity board

Sometimes the scrum master opens an affinity board to size many stories quickly. Every story starts in Not sorted yet. Move stories with ◀ (smaller) and ▶ (larger), or ⋯ to pick a column. Everyone sees each move at once; talk it through and move stories again if needed.

Notes

Anyone can add a note to a story — under the current story, or with the notes button of a story in the backlog. You can delete your own notes.

Display

The palette button in the header sets dark mode, colours, text size and your time zone — see Display settings.

If the room shows ● Recording, the scrum master is recording the session for playback later.

Projects and rooms

For: Scrum masters

A project groups the rooms of one team or product; a room is where estimating happens (up to 30 people, scrum master included). Rooms and their history belong to the project's scrum master; administrators can manage every project.

Projects page

• New project — name and describe it. The pencil renames it; the archive button hides it (and its rooms) without deleting anything.
• Create room — under the project, with the technique for the first vote.
• Show archived — see archived projects and rooms, and restore them.

Inviting people

• Copy link shares the room link; anyone with it can join while Open to new members is on.
• Add a user creates a seat and a personal link for one person.
• The ⋮ menu next to a person makes them a moderator, a team member or a watcher, or removes them at once (their link stops working). To keep them out, also lock the room (the padlock above the story) or Issue new share link under Rules & sizing.
• See Running a session for moderators, watchers, the timer and more.

Rules & sizing

Estimating a story

For: Scrum masters

flowchart TD
    S[Story in the backlog] -->|Start| V[Voting: cards face down]
    V -->|each person picks a card or gives three numbers| V
    V -->|Reveal, or automatically when everyone has voted| R[Revealed: cards, statistics and a suggestion]
    R -->|Vote again| V
    R -->|Save estimate| D[Estimated]
    D -->|Vote again| V
    D -.->|Update Jira| J[(Jira issue)]

1. Start a story (the ▶ button in the backlog, or Start: … above). The Technique selector above the story chooses how; switching it during a vote starts the vote again the new way.
2. Everyone votes; the table and the team list show who has voted.
3. Reveal cards (or let the room reveal itself when everyone has voted — Rules & sizing).
4. Read the result: distribution, average, median, range, consensus, passes, outliers (ringed in red, with "ask them to explain") and a suggested estimate — the card closest to the room's averaging rule (Rules & sizing → Suggested estimate from: the mean, the median, the most common card, or the mean without the highest and lowest vote; ties go to the larger card; automatic = the mean for numbers and the most common card for sizes and words).
5. Choose the final estimate (the suggestion is pre-selected; you can type another) and Save estimate — or Vote again for a new round after discussing the highest and lowest cards.
6. Next story moves on.

Hide results (switch above the story): team members see who voted, but no values, statistics or final estimates; you still see everything. Anonymous, the padlock (lock the room) and the Timer are next to it — see Running a session. Too big? Quick split… turns the story into an epic with smaller stories — see Epics and quick split.

Every round is kept in the history, including rounds that were voted again.

Running a session

For: Scrum masters

Moderators

Anyone in the room can run the session for you: the ⋮ menu next to their name → Make moderator. A moderator can start votes, reveal, use the timer, record final estimates, edit the backlog and rules, lock the room, hide results and remove team members and watchers — without a CHIPS account. Only the scrum master appoints or removes moderators. Whether moderators also vote is a rule (Moderators vote too).

Watchers

Watchers see the whole session but do not vote, add notes or react — for stakeholders, new team members or a product owner who only listens. People choose Join as watcher on the invitation page, or you switch someone with ⋮ → Make watcher (and back with Make team member). Watchers never count as missing votes.

Timer

Timer above the cards gives everyone 30 seconds to 5 minutes; +30 s adds time and the crossed clock stops it. A timer for every vote is set under Rules & sizing → Timer per vote, which also decides whether the cards are revealed when the time is up (otherwise everyone just sees "Time is up").

Lock, remove, hide

• The padlock above the story locks the room: the share link stops accepting new people (people already in stay). Click it again to unlock.
• ⋮ → Remove from the room kicks someone out at once.
• Hide results keeps the revealed values and statistics from the team.

Anonymous voting

With Anonymous on, the revealed cards are shown without names — to everyone, the scrum master included — and the history, downloads and recordings do not say who voted what either. Turning it off later never reveals the names of a round that was anonymous.

Pass card and outliers

The ? card means pass: the person abstains. It counts as a vote for "everyone has voted" but not in the statistics. After the reveal, votes at least two cards (configurable) away from the median are outliers: ringed in red, with a note to ask those people to explain — a quick way to surface what others may have missed.

Reactions

Everyone except watchers can send emoji reactions during the discussion; they appear next to the person's name and in a short feed for about ten seconds.

Epics and quick split

For: Scrum masters

Big pieces of work are easier to estimate in two steps — trunk-based estimation:

1. Estimate the trunk. Add the work as an Epic (tick Epic when adding, or change the type in the edit dialog) and vote on it like any story. Its estimate is a rough size of the whole.
2. Split it. Quick split… (next to Save estimate, or the split button in the backlog) opens a dialog with ready-made splits you can edit line by line:
3. Equal parts — part 1, part 2, …;
4. SPIDR — spike, paths, interfaces, data, rules;
5. Workflow steps — first, middle and last step, notifications;
6. Create / Read / Update / Delete;
7. My own list.

The new stories go right after the epic and keep its priority, versions and labels. With Vote on the first new story now the next vote starts at once. 3. Estimate the parts. The backlog shows them under the epic with how many are estimated and their total next to the epic's own estimate — so you see at a glance whether the trunk estimate held.

A story that is still a story can be split too: it becomes an epic. Under Rules & sizing → Suggest splitting at, choose an estimate (e.g. 13, or XL): after a reveal at or above it, CHIPS suggests a quick split. The REST API can split as well: POST /api/v1/rooms/{room}/stories/{story}/split.

Sprint capacity

For: Scrum masters

Sprint planning in CHIPS: each person's working days in the sprint, a minimum and maximum of story points they can take on, and the points actually assigned to them — in red when it is more than their maximum.

The team list

Each project has a team list (Projects → the people button on the project, or Team list in a room's capacity panel). For each person:

• Name — as they join rooms and as stories are assigned (matched without regard to capitals).
• Seniority — junior, mid-level, senior or lead; Analytics uses it to check whether estimates follow the most senior person.
• Working days per sprint (or calendar days or hours, see below) — empty means the project's usual number (10 unless changed).
• Minimum and maximum points — empty means the defaults below.

Defaults: one story point is one working day. So the maximum is working days × points per day (10 days → 10 points) and the minimum is half the maximum (10 days → 5 points). Change story points per working day on the team page if your team's points mean something else (e.g. 2 points per day).

In a room, Add everyone in this room puts the team members and moderators who are not on the list yet onto it.

A room is a sprint

The Sprint capacity panel next to the people in a room shows, for everyone on the team list:

• assigned / maximum points — the final estimates (numbers) of the room's stories whose assignee is that person; an epic that was split counts through its stories, not twice;
• the colour: red when over the maximum (with a warning sign), orange when under the minimum, green in between; and a bar for the load;
• working days, minimum, maximum and how many stories.

Below: the total against the team's capacity, points not assigned to anyone, assignees who are not on the team list, and estimates that are not numbers (t-shirt sizes are not counted).

How sprints are measured

On the team page, How sprints are measured sets the unit a project counts sprints and people's time in:

• Working days (the default) — the days of the project's working week (Monday to Friday unless changed, e.g. Sunday to Thursday) without its holidays (one per line: 2026-12-25 Christmas);
• Calendar days — every day, weekends included;
• Hours — working days × hours per day (6 unless changed).

Points per unit, the usual length of a sprint and everyone's own time are all counted in that unit, and the labels change with it ("10 working days", "60 hours"). Switching between days and hours converts the numbers already entered by the hours per day, unless Convert is turned off. The estimate review counts how long stories took in the same unit.

The scrum master (or a moderator) can set sprint dates (the calendar button; CHIPS counts the units between them) and click a person to change their working days or limits for this sprint only — e.g. someone on holiday for three days. Use the team list removes the sprint's values again.

Assign stories in the story's Edit dialog; the assignee field suggests the names on the team list. When the scrum master hides story point values from the team, the capacity panel is hidden from the team too.

Delivery

For Analytics, a story can also record its delivery: when work started and was done, defects found, times reopened (rework) and sprints carried over — under Edit → Delivery, or read from Jira with Delivery from Jira (started = the first move out of To Do, done = the resolution date, reopened = moves from a done status back to an open one, defects = linked or sub-task bugs, carried over = sprints in the Sprint field minus one).

Analytics

For: Scrum masters and administrators

Analytics (in the header, or the chart button on a project) is part of the Enterprise edition. Choose the project, the period (the last 90 days, 6 months, 12 months or all time) and, for the forecast, a date. Every table can be downloaded as CSV.

People are matched by name across the project's rooms, the team list and assignees. Votes from anonymous rounds are never attributed to anyone — they count only in team figures such as spread. ? (pass) and ☕ are not estimates.

Estimators

• Above, on or below the final estimate — each person's first vote on a story (before discussion) against the estimate the team chose; the average difference in cards and a tendency (estimates high, estimates low, close to the team).
• Highest and lowest — how often a person had the highest or the lowest vote, in rounds with at least three voters who did not all agree.
• Passes and notes written.

Velocity

Each room is a sprint: planned points (estimated in the room) and delivered points (stories done — by the sprint's end date if it has one), the ratio, and the team's capacity and utilisation from the capacity panel. Contribution by person adds up the delivered points of the stories each person owned (the assignee) and their share of the team's velocity.

Agreement

The spread of first-round votes per story (cards between the lowest and the highest vote; for three-point estimates, the variation), how often the team agreed at once, how often it voted again, by technique, and the most divergent stories first — the ones the team understood differently.

Anchoring

Do estimates converge toward the first person to comment (the first note after the reveal) or the most senior voter (from the team list)? For each story CHIPS takes the middle of the first, pre-discussion votes and the final estimate, and measures how far the estimate moved toward that person's first vote (100% = all the way) compared with how far it moved toward everyone else's. A difference of 15 points or more over at least five stories reads estimates converge toward this person. Influence by person shows the same pull for everyone, how often their first vote became the final estimate, and how often they commented first. Re-votes show how much the spread shrank after discussion.

Quality

For delivered stories: defects per story and per 10 points, the share reopened (rework) and the share carried over to a later sprint, and the median cycle time — by owner (assignee) and by estimator (stories whose final estimate was that person's first vote). They are signals for a conversation, not a score.

Forecast

A Monte Carlo forecast: 10,000 simulated futures, each week drawing a random week of real throughput from the last 12 weeks, until the remaining stories (or points) are done. It shows the dates by which 50%, 70%, 85% and 95% of the futures finished, the distribution, and the chance that everything is done by your date.

Points vs time

Whether story points predict cycle time (started → done): the Spearman correlation (order of sizes against order of durations), Pearson and R², a scatter chart with a trend line, cycle time by size (box plot), and whose first votes predict duration best.

Missed estimates

From the estimate review: how many finished or due stories ran over their estimate, the reasons ranked in a Pareto chart (the few reasons behind 80% of the misses), by category and by whether they are within the team's control, sprint by sprint, and what each reason costs (points over the estimate, how many times its estimate a story took). It also shows what goes with running over — story size, assignee, seniority, technique, and how far apart the first votes were — which reasons come together, the stories still without a reason, and the risk for the sprints still open: each open story's chance of running over, from how often stories of its size ran over before. What stands out puts the main findings in words.

More

Trends by sprint — the median story size and days per point (size drift or point inflation); epics — the trunk estimate against the sum of their stories; estimation effort — minutes per round and rounds per story.

Delivery data comes from Edit → Delivery on a story or from Delivery from Jira (on this page for the whole project, or in a room) — see Sprint capacity. The REST API has the whole report: GET /api/v1/projects/{id}/analytics?period=180.

Estimate review

For: Scrum masters and administrators

The estimate review (Enterprise edition; the demo project in every edition) is on each project: the ✓ list button on the dashboard, Open the estimate review in Analytics, or Estimate review in a story's edit dialog in a room.

When does a story run over its estimate?

CHIPS works it out from the delivery data. A story ran over when

• it was carried over to a later sprint, or not done by the end of its sprint;
• it took more working days (Monday to Friday, start and done both counted) than its points ÷ the project's points per day, by more than the margin (25% unless changed on the Reasons tab) and by more than one day; or
• the actual effort you recorded, in story points, is above the estimate by more than the margin.

You can always overrule it: over its estimate or within its estimate. Stories that are not finished while their sprint is still running are open.

Giving reasons

The Stories tab lists the stories that ran over (or those without a reason yet, those within their estimate, open ones, or all), sprint by sprint. For each one CHIPS says why it flagged it. Pick one or more reasons right on the card — the first is the main reason — or open the review (✎) to set the outcome, the main reason, the actual effort in points and a note. Giving a reason marks the story as over its estimate.

The list of reasons

Each project has its own list on the Reasons tab. Add the standard reasons adds twelve common ones in six categories — requirements, technical, dependencies, people and availability, process, outside the team — each marked as within the team's control or not. Edit them, add your own, and retire the ones you no longer want: a reason that has been given stays on its stories (and in the analytics); only unused reasons can be deleted.

Past sprints

The Past sprints tab brings in sprints planned before CHIPS, so the review and Analytics cover them. Each sprint becomes an archived room (it does not count as an active room) with its dates, stories, story points, assignees and delivery data.

• From Jira — a JQL query, for example project = ABC AND sprint in closedSprints(). CHIPS reads each issue's sprints, story points, assignee, status history, linked bugs and resolution date. A story goes to the sprint it was first planned in; each later sprint counts as a carry-over. Only closed sprints are imported unless you include the one running now. Issues already estimated in a CHIPS room of the project are not copied: their delivery data is read instead.
• From a file — a CSV file, one row per story. Sprint and Title (or Key) are needed; Sprint start, Sprint end, Story points, Assignee, Started, Done (YYYY-MM-DD), Defects, Reopened, Carried over, Actual points, Outcome (missed / met), Reasons (separated by ; or |) and Note are read when present. Download the example file to start from.

Preview shows what would be imported; nothing changes until you import. Importing again updates the same sprints and stories and keeps the reasons already given.

The REST API has it all: GET /api/v1/projects/{id}/review, …/review/reasons, PUT /api/v1/stories/{id}/review, POST …/review/import/jira and …/review/import/file.

The demo area

For: Scrum masters and administrators

Projects → Demo (or /demo) makes a ready-made project, CHIPS demo, in a few seconds. There is one demo per installation; every scrum master and administrator can open, use, reset and remove it.

What is in it

• The room Demo · Sprint 12 planning — the sprint being planned now. It is one of your edition's active rooms (Community allows five), so the demo needs one free room.
• People: Sam (scrum master), Morgan (moderator), Wes (a watcher — the product owner) and five team members, Ann, Bob, Cat, Dan and Eve, all on the project's team list with seniority and working days.
• 19 user stories (with keys DEMO-101 …) and an epic, Checkout redesign, split into four stories. Twelve stories are estimated — with votes, notes and some second rounds — and assigned; some are in progress or done; the rest wait in the backlog. One revealed round is left on the table, with an outlier to discuss. Ann has more points than her maximum, so the capacity panel shows red.
• Three earlier sprints (9, 10 and 11) as archived rooms: they do not use active rooms, and give the analytics their history — velocity, delivery, defects and carry-over. They were estimated with every technique: Fibonacci, planning poker, t-shirt sizes, three-point estimates and an affinity board; their stories that ran over were reviewed with reasons (the estimate review).
• Planning (Plan): eight stories in the project backlog for the next sprints, ranked by WSJF, with RICE and value ÷ effort scores and a target date; acceptance criteria (Given / When / Then and rules) on sprint stories; dependencies with their badges, steps and critical path; eight requirements — three non-functional, some imported from a spreadsheet — traced to stories with their coverage; four risks with ROAM; decisions and assumptions recorded in the room; Morgan half-time and Eve at 80% availability, and a company holiday ahead; story priorities, labels and versions; one story pinned to its sprint.
• The call: the room's call is a Teams meeting with a dial-in number; the refinement call was recorded and transcribed, with each speaker named from the Teams transcript (Conference calls).

The demo page lists every feature with what the demo shows of it and a button to open it.

What each edition adds, shown with the demo

• Analytics (Enterprise) — the demo project's analytics are shown in every edition: Dan tends to estimate high, Cat low, and estimates drift toward Ann, the lead.
• Recording and playback (Team, Enterprise) — the first stories of the demo sprint were recorded; play them back in any edition.
• Activity log (Enterprise download) — every step of the demo sprint was logged; the demo page shows the latest entries and downloads the demo's part as CSV.
• REST API (Team, Enterprise) — example requests and what the API answers for the demo room.
• Jira (Team, Enterprise) and single sign-on (Enterprise) — explained, with a preview.

Reset throws away whatever was done in the demo and makes it again; Remove deletes it and frees its room. The people are invented; everything else was made with the same rules as real rooms.

Estimation techniques

For: Scrum masters

Choose the technique story by story with the Technique selector — one session can mix all six.

Custom decks

Under Rules & sizing → Custom deck give the deck a name and its cards, smallest first (presets: hours, days, fist of five, risk, animals). Save as my deck keeps it for your other rooms; My decks fills it in again. The pass (?) and break (☕) cards are added as for every deck. Affinity boards can use the custom deck as their columns.

Three-point estimation

Each person's estimate is (O + 4M + P) / 6. The team's estimate uses the averages of everyone's three numbers; the standard deviation (P − O) / 6 gives the likely range (estimate ± 2σ). The final estimate offers the PERT estimate, rounded up, and the top of the range.

Affinity estimation

Press Affinity estimation and choose the columns. While the board is open, no single story is voted on; ending the session closes the board without saving. With values hidden, team members see Size 1 · smallest … instead of the values.

flowchart TD
    A[Scrum master opens an affinity board and picks the columns] --> B[Every story without an estimate starts in Not sorted yet]
    B --> C[Anyone in the room moves stories into size columns]
    C -->|everyone sees each move at once| C
    C --> D{Scrum master decides}
    D -->|Accept board| E[Each sorted story gets its column as final estimate]
    D -->|Close without saving| F[Nothing changes; the board stays in the history]

User stories and attributes

For: Scrum masters

Adding stories

• Type a key (optional, e.g. ABC-123), a title and details (Markdown) and press Add.
• Add several at once — one title per line.
• Import — from a CSV file or from Jira.

Editing and attributes

The pencil button of a story edits its title, key and details, and its attributes:

• Assignee — for Jira stories, Find in Jira lists the people who can be assigned the issue; picking one ties the story to that Jira user ("✓ Jira user").
• Priority — Highest … Lowest, or Jira's priorities (type your own if needed).
• Fix versions and Affects versions — several each; Jira's versions are offered when connected.
• Labels — type a label and press Enter; no spaces.

Everyone sees the attributes on the story and in the backlog; they go into history and downloads, and you can send them to Jira.

Removing

The delete button removes a story from the backlog; if it was voted on or has notes, its history is kept.

Notes

Anyone can add notes; authors and the scrum master can delete them. Notes appear for everyone at once.

Uploading and downloading (CSV)

For: Scrum masters

Upload stories

Import → Upload a CSV file. The file needs a header row and at most 10 columns (500 stories, 1 MB). Columns are recognised by their headers — you can change the mapping in the preview:

Stories whose key is already in the room can be skipped. A Jira CSV export works as it is.

Download results

Download results → This session or All stories in this room, or any session from History. One row per story: key, title, attributes, technique, final estimate, votes of the last round, statistics and notes. The file opens correctly in Excel (UTF-8), and text that would run as a spreadsheet formula is made harmless.

Jira

For: Scrum masters

Connect

On Account → Jira connections:

• Jira Data Center / Server / Service Management — a personal access token (your Jira profile → Personal Access Tokens).
• Jira Cloud — an API token from id.atlassian.com, with your account's email.

The token is checked against Jira and stored encrypted. Your administrator may limit which Jira servers can be used.

Import

Import → Import from Jira, type a JQL query (e.g. project = ABC AND sprint in openSprints()), Preview, Import. Issues become stories with their key (linked to Jira), summary, description, assignee, priority, versions and labels.

Update Jira

Update Jira above the backlog, or a story's cloud button:

flowchart TD
    A[Update Jira] --> B{Which stories?}
    B -->|this story| T[The story]
    B -->|the room| R[All Jira stories in the room]
    B -->|JQL query| Q[Issues found in Jira, paired with stories by key]
    T --> F[Choose the fields to send]
    R --> F
    Q --> F
    F --> P[Preview: what will be sent, and what not and why]
    P --> U[Update Jira]
    U --> X[Result per issue: updated, partly updated or failed]

• Which stories — this story; all Jira stories in the room; or the issues a JQL query finds (paired with the room's stories by key).
• Which fields — story points, assignee, priority, fix versions, affected versions, labels.
• Empty values are not sent unless you tick Also clear fields in Jira that are empty here.
• If Jira refuses a field (e.g. an unknown version), the other fields are still sent.
• The cloud button of each story turns green when the issue is up to date, red with the reason if not.

Story points must be numbers: t-shirt sizes are not sent. With Send final estimates of Jira stories to Jira on (Rules & sizing), each saved estimate goes to Jira at once.

Recording and playback

For: Scrum masters

Press Record in the room. Every step is captured — stories started, who voted, reveals, estimates, notes, affinity moves, people joining and leaving — with how the room looked afterwards. Everyone in the room sees ● Recording. Press the stop button to finish; ending the session or archiving the room also stops it.

Find recordings under History (and on each session's page). The player has:

• play / pause, previous and next step, start and end, and a timeline slider;
• speeds from 1× to 16×, and Skip pauses (long waits last at most 2 seconds);
• the list of steps — click one to jump to it.

Votes stay face down until the moment they were revealed, exactly as in the room. Recordings can be renamed, deleted or downloaded (JSON). Only the room's scrum master and administrators can see them.

Planning: backlog, requirements, risks and forecasts

For: Scrum masters

Plan (the timeline button on a project) is where a project's work is shaped before and between sprints. Each room is a sprint; the backlog holds the stories not yet in a sprint.

Backlog and ranking

Add stories to the backlog (key, title, points), and rank them: to the top, up or down one. In the Team and Enterprise editions, give stories scores and rank the whole backlog by one of them:

• RICE = reach × impact (0.25 minimal … 3 massive) × confidence % ÷ effort;
• WSJF (weighted shortest job first) = (business value + time criticality + risk reduction) ÷ job size;
• value ÷ effort.

Effort is the story's points unless an effort is given. Stories without the chosen score keep their order below the others. Move into a sprint puts a story in a room (at the end of its stories); an epic takes its stories along. Stories can go back to the backlog unless they are being estimated.

A story's planning details

The ✔ button on a story (in the backlog or a room) opens:

• Acceptance criteria — rules, checklist items or Given / When / Then scenarios; tick them when met. The team sees them under the story while voting.
• Dependencies — what the story can only be finished after. Loops are refused.
• Requirements — which requirements it implements.
• Priority & dates — scores, a target date, and pinned (auto-scheduling leaves it where it is).

In rooms and the backlog, badges show a story's dependencies: ↳ after X (worked on first, in the same sprint), ⛔ after X in red (a conflict: X is planned later or still in the backlog), 🔗 blocks N, the step in the sprint's order of work, criteria met (✓ 2/3) and requirement keys.

Requirements

Write requirements (key, title, description, functional or non-functional with a category such as performance or security, MoSCoW priority, status, source) and link the stories that implement them. Team and Enterprise also import a CSV file (columns by name: Key, Title, Description, Type, Category, Priority, Status, Source, Stories — story keys to link; existing keys are updated; an example file is provided) and show coverage: the share of a requirement's story points that are delivered (a story is delivered when its done date is recorded, or when it was estimated in a finished sprint).

Team capacity

Capacity is the total of everyone's availability: each person's days (or hours) in the sprint × their availability % (part-time, other duties; set on the Team page, or per sprint in the room) × points per unit. The capacity panel and the sprint plan show it.

Sprint plan

For each open sprint: its load against the team's capacity, its conflicts (dependencies planned later or not at all, sprints over capacity, people over their limit, target dates the plan misses), and the order of work: stories in one step can be worked on at the same time (concurrent); steps follow each other (sequential). The critical path is the longest chain of dependent open stories — the work that decides the earliest finish.

Auto-schedule (Enterprise) proposes a plan: stories in rank order, each after the stories it depends on, in the first sprint with room for the team (capacity × focus factor) and for its assignee. Unestimated stories count as the default size; stories larger than a sprint are reported (split them). Sprints are proposed after the last one while needed. Preview first; Apply moves the stories and creates rooms for the proposed sprints.

Relationship map

Map draws the project as one picture. Time runs down the timeline on the left, day by day, one band per sprint (the current one marked, with a Today line). Each user story is a bar from the day it is planned to start to the day it should be finished, so the more points, the longer the bar. The sprint's people work through its stories in rank order, one at a time each: a story assigned to someone waits until they are free, any other goes to whoever is free first, and a story that depends on others starts only when they are finished — so dependent stories line up one after the other. A day per point is the sprint's length over each person's share of its capacity (Plan → Capacity); an unestimated story is drawn, dashed, with the project's default size. A bar with a red border finishes after its sprint ends; work that runs on past the last sprint shows under After the last sprint. Finished sprints show their delivered stories within the sprint. Stories still in the backlog wait under Not scheduled. Around them, each in its own column and next to the stories it concerns: requirements (left), decisions, assumptions, risks and people (right).

The lines show how things are related: an arrow from a story to the stories that depend on it (red and dashed when they are planned in the wrong order), a dotted line from an epic to its parts, and lines from the requirements a story delivers, the decisions and assumptions about it, the risks that threaten it and the person it is assigned to. Stories on the critical path have a gold border; delivered ones are grey.

Editing on the map. Choose what dragging does under Drag to:

• Move stories (the default) — drag a story up or down to change the day it starts, into another sprint, or down into the backlog. Dropping it at the top of a sprint lets it start with the sprint again. The stories that depend on it move along. A story never starts before what it depends on is finished, nor before someone is free: if it cannot start on the day you chose, the message says why. Stories of finished sprints stay where they are.
• Link items — drag one item onto another to link them: a story onto a story it must come before (the second then depends on the first), an epic onto a story (the story becomes part of it), or a requirement, decision, assumption, risk or person onto a story (it implements it, is about it, threatens it, is assigned to them). A decision, an assumption or a person is linked to one story at a time: linking moves it.
• Look only — nothing moves; hover and select as usual.

Select a line to see what it means and remove it (a dependency can also be reversed). After each change an Undo button puts things back. Changing the map needs the right to plan the project (its scrum master or an administrator).

Use the Show boxes to make each type visible or not (people and finished sprints are left out at first, to keep the picture calm), and choose how many finished sprints to include. Hover over anything to see its details — for a story, when it starts and finishes and what it waits for — and highlight everything linked to it; select a story to open its planning details. The map is in every edition; risks appear where the risk register is (Team and Enterprise).

Risks (Team and Enterprise)

A risk register: likelihood and impact (1–5; the score is their product: critical from 15), ROAM status — resolved, owned, accepted, mitigated (or still open) — owner, mitigation, target date, the sprint and the stories at risk. Risks on stories of the critical path are marked. A 5 × 5 matrix shows where they are.

Forecast and what-if (Enterprise)

When will the remaining work be done? A straight line at the expected velocity (recent finished sprints, or the team's capacity), and a Monte Carlo simulation from past sprints with 50 / 85 / 95 % dates. Change the what-if values — capacity, people joining or leaving, scope, velocity, focus factor — and compare with the baseline. Projected flow shows each future sprint's stories and points; flow metrics show throughput, cycle and lead time, work in progress, and the cycle time to expect at the current WIP (Little's law).

Decisions and assumptions

During planning the scrum master or a moderator records decisions (proposed, agreed, superseded) and assumptions (to be checked, validated, invalidated) in the room's panel; everyone in the room sees them, and Plan → Decisions lists those of every sprint. In every edition.

Conference calls

For: Scrum masters

A room can have a call — the meeting the team talks in while estimating:

• Microsoft Teams, Google Meet, Zoom — the meeting's link; and its dial-in number and PIN, if it has them;
• Phone conference — a dial-in number and PIN (conference ID);
• Other call link — any https:// link.

(Skype was retired by Microsoft in May 2025 — its users moved to Teams; Google Talk is now Google Meet.)

Everyone in the room sees the Call panel with Join the call and Dial in, which calls the number and enters the PIN on phones and computers with a phone app. The scrum master sets the call with the settings button on the panel, or — with Microsoft, Google or Zoom connected (Enterprise edition) — creates a new Teams, Meet or Zoom meeting for the room in one click.

Recording (Team and Enterprise editions)

The call settings say how calls in the room are recorded: never, ask each time, in the scrum master's browser, with the meeting's own recording (Teams, Meet or Zoom), or both.

Record the call records in the scrum master's browser: the microphone and, if chosen, the sound of the call — the browser asks which tab or window to share; pick the call's tab and turn on Share tab audio (a call in the Teams or Zoom app: share the screen with its sound, on Windows and ChromeOS). Before it starts, the scrum master must confirm that everyone on the call was told it is recorded — recording people without telling them is unlawful in many places — and CHIPS keeps that confirmation with the recording. While it runs, everyone in the room sees ● This call is being recorded. The audio is sent to the CHIPS server every few seconds; keep the room open until you press stop.

With the meeting's own recording, start recording and transcription in Teams, Meet or Zoom as usual; after the call, Fetch from Teams/Meet/Zoom on the room's recordings page reads the meeting's transcript (with names) and the link to its recording, which stays with the platform.

Transcripts — English only

CHIPS transcribes recordings on its own server (the audio does not leave it), once an administrator has installed speech recognition. It first detects the language: calls in English are transcribed; others are marked Not English and kept as audio. The meeting's own transcripts are kept only when they are in English, too.

On a recording's page: play the audio, click a time to play from there, and download the transcript as text, WebVTT subtitles or CSV. Transcribe again after a change of the speech model.

Who said what

CHIPS's transcript does not know the speakers by itself. When the room's call is a Teams, Meet or Zoom meeting and the scrum master has connected Microsoft or Google (Account → Meetings; Zoom is set up once by an administrator), Fetch also lines up the meeting's transcript with CHIPS's recording of the same call by time, and puts each speaker's name on CHIPS's transcript. Names that match a CHIPS account (by email address or name) are linked to it. Click any speaker to name or correct them by hand — for one line or every line with the same label.

For administrators

Admin → Settings → Conference calls: whether scrum masters may record, how long recordings are kept (90 days unless changed; 0 = forever), transcription on or off and its speech model (tiny is fastest, medium most accurate), and the Zoom app. Install speech recognition with the installer option --with-transcription (or pip install faster-whisper in CHIPS's Python environment); the model is downloaded the first time it is used, or ahead of time with python -m scrumpoker.manage transcription download. Teams and Meet use the Microsoft and Google sign-in providers (Admin → Sign-in providers): their apps need the meeting permissions (Microsoft Graph OnlineMeetings.ReadWrite, OnlineMeetingTranscript.Read.All, OnlineMeetingRecording.Read.All; Google meetings.space.created, meetings.space.readonly) and the redirect address <public address>/auth/meetings/<provider>/callback.

Sessions and history

For: Scrum masters

A session starts with the first vote in a room and ends when you press the stop button next to the session name, or after a long pause (8 hours by default). Every round is kept: who voted what, the statistics, the final estimates, the technique, the notes and any affinity boards.

History lists sessions (yours; administrators can see everyone's) with filters by project and room, and the room's recordings. Open a session to see every round, rename it or download its results. Values hidden from the team during a session are shown here, because only the room's scrum master and administrators can open the history.

Removing a story or archiving a room keeps its history; only an administrator can delete a room or project permanently.

Display settings

For: Everyone

Press the palette button in the header (also in the user menu and on the Account page):

• Theme — follow your device, light or dark.
• Accent colour — eight colours.
• Text size — small, normal, large, larger.
• Time zone — dates and times on the pages (downloads are always in UTC).
• Compact spacing and Reduce motion.

Changes show at once; Save keeps them, Cancel goes back. Team members' settings are remembered in their browser; scrum masters' and administrators' settings are saved with their account and follow them to other devices.

Administration

For: Administrators

Admin (administrators only) has these tabs:

• Users — add people (with a password, or without one if they sign in through a provider), change roles, disable accounts, set passwords, sign someone out everywhere, delete accounts. There is always at least one active administrator.
• Projects & rooms — every project and room: rename, hand over to another user, archive or restore, open any room (you act as its scrum master), delete permanently.
• Sessions — the latest sessions everywhere.
• Sign-in providers — OAuth 2.0 / OpenID Connect (Signing in).
• Access tokens — every personal access token, with revoke.
• Activity log — see Activity log.
• Settings — the security and installation checks; organisation name, public address, default time zone and language (American or British English); self-registration, password sign-in, two-factor sign-in for administrators, password length, how long a sign-in lasts; users per room, session pause, default technique; REST API and Jira on or off, allowed Jira servers; log retention and room activity logging.

Users show badges for two-factor sign-in and locked accounts; the buttons next to them unlock an account or turn two-factor sign-in off (for someone who lost their phone).

On the server, python -m scrumpoker.manage can also create users, reset passwords, change roles, list users, show the version, truncate the log, make a setup code (setup-code), unlock accounts (unlock NAME), turn off two-factor sign-in (reset-2fa NAME) and run the checks (security-check) — useful when nobody can sign in.

Activity log

For: Administrators

Everything CHIPS does on someone's behalf is logged: sign-ins (and failed attempts), administration, projects, rooms, stories, voting, notes, imports, Jira, sign-in providers, access tokens, recordings, and the software's own start, stop and errors. Each entry has the time, level, category, who did it, their IP address, the room and the details.

Never logged: passwords, tokens and vote values — the log says that someone voted, not what.

Admin → Activity log: search (text, person, room, IP), filter by category, level and dates, open an entry for its details, page through with Newer / Older, Download CSV.

Truncate log… deletes all entries, entries older than a number of days, or entries before a date. The truncation itself is always recorded. Automatic retention (90 days by default) and whether to log room activity are under Admin → Settings.

Editions and licensing

For: Administrators

CHIPS comes in three editions. Without a license key it runs as Community — free, with limits. A license key from the vendor unlocks Team or Enterprise.

Team members who join rooms by link never use a seat. The activity log itself is always kept and viewable by administrators.

Installing a license key

Admin → License: paste the key (it starts with CHIPS1.) and press Install key. The page shows the edition, the licensee, the expiry, the seats and rooms in use, and the installation ID — the vendor can bind a key to it so it works only on this installation. On the server you can also run python -m scrumpoker.manage license install KEY (or license show).

Keys are checked offline with a digital signature: CHIPS never contacts a license server and sends no usage data. A key cannot be edited — changing it breaks the signature.

Expiry

Thirty days before a key expires, administrators see a reminder. After the expiry date everything keeps working for a 14-day grace period; then CHIPS runs as the Community edition until a renewed key is installed. No data is ever deleted: limits only stop adding accounts or rooms, and features of a higher edition stop being usable — existing rooms, stories, history and recordings stay.

When a limit is reached

Creating one more account or room beyond the edition's limit is refused with an explanation; disable an account, archive a room, or install a key with more seats. Using a feature of a higher edition shows which edition it needs.

Protected builds

The packages customers install contain CHIPS compiled to native code, without its source, and a list of every file signed by the vendor. When CHIPS starts it checks that list; if a file was changed, removed or added, it runs as the Community edition, tells administrators that the installation was modified and writes this in the activity log. Reinstalling from the original package fixes it; no data is lost. Admin → Settings → Security and installation checks shows the result.

The license agreement the first administrator accepted, and the third-party notices, are under Legal.

Signing in, OAuth and access tokens

For: Scrum masters and administrators

Signing in

Scrum masters and administrators sign in with a username and password, or with their organisation's account (Sign in with … on the start page) if an administrator set up a provider. Team members never need an account.

OAuth 2.0 / OpenID Connect (administrators)

Admin → Sign-in providers → Add: Google, Microsoft Entra ID, GitHub, Atlassian, any OpenID Connect provider or any OAuth 2.0 provider. Register CHIPS with the provider using the redirect URI shown, enter the client ID and secret, and choose whether a first sign-in creates an account and which email domains are allowed. People can also link a provider to their account on the Account page.

Personal access tokens

Account → Personal access tokens → Create: a token for scripts and tools, read-only or read and write, with an expiry. It is shown once — copy it. Use it like a Jira PAT: Authorization: Bearer spk_…. Revoke it on the same page.

REST API

For: Developers

The REST API is at /api/v1; interactive documentation at <your CHIPS address>/api/v1/docs. Authenticate with a personal access token:

TOKEN=spk_…
curl -H "Authorization: Bearer $TOKEN" https://chips.example.com/api/v1/projects
curl -H "Authorization: Bearer $TOKEN" -H "Content-Type: text/csv" --data-binary @stories.csv \
     https://chips.example.com/api/v1/rooms/ROOM_ID/stories/csv
curl -H "Authorization: Bearer $TOKEN" -o results.csv https://chips.example.com/api/v1/rooms/ROOM_ID/results

Projects, rooms, stories (add, change, attributes), notes, sessions and results, recordings, Jira preview and update, and for administrators users and the activity log. Permissions are the same as on the pages; read-only tokens can only read. GET /api/v1/health shows the version.

Troubleshooting and FAQ

For: Everyone

I can't join the room. The link may be old (the scrum master issued a new one), the room may be closed to new members, or full (30 people). Ask the scrum master for a new link.

"You were removed from this room." The scrum master removed you; ask them to add you again.

I don't see the cards' values after the reveal. The scrum master is hiding story point values.

"The database is unavailable — retrying…" CHIPS can't reach its database; it keeps retrying. Tell your administrator if it lasts.

My screen doesn't update. Changes appear at once; if not, reload the page. Very old browsers are not supported.

Jira says the token is not accepted. Create a new personal access token (or Cloud API token) and add the connection again on the Account page. Jira Cloud needs the email address of the token's account.

A fix version is refused by Jira. The version must exist in the issue's project; pick one from the list Jira offers in the story's edit dialog.

Dates show the wrong time. Set your time zone in Display settings.

Nobody can sign in any more. On the server: python -m scrumpoker.manage reset-password NAME or create-admin NAME (see the README).

"Too many failed sign-ins." Wait the minutes shown, or ask an administrator to unlock the account.

I lost the phone with my authenticator app. Sign in with a recovery code, or ask an administrator to turn two-factor sign-in off for you, then set it up again.

Where is the setup code? In the installer's output and the server log; on the server python -m scrumpoker.manage setup-code makes a new one (Setting up CHIPS).

"This installation of CHIPS has been modified." Files of the installation were changed or added. Reinstall CHIPS from the original package; your data is not affected.

Which version is this? See About CHIPS.

About CHIPS

For: Everyone

CHIPS 2.2.0 — released 2026-11-01. Made by EEZEEZEE.

CHIPS stands for Collaborative Heuristic for Iterative Planning and Story-pointing: a team estimating together (collaborative), using quick rules of thumb such as planning poker, t-shirt sizes and affinity sorting (heuristic), sprint after sprint (iterative), to plan work and give user stories their points (planning and story-pointing).

Built with Python, NiceGUI, FastAPI and PostgreSQL. Versions follow semantic versioning (MAJOR.MINOR.PATCH); the database has its own schema version, shown under Admin → Settings.

What's new in 2.2.0

• An editable relationship map: drag a story to another day, sprint or the backlog; drag a requirement, decision, assumption, risk or person onto a story to link it; select a line to remove it or reverse a dependency; undo any change.
• A timeline in days: each story is a bar as long as its points, spread over the sprint's people in rank order; dependent stories start when what they need is finished; work that will not fit its sprint shows in red.

2.1.0

• Relationship map: every story on a timeline of the sprints, with its dependencies, requirements, decisions, assumptions, risks and people; hover over a story for its description, or over a line for what it means; show or hide each type.
• Decisions and assumptions can be about a story.
• Fixed: Copy link works when CHIPS is opened over plain HTTP by its address.

2.0.0

• Planning: a ranked project backlog (by hand, or by RICE, WSJF or value ÷ effort), acceptance criteria, dependencies between stories with badges and conflict warnings, requirements (functional and non-functional, written here or imported from CSV) traced to stories with coverage, team capacity as the total of everyone's availability, the sprint plan with sequential and concurrent steps and the critical path, risks with ROAM, auto-scheduling, what-if forecasts with flow metrics, and a log of decisions and assumptions.

1.9.0

• How sprints are measured: working days (with your own working week and holidays), calendar days or hours.
• Conference calls: join the room's Teams, Meet, Zoom or phone call; record it in the browser; English transcripts on your server; speakers named from Teams, Meet and Zoom transcripts.

1.8.0

• Estimate review (Enterprise): why stories ran over their estimate, past sprints from Jira or a file, and missed-estimate analytics.

1.7.0

• The Apache web server in front of CHIPS, HTTPS with Let's Encrypt, and installation on AWS.
• A demo area in every edition.

1.6.0

• Sprint capacity: a team list with working days per person, minimum and maximum story points (1 point = 1 day by default), and a capacity panel in each room that turns red when someone has more than their maximum. Stories record delivery: started, done, defects, rework, carry-over.
• Analytics (Enterprise): estimator behaviour, highest and lowest estimators, velocity contribution, agreement, anchoring and influence, quality by owner, Monte Carlo forecasts and points versus cycle time.

1.5.0

• American or British English: the administrator chooses which spelling menus, messages and help use, in the setup wizard or under Admin → Settings.
• CHIPS is made by EEZEEZEE, shown on the welcome page.

Earlier releases

• Moderators and watchers, kicking and locking, hiding results and anonymous voting (Running a session).
• Custom decks, the pass card, a voting timer, outlier highlighting, averaging rules and emoji reactions.
• Epics with trunk estimates and quick split (Epics and quick split).
• CHIPS can be hosted on Windows (11, Server 2022 / 2025) as well as Linux and macOS.
• A welcome page with the full name, and a setup wizard protected by a one-time setup code.
• Two-factor sign-in, locking after repeated wrong passwords, a password policy and security checks.
• Compiled, signed customer builds that detect changes.

The license agreement and third-party notices are under Legal.