IT projects rarely go wrong during the first Sprint Planning session. The conditions for failure usually appear earlier: when the business objective remains vague, the backlog is a list of ideas rather than a decision-making tool, and the client and the provider interpret responsibility for scope, architecture, quality, and deadlines differently. A team may start writing code, but that does not mean the organisation is ready for predictable delivery.
This guide presents 12 decisions that should be made before the first sprint. It is not a kick-off agenda or an extensive documentation checklist. It is an operational framework for assessing whether a project has sufficient business, product, organisational, and technical foundations to begin delivery—and whether the selected engagement model allocates responsibility appropriately between the client and the technology partner.
The core principle: the first sprint should not be used to discover who can make decisions, where the data is located, or how software can be deployed. It should be used to deliver the first verifiable increment of value.
Why does an IT project start before the first sprint?
A sprint calendar does not create predictable delivery. Scrum provides a framework for inspecting progress and adapting the plan, but it does not replace business decisions, product ownership, backlog readiness, access to environments, or a quality strategy. If these elements are missing, the team will spend the first weeks resolving organisational debt instead of developing the product.
The official Scrum Guide states that the Product Owner orders the Product Backlog and that the Scrum Team creates a valuable Increment that meets the Definition of Done. This does not mean the entire product must be designed in detail before Sprint 1. The project does, however, need enough readiness for the team to make decisions based on reliable context and to reduce risk through successive iterations.
The most common false start
The project has formally started: the agreement has been signed, the team is available, the kick-off is on the calendar, and the backlog contains initial tasks. A few days later, the team discovers that:
- the sponsor and Product Owner have different interpretations of the first release,
- the team cannot access the required environment or data,
- integration with a core system depends on approval from another department,
- QA is expected to join only shortly before release,
- no one knows who approves architectural decisions,
- every new stakeholder request is added directly to the sprint.
The team is busy, but the project is not yet capable of delivering value regularly.
| Area | Formal start | Operational readiness |
|---|---|---|
| Objective | The project has a name and a high-level premise | The team understands the problem, expected outcome, and constraints |
| Backlog | A list of features exists | The first items are understood, prioritised, and small enough to complete |
| Team | Roles have been staffed | People have a decision mandate and access to the required context |
| Technology | A technology stack has been selected | Dependencies, integrations, environments, and major risks have been identified |
| Quality | Testing has been planned | Acceptance criteria, the Definition of Done, and QA ownership are defined |
| Release | A release date has been proposed | The team knows how to build, deploy, monitor, and roll back a change |
What is project readiness?
Definition: project readiness is a confirmed level of business, product, organisational, and technical preparedness that allows a team to begin delivery without blockers that could reasonably have been removed before the start.
Readiness does not mean complete knowledge. In complex projects, some assumptions can only be validated through discovery, prototyping, technical spikes, or development. The objective is therefore not to eliminate uncertainty, but to make it visible, assign owners, and define how it will be reduced.
A useful project readiness gate answers three questions:
- Does the team understand the outcome it is expected to achieve?
- Does it have the conditions required to start safely?
- Do we know who will make a decision—and how—when uncertainty appears?
This is particularly important in enterprise projects, where dependencies often involve multiple systems, business owners, security teams, vendors, and regulatory requirements.
12 decisions to make before the first sprint
Each decision below is presented through the same practical lens: the decision question, its delivery impact, the minimum artifact, the decision owner, and a risk signal. An artifact does not have to be a long document. Its purpose is to make an agreement visible, testable, and accessible to the team.
1. What business problem should the project solve?
“We are building a new application,” “we are modernising a system,” or “we are automating a process” describes a solution, not the underlying problem. Without a precise diagnosis, a team can efficiently deliver functionality that does not change the business outcome.
Before the start, the organisation should agree on the following:
- which process, cost, risk, or user experience should change,
- who is affected by the problem,
- why the organisation wants to address it now,
- what happens if the project is not delivered,
- which business constraints are non-negotiable.
Minimum artifact: a one-page problem statement covering the affected users, the current process, the expected outcome, and the most important constraints.
Owner: the business sponsor or Product Owner. The provider can help clarify the problem, but cannot define the client’s business value independently.
Risk signal: stakeholders agree on the requested features but provide different answers when asked what outcome the project should achieve.
2. How will we know that the project creates value?
Time and budget are important controls, but they are not a sufficient definition of product success. A project can be delivered on schedule and still fail to improve the process, win user adoption, or justify its operating cost.
Separate three groups of measures:
- business metrics—for example process completion time, service cost, conversion, or the number of operational errors,
- product metrics—adoption, completion of a critical user journey, retention, or user satisfaction,
- technical and operational metrics—availability, performance, deployment frequency, recovery time, and incident volume.
Not every metric needs a final target before Sprint 1. The organisation should, however, decide what will be measured and who will act on the result.
Minimum artifact: a success-measure card that defines the baseline, expected change, data source, and measurement owner.
Risk signal: the only success measure is the number of features delivered by the target date.
3. What scope is actually ready for delivery?
A detailed specification of the entire product is not required before the first sprint. The organisation must, however, distinguish between work that is understood well enough to start and uncertainty that still requires investigation.
The starting scope should separate:
- work that is sufficiently understood to enter development,
- hypotheses that require discovery or a prototype,
- dependencies that still need confirmation,
- items consciously excluded from the first release.
The starting backlog should include not only user-facing functions but also the technical work and risk-reduction tasks required to deliver a working Increment. If Sprint 1 consists entirely of “project setup,” check whether some preparation should happen before the formal start.
A Definition of Ready cannot replace conversation
A set of criteria can help the team assess a backlog item, but it should not become a bureaucratic approval gate. The first items need to be small enough, understandable enough, and verifiable within the sprint.
Minimum artifact: an ordered backlog for the first iterations, with objectives, acceptance criteria, dependencies, and clearly marked uncertainty.
Risk signal: the backlog is a collection of expectations from multiple stakeholders, but no one has the authority to reject or defer an item.
4. Which engagement model fits the project risk?
An engagement model is not merely a billing arrangement. It determines who manages the backlog, the team, operational risk, and the outcome. The choice between Staff Augmentation, Dedicated Team, SoW / Fixed Price, and Managed Services should reflect project maturity and the client’s ability to lead delivery.
The models solve different problems:
- Staff Augmentation works when the client already owns the product, delivery process, and technical direction, but needs specific skills or additional capacity,
- Dedicated Team is appropriate when a stable, cross-functional team is required to develop a defined product area over time,
- SoW / Fixed Price requires clearer scope boundaries, assumptions, acceptance criteria, and a formal process for change,
- Managed Services is organised around a measurable service outcome, SLAs, and operational responsibility within agreed boundaries.
Minimum artifact: an engagement-model charter that defines responsibility boundaries, backlog ownership, commercial rules, governance, and escalation.
Risk signal: the client expects the provider to own the result but chooses a model in which product decisions and delivery management remain exclusively on the client side.
5. Who owns business, product, and technical decisions?
A project needs more than names assigned to roles. It needs people with an actual decision mandate. In enterprise environments, the blocker is often not missing knowledge but waiting for approval from a stakeholder who is not involved in the team’s daily work.
Before delivery starts, define:
- who orders the Product Backlog,
- who approves changes to scope and budget,
- who makes architectural decisions,
- who approves security and compliance requirements,
- who accepts the business outcome,
- who resolves cross-team dependencies.
Important architectural decisions can be documented as short Architecture Decision Records. The record should capture the context, decision, and consequences without creating a large document that immediately becomes outdated.
Minimum artifact: a RACI or a simpler decision map identifying decision owners and the maximum acceptable response time.
Risk signal: the Product Owner is responsible for the backlog but cannot decline a request from a sponsor or another department.
6. Is discovery or a technical audit required?
Discovery is not a compulsory phase of every project. It is a tool for reducing a specific type of uncertainty. It is useful when the organisation does not yet have enough evidence to define a safe scope, architecture, cost, or delivery sequence.
Discovery is needed when uncertainty concerns the product:
- the highest-priority user problem is unclear,
- several substantially different solution paths are possible,
- business assumptions have not been validated,
- the first-release scope is too broad.
A technical audit is needed when uncertainty concerns the system
- architecture documentation is missing or outdated,
- the project involves legacy components with unknown dependencies,
- it is unclear whether current APIs, data, and environments can support the planned change,
- the system lacks tests that would make changes safe,
- the actual migration or integration effort is unknown.
When uncertainty is high, signing a rigid scope does not remove risk. It moves risk into development, where every correction costs more and affects the delivery forecast.
Minimum artifact: a discovery or audit charter that lists the questions to answer, the evidence to produce, and the exit criteria.
Risk signal: the schedule is highly detailed but relies on assumptions that the technical team has not verified.
7. Have architecture and integrations been understood?
The complete architecture does not need to be designed before iterative delivery begins. The team does need to understand which decisions will be difficult or expensive to reverse. These often involve data, security, core-system integrations, availability requirements, and platform constraints.
The architectural minimum before the start includes:
- system boundaries and component responsibilities,
- an integration map and owners of dependent systems,
- critical data flows,
- non-functional requirements,
- availability, performance, and scalability assumptions,
- decisions that require technical validation.
For a legacy project, decide whether the current codebase, database, automated tests, and release pipeline need to be assessed before development. The related architectural options are covered in our guide to legacy system modernisation for AI.
Minimum artifact: an up-to-date context diagram, integration map, list of non-functional requirements, and register of key architectural decisions.
Risk signal: the new team discovers major dependencies only while implementing the first features.
8. Are environments, data, and access ready?
Missing access is one of the most predictable blockers in software delivery. Nevertheless, many organisations start the access process only after the team has joined. In regulated environments, access to repositories, VPNs, data, and environments may require multiple approvals, training steps, and managed-device configuration.
Before Sprint 1, confirm:
- accounts, devices, VPN access, and multi-factor authentication,
- access to repositories, documentation, backlog tools, and communication channels,
- the ability to run the system locally or through an approved development environment,
- the availability of development and test environments,
- rules for production data, masking, and anonymisation,
- access to logs, monitoring, and diagnostic tools,
- the support and escalation process for access issues.
If the project uses external specialists, see our practical guide: How to onboard an external IT specialist into your team.
Minimum artifact: an access matrix with owners, status, and target dates, plus a verified path for running the system.
Risk signal: the sprint plan assumes development work, but the team cannot run the solution or execute a test in an environment.
9. How will quality be assured?
QA should not appear for the first time shortly before release. Quality decisions affect backlog structure, architecture, environments, test data, and developers’ daily workflow. The later these decisions are made, the more defects and structural problems must be removed from an already built solution.
Before the first sprint, define:
- what acceptance criteria every backlog item should contain,
- what Done means for code, tests, documentation, and deployment,
- which tests will be manual and which will be automated,
- which scenarios require integration, performance, or security testing,
- who creates and maintains test data,
- who owns business acceptance,
- how regression will be managed.
OWASP SAMM treats verification as a capability across the software lifecycle rather than an activity performed only at the end. The same principle applies in delivery: quality must be planned together with scope and architecture.
Minimum artifact: a concise test strategy, the Definition of Done, and named ownership for QA and acceptance.
Risk signal: estimates include development effort but exclude test design, data, environments, and regression.
10. How will deployment, monitoring, and security work?
A project does not end when code is merged into the main branch. Before the start, the team should know how a change moves through build, testing, release, deployment, and operations. Otherwise the first version may be implemented quickly but take much longer to launch safely.
The NIST Secure Software Development Framework recommends integrating secure practices throughout the SDLC. Security requirements, dependency management, code protection, and verification should therefore not be added after the product is built.
Before Sprint 1, agree on:
- branching and code-review strategy,
- the CI/CD pipeline and required quality gates,
- configuration and secrets management,
- environments and version promotion between them,
- dependency, source-code, and container-image scanning,
- technical and business monitoring,
- rollback and incident-response procedures,
- legal, regulatory, and audit requirements.
Edge One Solutions supports projects with DevOps, CI/CD automation, maintenance, and monitoring, as well as testing and quality assurance.
Minimum artifact: a high-level release flow covering CI/CD, environments, responsibilities, monitoring, and rollback.
Risk signal: the first release date is set, but no verified route to the target environment exists.
11. How will scope change be managed?
Change is not an exception in an IT project. It is a natural result of learning, user feedback, new evidence, and shifting priorities. It becomes a problem when the organisation has no consistent way to assess its impact.
Before work begins, agree on:
- who can raise a change,
- who assesses the effect on scope, architecture, cost, and forecast,
- who makes the priority decision,
- which changes fit within the current engagement,
- when a formal change request is required,
- how the backlog, forecast, and decision record are updated.
Agile delivery does not require freezing the scope. It requires one visible decision queue and a conscious trade-off whenever one priority replaces another.
Minimum artifact: a simple scope-change workflow with decision thresholds and a rule for updating the forecast.
Risk signal: new requests are added to the sprint without removing other work or assessing the impact on commitments.
12. How will delivery quality be measured?
Velocity describes the amount of work completed according to one team’s estimation system. It is not a universal productivity measure and should not be used to compare teams or evaluate individuals.
From the first month, observe a balanced set of signals:
- achievement of the Sprint Goal,
- predictability of completing planned work,
- time from starting an item to deploying it,
- the number and duration of blockers,
- decision lead time for stakeholders,
- defects discovered after deployment,
- stability of environments and the delivery pipeline,
- progress in product and business metrics.
Metrics should prompt a discussion about the delivery system, not a search for an individual to blame. If the team repeatedly waits for decisions, environments, or data, adding more developers will not improve delivery.
Minimum artifact: a delivery-measure card containing the definition, data source, review frequency, and owner of the response.
Risk signal: reporting focuses on team utilisation rather than flow, quality, and value.
How does the engagement model change project preparation?
The same initiative can require a different level of preparation depending on how responsibility is divided. The table below is directional. The exact operating model must always be defined in the contract and adjusted to the client’s capabilities, project risk, and expected provider responsibility.
| Area | Staff Augmentation | Dedicated Team | SoW / Fixed Price | Managed Services |
|---|---|---|---|---|
| Objectives and priorities | Owned by the client | Owned by the client with provider support | Agreed in the scope and acceptance criteria | The client defines the outcome and service boundaries |
| Backlog | Managed by the client | Usually managed through a shared process | Baseline scope with controlled change | Operational backlog managed by the provider within the SLA |
| Team management | Client | Provider or shared model | Provider | Provider |
| Scope risk | Primarily client-side | Shared | Controlled through assumptions, acceptance, and change requests | Depends on the service boundaries and parameters |
| Primary success measure | Effective access to skills and contribution to the client’s delivery | Stable development of the product or product area | Accepted outcome consistent with the SoW | SLA, KPI, and continuity of the operational outcome |
Practical conclusion: the more responsibility for the outcome the provider is expected to assume, the more precisely both parties need to define service boundaries, acceptance criteria, assumptions, dependencies, and the change process before the start.
Minimum artifacts before Sprint 1
Documentation is not an objective in itself. Its role is to reduce dependence on individual memory and enable faster, more consistent decisions. In most projects, a small set of short, actively maintained artifacts is more useful than a large specification that quickly becomes obsolete.
| Artifact | What question does it answer? | Owner |
|---|---|---|
| Problem and outcome statement | Why are we running the project, and what should change? | Sponsor / Product Owner |
| Success-measure card | How will we evaluate the outcome? | Business and product owners |
| Starting backlog | What matters most in the first iterations? | Product Owner |
| Decision map / RACI | Who has the authority to decide? | Sponsor / Delivery Manager |
| Context diagram and integration map | Where are the main technical dependencies? | Tech Lead / Architect |
| Definition of Done and test strategy | What constitutes a complete and safe Increment? | Team / QA Lead |
| Release flow | How will code reach users, and how can it be rolled back? | DevOps / Tech Lead |
| Risk and assumption register | What can change the scope, timeline, or quality? | Delivery Manager |
GO, CONDITIONAL GO, or NO-GO?
A project readiness review should not end with mechanically ticking boxes. The result must be a decision about how the project should start.
| Decision | When should it be used? | What happens next? |
|---|---|---|
| GO | The objective, ownership, initial work, environments, and quality approach are sufficiently prepared. | Start Sprint 1 and review assumptions regularly. |
| CONDITIONAL GO | Limited risks remain, but each has an owner, target date, and workaround. | Start with constrained scope—for example technical discovery, a spike, pipeline preparation, or an independent component. |
| NO-GO | There is no product owner, no access to critical systems, no viable acceptance path, or no agreement on scope and responsibility. | Remove the blocking conditions before activating the full delivery team and budget. |
Important: NO-GO does not mean abandoning the initiative. It can be the most responsible decision because it prevents a fully staffed team from consuming budget without the conditions required to create value.
How should the first month of delivery be measured?
The first weeks should validate whether the organisational and technical assumptions work in practice. A new team should not be expected to reach maximum speed in its first sprint. The project should, however, become more predictable with each iteration.
| Area | Positive signal | Risk signal |
|---|---|---|
| Sprint Goal | The team delivers one coherent, assessable outcome | The sprint is a collection of unrelated tasks with no shared objective |
| Decisions | Owners respond within the agreed time | The team repeatedly waits for approvals |
| Blockers | They are visible, assigned, and time-bound | The same blockers return in successive sprints |
| Quality | Tests and acceptance criteria are part of each item | “Development done” work waits in a separate testing queue |
| Deployment | The team completes the path from code to an environment | The first deployment attempt is postponed until the end of the project |
| Learning | Assumptions are regularly validated and updated | The plan remains unchanged despite new evidence |
Project readiness checklist for CIOs, CTOs, and project sponsors
Business and product
- the business problem is described independently of the proposed solution,
- a sponsor and product owner have been identified,
- business, product, and operational metrics have been agreed,
- the initial scope has clear boundaries,
- the backlog for the first iterations has been ordered,
- areas of uncertainty have been named.
Responsibility and collaboration
- the engagement model matches the risk and the client’s operational maturity,
- client and provider responsibilities have been defined,
- business, product, and technical decision owners have been identified,
- the escalation path and expected decision time have been agreed,
- the scope-change process has been defined.
Technology and security
- the main components, data sources, and integrations have been identified,
- hard-to-reverse decisions are visible,
- the need—or lack of need—for discovery and a technical audit has been confirmed,
- performance, availability, security, and regulatory requirements are included,
- secrets, dependencies, identities, and access have an agreed management approach.
Delivery and operations
- the team can access repositories, environments, data, and documentation,
- the Definition of Done, test strategy, and QA ownership exist,
- the CI/CD pipeline, deployment, monitoring, and rollback approach have been agreed,
- delivery-quality metrics have been defined,
- the review cadence for risks, measures, and assumptions has been established.
The role of a technology partner before the project starts
A mature technology partner should not react to uncertainty by immediately increasing the team size or producing a deceptively precise schedule. Its role is to help the client determine what is ready for delivery, what requires further analysis, and which engagement model creates the right division of responsibility.
Before delivery begins, the provider should:
- understand the expected business outcome and critical processes,
- verify whether the scope supports credible planning,
- make technical assumptions and dependencies visible,
- propose the right team composition rather than merely available roles,
- include QA, DevOps, and security in planning,
- define responsibility boundaries within the selected model,
- identify the missing conditions that make a safe start impossible.
Edge One Solutions supports organisations with software development and integration, IT project management, testing, DevOps, and team building through Staff Augmentation, Dedicated Team, SoW, and Managed Services.
How we approach the start: before activating the full team, it is worth assessing project readiness, the most important risks, and the expected responsibility split. This makes it possible to select an engagement model based on the actual delivery situation rather than forcing the project into a model selected in advance.
If you are preparing a new project, changing a provider, or expanding a team, we can jointly assess whether the initiative is ready for delivery and which decisions should be resolved before the first sprint.
Summary
A strong project start does not mean that every question already has a final answer. It means that the team understands the objective, the boundaries of responsibility, and the process for working with uncertainty.
Before the first sprint, the organisation should:
- define the problem and expected outcome,
- agree success measures and the initial scope,
- select the appropriate engagement model,
- assign decision ownership,
- determine whether discovery or a technical audit is required,
- confirm architecture, integrations, environments, and access,
- include QA, DevOps, and security in the plan,
- define change management and delivery measurement.
If one of these elements is missing, the project does not always have to stop. The organisation does need to decide consciously whether it can proceed with a full start, a constrained preparation sprint, discovery, or a temporary NO-GO. That decision is what separates responsible project preparation from a purely formal kick-off.
