Sprint 0, key in agile project management.

For a while, technology made the difference and that product or service that offered more functionalities was the most likely to dominate a market. But this is no longer the case: we live in the "user era", and we are no longer asked for a specific functionality, but rather expect "the best experience". We are asked (almost required) to make, while being useful, a product that is, additionally, simple, nice...

This new approach is something that is already internalised in startups and purely digital companies. Good examples of this are Uber and Airbnb. The whole, the experience… that Uber and Airbnb give their users makes them feel VIP and that is what allows them to make a difference with the rest of alternatives... It is not the mere "functionality".

One of the problems we encounter is that the vast majority of organisations are not structured like Airbnb or Uber, but settle around areas of expertise. Each is responsible for a part of the production process and are not focused "to the user".

So, whenever a new initiative arises, those "transversal" departments, the ones that must support the initiative, will ask us in return to inform them of how much the implementation will cost, when it will go to production and how much space in the database we will need, at the same time that they pass us the forms to fill with that information.

The usual way of implementing new business initiatives is the elaboration, with a lot of work and after a detailed analysis, of an RFP. And yet, that RFP does not collect (it can not collect) more than the personal vision of that one or those that elaborated it. It does not take into account the (changing) view of the intended user. Instead, they detail a series of immutable requirements with (preset) planning that fits perfectly into the organisation's budget schedule, but not so much to the changes in the market during its execution.

And yet, we know that competition's successful initiatives are not articulated in this way, but rather they are based on an idea, which is rapidly implemented in an embryonic phase in order to direct its growth towards those areas that offer more ROI (in broad terms). And that is not done with "Annual Plans".

How can I define the indefinite?

It is clear that of the three parameters that are studied in the classic project management (Price, Time and Scope) the most important is the Scope. It is what motivates the realisation of the project but also what, intuitively, will determine the other two parameters.

And although it is clear that it is not possible to determine the scope a priori, but after listening to users in successive deliveries, the stubborn reality is that many organisations still need to be able to plan their resources in the medium and long term (budgetary, human and material).

In addition, although secondary, other factors that are wanted to be known are the necessary infrastructure to execute the project, the maintenance teams that will be affected, the final technological architecture... and the systems with which it is necessary to make integrations.

Is it too much to ask?

How do we undo this Gordian Knot?

The traditional response of suppliers (and customers) is to ignore this fact and throw everyone into the "closed project" pool without looking at whether there is water or not, relying on luck and subsequent negotiation skills between client and supplier to be able to close that project "in the best possible way". That is the problem that concerns when projects are approached this way... both the client and the supplier focus on how to close the project contract and not how to give the maximum value to the users. Am I wrong?

In Paradigma we know that in this type of projects it is not possible to meet expectations and, when they appear to do so, the (forgotten) fourth parameter, QUALITY, is the one that suffers.

On the other hand, agile methods require, in order to begin development, a "Product Backlog" that the client is not usually able to elaborate for himself: the "Product Backlog" does not define a closed scope since it is not a traditional analysis document. However, it is the list of "functionalities that we would like to incorporate" into the project in the future and it is necessary to have it identified before beginning development.

It seems that we still have an insurmountable obstacle: we still can not offer a response to WHAT, HOW and HOW MUCH before starting the project.

The Paradigma's proposal: Sprint 0

The first step, prior to the execution of Sprint 0 (we will see what it is) is to identify with the client at what point in the definition process the idea is found, to identify in which specific areas and with what tools, we can help.

Sprint 0 is a joint effort, in which Paradigma and the client (in the broad sense) explore all aspects of the project to be undertaken, of course, also incrementally and iteratively.

In a short term (between 3 and 5 weeks) you get, as a result, a far more detailed definition of what the client could produce autonomously. The estimated and prioritised Product Backlog, in which various user and stakeholder influences (technical and architectural, budgetary, dependencies of other projects, competition analysis, etc.) have been collected through various techniques.

Sprint 0 allows focusing the project

It is assumed that the scope of the project must be guided by the opinion of the users, but it is not possible to obtain such feedback if there is no product already "released". Sprint 0 allows us to identify the objectives of the project and reduce scope uncertainty (in the form of Product Backlog) and the technological approach: this clarifies expectations within the organisation.

The quick definition is that "Sprint 0 produces everything you need to start working with an agile approach." This includes, above all, a Product Backlog in which the vision that has been identified together is captured.

We begin by identifying the scope definition status and, depending on that state, we define what tools and dynamics are going to be applied in that Sprint 0. The ultimate goal is to get a clear view of:

• What we want to implement, in the form of Product Backlog and prototypes.
• How we want to implement it, in the form of Technical Architecture.
• And how much (time and money) it will cost us to reach each of the possible main phases of project implementation.

Within that Product Backlog, it is usual to find the Epics classified in these three groups: MVP (Minimum Viable Product), MMP (Minimum Marketable Product) and Future Functionalities. Evidently, the Epics of the first two groups will have been decomposed into User Stories and their complexity will have been estimated, allowing them to be prioritised, supported by Prototypes and Graphic Proposal (from a Usability point of view) and a proposed Architecture and even Concept Tests of the most innovative technological elements.

However, since at this point we already have a scope orientation (MVP and MMP) which allows "Business" to obtain a very approximate vision of what will be the result of the project, it is also possible to minimize the concerns of both Management (orientation when it comes to Costs and Deadlines), as well as Technology (when is it estimated that the environments and teams that support the new product will be available, who will form the team, what resources will be needed, what new products or frameworks will be introduced into the ecosystem to maintain, etc).

At this point, both the business leaders and the project team have had time to work together on a common goal, to build a language and collaboration tools that facilitate communication and serve to cement a relationship of trust between who has to finally decide what and with what priority the product has to be implemented (the Product Owner) and who is able to decide how it is implemented (the Scrum team).

It is only at this moment when we are prepared to start the project from a solid foundation.