What Should Be Considered Before the First Sprint?

Do you want our logo?

Do you want our logo description

If you are familiar with Agile methodologies in general and Scrum in particular (and especially if you practice it), I know you will tell me that Scrum does not recognize the existence of a Sprint Zero. This post is not about explaining what a Sprint is or clarifying what the term “time-box” implies or does not imply, but about giving a place to this period of time that is needed at the start of a project. We can call it whatever we want, but Sprint Zero is a necessary good if we want to avoid surprises halfway through… or even at the end.

My experience

I have been managing projects for almost fifteen years — first under a waterfall methodology, and now I am an agilista (or at least I try), working with Scrum. When humanity took that great leap toward true value delivery, leaving behind endless Project Management Plan documents printed in A3, we also forgot to ensure, through a time-box, this space to understand the project, the client, and the team — to make initial contact, put faces to names, and start getting to know each other.

Defining the rules of the game, understanding needs, feeding the backlog, making initial estimates… all of this is just as important as delivering a Minimum Viable Product (MVP). In fact, it is essential for the MVP to meet the expectations of all stakeholders. Because sometimes — just sometimes — in that first contact, one side realizes the other cannot deliver what was expected, and we avoid discovering this when half the work is already done.

It is true that working in consulting is not the same as working for a final client. Consultants serve clients who have a product to sell, which somehow also becomes our product. But this service has an end date, so generally in consulting we tend to request these time-boxes to align expectations and ensure deliverables with greater reliability. On the client side, where information is more direct and immediate, there is often a tendency to think that these spaces — where the team reflects, plans, aligns, and gathers context — are unnecessary.

This initial phase of the project provides a series of advantages that allow us to start the first Sprint with a higher chance of success, compared to diving straight into it without fully understanding what we are facing:

You will get to know your client

And to do so, you will make time — even when there is none — for kickoff meetings where the team presents what has been understood from the agreed scope (the project charter) and the conclusions drawn from this initial phase, where sometimes people only understand what they want (or are able) to understand.

From these meetings, questions will arise that may (or may not) change the product scope and even increase its value — because, honestly, they had not even been considered before. And what better value delivery than adding value to your own product?

You will get to know the team and start building relationships

I’m not talking about having “a good team” in abstract terms, but about creating the feeling of moving as one, rowing in the same direction. In those early days, you begin to see — and be seen: strengths, habits, styles, and how each person reacts under pressure or uncertainty.

That knowledge is invaluable because it allows you to anticipate and manage risks and dependencies that are not visible at first: misunderstandings, misaligned expectations, misinterpreted silences, or decisions no one dares to make without a clear framework.

You will help the team and the client get to know each other

In those early meetings filled with questions and clarifications (business, technical, and “how do we actually do this?”), the real starting point is built. If mutual trust is established during this period, everything flows better afterward: when the team proposes something unexpected, the client will at least listen; and when business priorities change mid-way, the team will treat it as what it is — an adjustment, not an impossible drama.

Together, we establish the rules of the game

This already accounts for half the success of the deliverable: sprint duration, daily stand-up time, planning/review/retro agendas, estimation approach, and how we write user stories. We also set up the basics: repositories, access, tools (Jira or not?), and initial technical decisions to avoid improvisation. With all this, we outline a lightweight initial roadmap to understand where we are starting and what milestones lie ahead.

The Product Owner can leave this phase with an initial Product Backlog

A first version — but enough to build an MVP that becomes the foundation for everything else. As Scrum dictates, the backlog will evolve throughout the product lifecycle, but defining initial epics, stories, and tasks gives us a solid starting point to begin building (and learning) from Sprint 1.

From all meetings, impressions, ideas, and decisions, an initial risk management can be established

This allows us to create an initial picture of potential scenarios the team may face and try to eliminate or mitigate them before they become real problems.

All of this lays the foundation of the project, from which the path begins — not only toward successful deliverables but toward doing things properly, always, always through alignment.

In real life…

Let me share a real case that reinforced all of this for me. I was assigned to a project with a client we had worked with before — in theory, nothing should have surprised us. A short, urgent project: the client wanted a deliverable by early year, and we received it in mid-November. December in between, with holidays already scheduled… so the margin was tight.

Looking ahead, we realized it was necessary to discover each other to strengthen the product and build as much as possible at the highest possible speed, delivering a quality MVP that could grow incrementally.

We spent two weeks getting to know each other: 10 working days where, based on the project initiation document, we worked closely with the client to resolve requirement doubts, extract all necessary User Stories, estimate them, and therefore estimate the entire project.

Given the impossibility of delivering everything desired by the client’s deadline, the idea was to propose an MVP that would evolve through value deliveries every two weeks, with new features and deployment milestones until completing everything defined in the requirements document.

We started with enthusiasm, determined to do it right. We explained that sprints would be 2-week time-boxes, used every available moment to gather more information, clarify doubts, define how features could be more effective, and build a roadmap with milestones and value deliveries.

The first week went smoothly: committed client, motivated team… what could go wrong? By the second week, the client stopped attending meetings, became vague in responses, and stopped replying. Before we could finalize the roadmap and delivery plan, they canceled the project.

A failure? For me, quite the opposite: it was an early signal that saved us weeks of pressure and wasted effort. Without that initial phase, we would have discovered it much later — with work already done, an exhausted team, and a frustrated client.

What conclusion do we draw?

So, was Scrum wrong for not “inventing” a Sprint Zero? From a strict Scrum perspective, it may not make sense: a Sprint is a Sprint. But real life — especially in consulting — rarely starts under ideal conditions, and that’s where this discovery time-box becomes an ally.

In today’s context, with the growing need for adaptability, it makes sense to go through this discovery phase with the client — something that has existed since the origins of project management.

What would have happened in that project where the client withdrew in week two? Would we have realized so quickly that we were not aligned? Probably not. We would have gone through six weeks of intense pressure, trying to deliver something unachievable, with a stressed team, a frustrated client, and quality and methodology both questioned.

Traditional project management already accounted for something similar: before execution, you needed to initiate and plan — understand the context, align expectations, and define a roadmap.

Call it what you want, but the need to understand the client, the problem, and the project conditions is not new — what has changed is how we do it. Today, we don’t aim for exhaustive waterfall-style planning, but for a lightweight and adaptive start: empathizing with goals, clarifying needs, making assumptions visible, identifying risks, and leaving with a first working vision.

In short: think just enough at the beginning so you don’t pay later for not thinking at all.

At Paradigma, we apply this mindset through Polaris, our framework, where we maintain Agile principles while adapting to each client’s lifecycle:

We keep the Agile essence, applying the 80/20 rule: 80% is team attitude, 20% is practices, tools, and experience.
The Scrum Master evolves into an Agile Delivery Leader, ensuring coordination, value focus, and clarity.
We follow a shared True North, guiding decisions and maintaining direction.
We work in a 100% adaptive framework with clear phases: pre-project, kickoff (Sprint Zero), iterations, and closure.
We proactively manage risks from day one.
We aim for productivity, doing what is necessary first, then what is possible, and eventually what seemed impossible.
We rely on metrics to make decisions, adapting them to each context.
Quality is non-negotiable, ensuring superior products.
We understand that software is about solving business problems, so our approach is always aligned with the client.
Team experience matters, and relationships with clients are key to success.

And I’ll close with something simple: life gives us the ability to choose — also when managing projects and trusting others with our products. Nothing guarantees 100% success, but if we can choose, I’m clear: better to get to know each other before jumping to conclusions, better to empathize before blaming.

Better to discover things early than end up with a list of “I told you so” that leads nowhere… and certainly not to product success.