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

What do you want to build or improve?

Tell us your goal and what is getting in the way. Two or three sentences are enough to start.

Tell us about your challenge

Where the reply goes.

A product name or link is useful too.

What do you want to achieve, what is in the way, and is there a 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.

We use your details to handle this enquiry. You will not be added to a newsletter. 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 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.

We will match the topic to the right specialist and work out whether you need advice, a focused delivery engagement or support for your team.

How we start

  • Andrzej or Zosia gathers the context and helps arrange the next step.
  • A consultant with relevant expertise reviews the challenge. If we are not the right partner, we will say so.
  • Before work begins, you receive a proposed scope, cost and timeline.
Contact
Directly with the CloudWarrior team
Next step
Advice or a delivery proposal matched to the challenge

Contact

Remote across the EU · Europe/Warsaw time