Your book library

Apply the ideas with your team

The books are yours to explore. There is no appointment required to access them, and educational emails are a separate, optional choice.

Explore the AI Adoption Programme

If a download does not open, contact [email protected].

Before the code: clarifying a team invitation

Fictional educational example. This is not a customer case, product capability claim or measured result.

Starting request

“Let people invite colleagues into the workspace.” This leaves access, roles, acceptance and expiration undecided.

Make eight decisions visible

1. Workflow: add invitations to an existing workspace, not public signup.
2. Modules: membership, authorization, invitation storage, email delivery and UI.
3. Scope: one invitation at a time, a pending list and revocation. Exclude bulk imports and billing changes.
4. Risk: membership exposes workspace data. Only authorized administrators may invite, with server checks.
5. Complexity: handle invitation state, identity matching, expiry and delivery failure. Estimate after inspecting existing code.
6. Database: record workspace, recipient, inviter, allowed role, expiry and state. Create no membership before valid acceptance.
7. API: authorize and validate create, list, revoke and accept operations on the server. Repeated acceptance must not duplicate membership.
8. UI: show pending, accepted, revoked, expired and delivery-failure states accurately. API success is not proof of email delivery.

The team still needs to choose expiry, allowed roles, identity verification and retention for its application. These are examples, not universal defaults for AI to choose silently.

Acceptance checks

• An authorized invite creates one pending invitation with no premature access.
• The server refuses an ordinary member's unauthorized invite, even if the UI is bypassed.
• The intended recipient receives the correct workspace and role; repeated acceptance creates no duplicate membership.
• Another account cannot gain unintended access.
• Revoked or expired invitations cannot grant membership.
• Delivery failure remains visible to an authorized owner.
• The invitation link shows clear status and accessible controls on mobile and desktop.

What changed?

Boundaries, dependencies and observable checks are now explicit before implementation. No code was built, customer test performed, or time or defect reduction measured for this example.

Try this on a real backlog item. Which decision would otherwise be left to the implementer or AI tool?

AI adoption baseline worksheet

Copy these prompts into your team's document for one application and a bounded change. This is an educational aid, not a promise of results or a controlled evaluation.

1. Application, team and named owner
2. Decision the measurement will inform
3. Practice being changed
4. Primary measure and why it matters
5. Exact definition, units and inclusion/exclusion rules
6. Observation source and collection method
7. Baseline dates, sample size and work types
8. Baseline value and distribution where useful
9. Follow-up dates, sample and value
10. Changes in work mix, staffing, tooling or releases
11. Balancing measure: quality, security or review burden
12. Missing data and uncertainty
13. What the evidence supports—and what it cannot establish
14. Next decision and review date

Possible measures include time resolving unclear requirements, items returned for missing acceptance evidence, or review rework. Choose something your team can collect consistently; these are not universal benchmarks.

Keep definitions consistent. Record counts with percentages and explain differences in work. A before-and-after change alone does not prove causation. Faster delivery with more failures is not an uncomplicated success.

Before sharing results publicly, obtain permission, remove sensitive information, retain the source record and show limitations. Illustrative book numbers are not observed team data.