CloudWarrior CloudWarrior, home

Free resource · template

First the problem, then the sprint plan.

CloudWarrior sprint brief · cloudwarrior.io/sprint-brief/

A template that sets out the problem before a conversation about an AI or delivery sprint: what should change, what data is needed, what could go wrong and how everyone will know the work is done.

Fill in the brief
Ask for a scope review
  • No account, no email
  • Entries not sent to a server
  • Printable and PDF-ready

How to write the brief

A brief is a starting point for judging scope, not a contract or a specification. Short answers in your company’s own language are enough; the technical detail is worked out later, together.

  1. Describe the problem in business terms

    Write what does not work today and who it affects. Leave technology for later; the fix is often simpler than the first idea.

  2. Describe a result that can be checked

    Instead of “implement AI”, write what someone will be able to do after the sprint and how you will see it.

  3. List data and access, do not send them

    The system name, the kind of data and the person who can grant access are enough. Access is arranged only after scope is agreed, through a separate secure channel.

  4. Write down what the sprint excludes

    Exclusions protect the deadline and the budget as much as the task list does. If something is left for later, say so plainly.

A filled example

An invented online shop and one customer service problem. The figures are illustrative and describe no client and no result.

Brief: first-pass handling of customer emails

1. Problem

What does not work today?
The customer service inbox receives several hundred emails a day. Order status questions are mixed with complaints, so urgent cases wait in the same queue as simple ones.
Who does it affect?
The customer service team and customers waiting for a reply
How do you cope today?
Reading emails by hand, moving them into folders, replying from saved templates

2. Expected result

What should work after the sprint?
Every new email gets a category and a draft reply based on the order data. A person on the team approves or edits the draft before it is sent.
How will you notice the change?
Time from a complaint arriving to the first reply, read from the ticketing system before and after the sprint

3. Data and access

What data is needed?
Anonymised emails from the last three months, order statuses, the returns policy
Which systems will need access?
Ticketing system: read access and saving drafts. Online shop: read-only access to order statuses.
Who can grant access?
Head of customer service and the shop administrator
Is the data sensitive?
Yes, personal data

4. Constraints

What are the constraints?
Customer data stays in the EU. No reply goes out without human approval. The team has one hour a day for testing.
Who accepts the result?
Head of customer service

5. Risks

What could go wrong?
The model files a complaint as a status question, or a draft gives a wrong delivery date. Warning sign: the team corrects many drafts during testing.
Where must a person keep the decision?
Sending every reply, decisions to reimburse a customer, legal matters

6. Acceptance criteria

When is the work done?
1. On an agreed set of archived emails, categories match the team’s judgement within an agreed threshold. 2. No draft reaches a customer without approval. 3. Every category and every draft is logged. 4. The team runs the new process from a short guide.

7. Out of scope

What does this sprint exclude?
Sending replies automatically, chat and phone support, changes to the shop itself
What happens after the sprint?
Decide after the demo

What to notice

The result describes behaviour that can be shown in a demo, and the acceptance criteria say how to check it. Access is described by type and owner, with no passwords anywhere.

Your brief

Seven parts, from the problem to what is out of scope. If you do not know something, write “not sure”. That helps judge the scope too.

To print the sheet or save a PDF, use your browser’s print command (Ctrl+P or Cmd+P).

1. Problem

The situation the problem arises in, and what it costs the business or its customers.

A team, a role or a group of customers.

The current process, workaround or tool.

2. Expected result

Behaviour or an outcome someone can check in a demo or a test.

An observation or a measure you can already read today. No profit forecasts.

3. Data and access

The kind of data, its source and format. Do not paste the data itself.

System names and the scope: read or write. No passwords or keys.

A role or a person on your side.

This affects where and how it can be processed.

4. Constraints

A deadline tied to a real event, budget, required tools, security rules, people’s availability.

The person who signs off delivery and scope changes.

5. Risks

A wrong model answer, gaps in the data, dependence on a vendor. Add how you would notice it happening.

Steps that must not be left to automation or an AI model.

6. Acceptance criteria

A list of conditions answered yes or no. Each can be checked in a demo or a test.

7. Out of scope

Things deliberately left for later.

An initial assumption. Further work is agreed separately.

What happens to the brief in a consultation

  • A draft is enough

    The brief does not need to be complete. Empty fields show what needs to be settled in the conversation.

  • Scope is agreed together

    The brief becomes a proposal for sprint scope, dependencies and acceptance criteria. No work starts before that is agreed in writing.

  • Access only after agreement

    Access to systems is granted for the agreed work, with the least privilege it needs and through a separate channel.

  • AI under human control

    Where the brief names a human decision, the solution leaves it with a person. The model prepares, a person approves.

Have a brief, even a partial one?

Describe the problem in the consultation form. In the conversation we judge whether the scope fits one sprint, what needs clarifying and which access will be needed. Do not send passwords or customer data.

Ask for a scope review

Other resources

Request a consultation

Describe the problem, the outcome that matters and any deadline that is real. Two or three sentences are enough to start.

Request a consultation

  1. Prepare an email
  2. Finish sending in your email app

Where the reply goes.

Helps place the request in context.

The problem, the outcome you need and any real deadline. No passwords, keys or customer data.

Initial qualification 08:00–16:00, consultations with Patryk after 18:00, Europe/Warsaw. The date is agreed individually; sending this form does not book a consultation.

Answers are used to reply to this request and nothing else. No mailing list, no sequence. Privacy.

Scripts are off, so this form cannot hand the request on. The same three answers work as plain mail: address, company and what needs to change. Write to pat@cloudwarrior.io.

Or write straight to pat@cloudwarrior.io.

Who answers, and when

Status: Patryk Ciszewski is currently contracted on a project.

  • Andrzej and Zosia run the initial qualification, 08:00–16:00 Europe/Warsaw. They ask about the company, the project, the problem, the outcome you want, the deadline and the budget, then pass the case to an engineer.
  • Technical consultations with Patryk are held after 18:00, Europe/Warsaw.

The time is agreed by email, case by case.

A person reads every request and replies by email with a proposed next step, the questions still open, or a clear no.

What happens next

  • A person at CloudWarrior reads the request and checks whether the problem fits the practice.
  • The reply proposes a call, asks what is still unclear, or explains why the fit is wrong.
  • Andrzej and Zosia run the initial qualification 08:00–16:00, and consultations with Patryk are held after 18:00, Europe/Warsaw. The actual date is agreed individually.
  • Scope, success criteria, timeline and cost are agreed in writing before any work starts.
Reply
By email, from a person
Call windows
Qualification 08:00–16:00 · Patryk after 18:00, Europe/Warsaw
Dates
Agreed individually
Commitment
None until scope is agreed

Contact

Remote across the EU · Europe/Warsaw time