CHIPSCollaborative Heuristic for Iterative Planning and Story-pointing · documentation for version 2.2.0

Changelog — CHIPS

CHIPS — Collaborative Heuristic for Iterative Planning and Story-pointing. Versions follow semantic versioning: MAJOR.MINOR.PATCH. The version is in scrumpoker/version.py; the database has its own schema version (Admin → Settings shows both).

2.2.0 — 2026-11-01

  1. An editable relationship map. Under Drag to: Move stories — drag a story up or down the timeline to change the day it starts, into another sprint or back to the backlog; Link items — drag one item onto another to link them (a story onto a story it must come before, an epic onto a story, a requirement, decision, assumption, risk or person onto a story). Select a line to remove it, or reverse a dependency. Every change can be undone. REST API: POST/DELETE /api/v1/projects/{id}/map/links, PUT /api/v1/stories/{id}/schedule.
  2. A timeline in days. Each sprint is as tall as its days; each story is a bar from the day it starts to the day it should be finished, as long as its points (the sprint's length over each person's share of its capacity). The sprint's people work through its stories in rank order; a story waits for the person it is assigned to and for the stories it depends on, so dependent stories line up after them. Bars that run past their sprint have a red border; hovering shows when a story starts and finishes and what it waits for. Dates down the timeline.
  3. Database schema 13: a story's planned start day.

2.1.0 — 2026-11-01

  1. Relationship map (Plan → Map, every edition): user stories and epics on a timeline of the sprints, with the requirements, decisions, assumptions, risks and people linked to them, and the dependencies between stories (conflicts in red, the critical path marked). Each type can be shown or hidden; hover highlights everything linked to an item; select a story to open it. REST API: /api/v1/projects/{id}/map.
  2. Decisions and assumptions about a story: choose the story when recording one, in the room or on the Decisions page; the story is shown with it. The demo's decisions and assumptions are linked to their stories.
  3. The map explains itself: hovering over a story shows its description; hovering over a line says what the link means in words (which story must come first and where each is planned, which requirement a story implements, what a risk threatens and its mitigation, who recorded a decision); the legend explains each line.
  4. Demo: every story has a description; a dependency planned in the wrong order (“Cart reminders” needs a backlog story); a further decision and an open assumption, each about a story.
  5. Website: a page per feature (estimation, sprint planning, relationship map, analytics and forecasts, calls, demo, security), each with screenshots of the demo, plus pricing and download pages; the top bar holds only Pricing, Documentation and Get CHIPS.
  6. Fixed: Copy link (room share link, project list, personal links, access tokens, installation ID) did nothing when CHIPS was opened over plain HTTP by its address, and said "copied" anyway. Copying now happens in the browser during the click, with a fallback for plain HTTP; if the browser still refuses, CHIPS says so and selects the link to copy by hand.

2.0.0 — 2026-11-01

Planning. CHIPS 2.0 adds a planning workspace to every project (Plan, /projects/{id}/plan).

  1. Project backlog and ranking — stories belong to their project; those not in a sprint wait in a ranked backlog. Add, re-rank, move into sprint rooms and back (an epic takes its stories along). Every edition.
  2. Prioritisation scores — RICE (reach, impact, confidence, effort), WSJF (business value, time criticality, risk reduction ÷ job size) and value ÷ effort; rank the backlog by any of them. Team and Enterprise.
  3. Acceptance criteria for each story — rules or Given / When / Then, ticked when met, shown to the team under the story while voting. Every edition.
  4. Requirements — written in CHIPS (every edition) or imported from CSV (Team and Enterprise), functional or non-functional (with a category), MoSCoW priority, status and source; related to user stories; with coverage — the share of their story points delivered (Team and Enterprise).
  5. Dependencies between stories with badges in rooms and the backlog, conflict warnings (dependency planned later or not at all, loops, sprints over capacity, people over their limit, missed target dates), and each sprint's order of work — concurrent within a step, sequential between steps.
  6. Team capacity as the total of the team's availability — availability % per person and per sprint.
  7. Risks (Team and Enterprise) — likelihood, impact, score and severity, ROAM, owner, mitigation, target date, sprint and stories; a 5 × 5 matrix; the critical path and the risks on it.
  8. Auto-scheduling (Enterprise) — an optimal sprint plan from the ranked backlog, dependencies, the team's availability, each person's limit and the story points; preview, then apply (proposed sprints become rooms).
  9. What-if analysis (Enterprise) — capacity, people, scope, velocity and focus changes against the baseline; straight-line and Monte Carlo delivery forecasts; burn-up; projected flow per sprint; throughput, cycle and lead time, WIP and Little's-law cycle time.
  10. Decisions and assumptions — captured in the room by the scrum master or a moderator, seen by everyone, listed per project. Every edition.
  11. The demo comes with a planned backlog, requirements, risks, dependencies, criteria and decisions.
  12. REST API: /api/v1/projects/{id}/backlog, /backlog/rank, /requirements (+ /import), /risks, /decisions, /plan, /plan/auto-schedule, /forecast; /api/v1/stories/{id}/backlog, /rank, /plan, /criteria, /dependencies; /api/v1/rooms/{room}/decisions; /api/v1/requirements/template.
  13. Database schema version 12 (applied automatically; existing stories keep their rooms and get a rank).

1.9.0 — 2026-10-31

How sprints are measured — each project chooses its unit on the team page:

  1. Working days (the default, as before) — now with the project's own working week (e.g. Sunday to Thursday) and holidays; calendar days; or hours (working days × hours per day, 6 by default).
  2. Points per unit, the usual sprint length, everyone's time and per-sprint overrides are counted in the unit, and converted by the hours per day when switching between days and hours. Sprint dates, the capacity panel, the room, the estimate review ("took 12 hours") and Analytics → Missed estimates follow it.

Conference calls — each room can have a call:

  1. Join a Microsoft Teams, Google Meet or Zoom meeting, a phone conference (dial-in number and PIN, with a one-tap tel: link) or any link, from the room's new Call panel — in every edition. (Skype was retired in May 2025 in favour of Teams; Google Talk is now Google Meet.)
  2. Choosing whether to record: per room — never, ask each time, in the scrum master's browser, with the meeting's own recording, or both; administrators can turn recording off and set how long recordings are kept (90 days).
  3. Recording in the browser (Team and Enterprise): the microphone and the call's tab or window sound, uploaded every 5 seconds. It starts only after the scrum master confirms everyone on the call was told; everyone in the room sees "● This call is being recorded".
  4. English transcripts on your own server (faster-whisper; installer --with-transcription): the language is detected first and only English is transcribed. Play from any line; download as text, WebVTT or CSV.
  5. Who said what (Enterprise): connect Microsoft 365 or Google under Account → Meetings (Zoom: one app for the organisation). CHIPS creates the room's Teams, Meet or Zoom meeting and, after the call, fetches the meeting's own transcript with the speakers' names, lines it up with CHIPS's recording and names each line — matched to CHIPS accounts by email or name. Speakers can also be named by hand.
  6. Pages: a room's call recordings (/rooms/{id}/calls) and each recording (/calls/{id}); the demo has a transcribed Teams call. Help: Conference calls.
  7. REST API: GET|PUT|DELETE /api/v1/rooms/{room}/call, POST …/call/meeting, …/call/fetch, …/call/recordings; GET /api/v1/call-recordings/{id}, …/transcript?format=txt|vtt|csv, PUT …/speakers, POST …/stop, DELETE.
  8. manage transcription status|download; Python package extra chips-estimation[transcription].
  9. Database schema version 11 (applied automatically).

1.8.0 — 2026-10-27

Estimate review (Enterprise) — why stories ran over their estimate, on each project (/projects/{id}/review):

  1. Past sprints from Jira or a file — a JQL query (for example sprint in closedSprints()) brings each past sprint in as an archived room with its stories, story points, assignees and delivery data (status history, resolution, linked bugs, sprints). A story goes to the sprint it was first planned in; later sprints count as carry-overs. Only closed sprints unless asked; issues already estimated in CHIPS get their delivery data instead of a copy; preview first; importing again updates. A CSV file works too (one row per story, with optional actual points, outcome, reasons and note; an example file is provided).
  2. Reasons — each project's own list: twelve standard reasons in six categories (requirements, technical, dependencies, people and availability, process, outside the team), each within the team's control or not; add, edit and retire your own (used reasons are kept for the history).
  3. Giving reasons — CHIPS flags each story that was carried over, not done by the end of its sprint, or took more working days or more actual effort than its estimate by more than the project's margin (25%). The scrum master gives it one or more reasons (a main one), can overrule the outcome, and records the actual effort and a note — on the review page, in the story's edit dialog in a room, through the REST API or in the CSV import.
  4. Analytics → Missed estimates — miss rate; a Pareto of reasons (the few behind 80% of the misses); categories and how much is within the team's control; reasons sprint by sprint and recurring reasons; what each reason costs (points over, × estimate); miss rate by story size, person, seniority, technique and how far apart the first votes were; how stories ran over; reasons that come together; stories without a reason; the risk for open sprints from the history; and the main findings in plain words.
  5. Demo — the demo's earlier sprints come reviewed, with reasons, in every edition.
  6. REST API: GET /api/v1/projects/{id}/review, /review/reasons (add, change, delete), PUT /api/v1/stories/{id}/review, POST /api/v1/projects/{id}/review/import/jira and /review/import/file.

Database schema version 10.

1.7.0 — 2026-10-25

A demo area, in every edition — Projects → Demo (/demo) makes a ready-made project, CHIPS demo:

  1. One active room — Demo · Sprint 12 planning, which counts as one of the edition's active rooms.
  2. People — a scrum master (Sam), a moderator (Morgan), a watcher (Wes, the product owner) and five team members (Ann, Bob, Cat, Dan, Eve), on the project's team list with seniority and working days.
  3. Stories — 19 user stories and an epic (Checkout redesign) split into four stories: estimated with votes, notes and second rounds, assigned (Ann over her maximum), some in progress or done, the rest in the backlog, and a revealed round with an outlier left on the table.
  4. Analytics in Community and Team — three earlier sprints (archived, so they use no active rooms) give the analytics their history; the demo project's analytics are shown in every edition.
  5. Enterprise and Team features to try — a recording of the first stories (playable in any edition), the demo's activity log entries with a CSV download, REST API examples with the API's answer for the demo room, Jira-style issue keys, and a preview of single sign-on.
  6. One demo per installation, open to every scrum master and administrator; Reset makes it again, Remove frees its room.

Apache web server, ready for AWS — on Linux the installer now puts the Apache HTTP Server in front of CHIPS (replacing the optional Caddy example):

  1. Apache on ports 80/443 passes pages and live updates (WebSockets) to CHIPS, which listens on 127.0.0.1:8080 only. deploy/apache.sh sets it up and can be run again to change it; settings are remembered and uninstall.sh removes exactly what it added (site, modules, firewall and SELinux settings, certificate).
  2. HTTPS — --domain NAME --letsencrypt EMAIL gets a Let's Encrypt certificate, renewed automatically, with HTTP redirected to HTTPS (TLS 1.2/1.3).
  3. AWS — --alb for an Application Load Balancer with an ACM certificate: Apache accepts only the VPC's addresses and CHIPS trusts the balancer's forwarded headers from them, so it sees visitors' real addresses and HTTPS. On EC2 the address is the instance's public name (IMDSv2). deploy/aws/ adds a CloudFormation template (instance, security groups, load balancer with /healthz health check, Elastic IP, Route 53 record, IAM role with Session Manager, IMDSv2 only, encrypted disk) and a user-data script.
  4. Amazon RDS — --database-url uses an existing PostgreSQL database instead of installing one.
  5. Amazon Linux 2023 support (Python 3.11/3.12 and PostgreSQL 15/16 packages); the .deb depends on Apache. New documentation page: Running on AWS. --no-apache keeps the old single-port setup.
  6. Fixes — in the compiled packages python -m scrumpoker.manage (setup code, administration commands) failed with "No code object available"; apt purge chips now also deletes the database and settings.

Database schema version 9.

1.6.0 — 2026-10-27

Sprint planning with capacity, and analytics.

Sprint planning (every edition)

  1. Working days per person — each project has a team list (Projects → the people button): name, seniority and working days per sprint. A room is a sprint: set its dates (working days are counted) and change anyone's days for that sprint only.
  2. Minimum and maximum story points per person — per person or per sprint; the defaults use 1 story point = 1 working day: maximum = working days × points per day, minimum = half the maximum. The project's points per day can be changed.
  3. Over the maximum turns red — the room's new Sprint capacity panel shows assigned / maximum for each person: red with a warning sign when over, orange under the minimum, green in between; plus unassigned points and assignees not on the team list. The assignee field suggests the team list's names.
  4. Delivery data — stories record when work started and was done, defects, times reopened and sprints carried over (Edit → Delivery), or read them from Jira (Delivery from Jira: status changes, resolution date, linked bugs, the Sprint field).

Analytics (Enterprise edition) — a new Analytics page per project and period, every table as CSV:

  1. Estimator behaviour — first-round votes above, on or below the final estimate; tendency.
  2. Highest and lowest estimator — how often each person was the highest or the lowest.
  3. Velocity contribution — planned and delivered points per sprint, each owner's share, utilisation.
  4. Agreement and divergence — spread of first-round estimates per story, by technique, re-votes.
  5. Anchoring and influence — whether final estimates move toward the first person to comment or the most senior voter more than toward others; influence by person.
  6. Ownership quality — defects, rework and carry-over by owner and by the estimator whose vote won.
  7. Monte Carlo forecast — 50/70/85/95% delivery dates from weekly throughput; chance of finishing by a date.
  8. Points versus cycle time — Spearman, Pearson, R², scatter, box plot by size; whose votes predict best.
  9. More — size drift and point inflation, epic trunk versus the sum of its stories, estimation effort, capacity history.

REST API: team list, room capacity, sprint dates, delivery and GET /api/v1/projects/{id}/analytics. Database schema version 8 (applied automatically).

1.5.0 — 2026-10-26

  1. American or British English — the administrator chooses the spelling of the interface in the setup wizard (Installation options → Language (spelling)) or later under Admin → Settings: English (United States) — color, organization, canceled, license — or English (United Kingdom) — colour, organisation, cancelled, licence. Menus, messages, notifications and Help follow the choice; what people type (story titles, names, notes) is never changed, nor are commands and addresses in Help. Existing installations keep British English. New setting language (en-US / en-GB) in the site settings and the public settings.
  2. The maker — CHIPS is made by EEZEEZEE: EEZEEZEE with the 2nd, 4th and 6th "E" and the 2nd "Z" reversed. On screen (welcome page, Help, the license agreement, documentation and website) every reversed letter is mirrored; plain text (package metadata, the .deb maintainer, LICENSE.txt) uses Ǝ for the reversed E's, as Unicode has no reversed Z. Screen readers read "EEZEEZEE".
  3. Welcome page — under the full name it now says "by EEZEEZEE" (styled as above) instead of "for" and the organisation name.

1.4.0 — 2026-10-26

Running a session: eleven new ways to estimate and moderate.

  1. Custom decks — a sixth technique with your own cards (numbers, words or emoji, 2–30), named, with presets; scrum masters save decks for their other rooms. Number decks get averages and totals.
  2. Pass card — ? now means pass (abstain): it counts as voted but is left out of averages, consensus and outliers; results show how many passed.
  3. Timer — a countdown per vote (rule: seconds per vote, reveal when time is up) or started from the room (30 s – 5 min), with +30 s and stop.
  4. Outliers — after the reveal, votes two or more cards (configurable) from the median are ringed in red with "ask them to explain"; for three-point estimates, PERT values far from the median.
  5. Moderators — the scrum master makes anyone in the room a moderator, who runs the session without an account (rule: moderators vote too).
  6. Kick, lock, hide — remove people from the ⋮ menu (moderators too), lock the room with the padlock, Hide results in one click.
  7. Anonymous voting — revealed cards without names for everyone, including the scrum master; history, downloads and recordings keep them anonymous; turning it off never un-hides a round.
  8. Watchers — Join as watcher (or switch someone): they see everything but do not vote, add notes or react, and never count as missing votes.
  9. Averaging rules — suggested estimate from the mean, the median, the most common card, or the mean without the highest and lowest vote.
  10. Emoji reactions — ten reactions shown next to names and in a feed for ten seconds.
  11. Epics and quick split — estimate an epic as a whole (the trunk), then split it in one step (equal parts, SPIDR, workflow steps, CRUD or your own list) into stories under it; the backlog shows the parts as a tree with their progress and total; an optional "too big — split it?" prompt after a reveal; POST /api/v1/rooms/{room}/stories/{story}/split.

Also: CSV downloads add Type, Epic, Passed, Outliers, Team value rule; the REST API reports roles; database schema version 7.

1.3.0 — 2026-10-25

Builds for macOS and Windows, and Windows as a host.

1.2.0 — 2026-10-24

A welcome page and setup wizard, security hardening, and protected (compiled, signed) builds.

1.1.0 — 2026-10-22

CHIPS becomes a product: editions, license keys, a license agreement and installable packages.

1.0.0 — 2026-10-22

First release under the name CHIPS (previously "Scrum Poker").

Earlier stages (before version numbers)