Sprint 0: what we do prior to coding

When we talk about the development process in outsourcing with my colleagues we usually “start” project with development phase: “So, we got that project and started with the team our sprint 1”. It is the most often phrase you can hear about the kick-off of the project. In the books about scrum you can find a lot about sprints, but so few about sprint 0 and preparation to the development. They start with “Ok, we have a list of features and we need to estimate them and get a backlog”. But where from we get this list of features? We start with design and then hang this design to the developers? Of course, not. We need a good Sprint 0 with a team to be able to start development. And then I discovered that we even need Sprint -1, where we go through the analysis of the project idea.

I just want to share my practical experience, which suits for the outsourcing software development company, that wants to deliver better product-oriented service. I am surprised how far from that we can be in some of our big outsourcing leaders.

Why we need Sprint 0

Let me describe how the process looked like 5 years ago. Company’s sales managers discussed the project with the potential client, prepared him our proposal on the budget and timing with the help of development team. Client was really happy with the proposal and signed the contract. Now it was the time for PM to lay his hands on the project. PM was introduced to the client and PM promised the client to start development asap. What goes next: PM gets all the project documents and often they are: project brief description on 1-2 pages (email with project description in 5 sentences as the worst scenario), estimation of the budget (seems like “rough”, but client is already stick to it), sometimes – prototypes, sometimes – requirements description on several pages. With all that information he goes through the several calls with the customer and creates the “requirements description” document, which he approves with the client (up to 50 iterations). Team gets that document, list of features and PM full of details in his head to the start of the development/estimation.

Result: PM knows a lot about the project (but far away from “all”), team knows nothing about the project (PM has to perform “knowledge transfer”), 2-3-4 weeks are spent, 1 person(PM) was involved into the process, so he have only 2 possible options: PM just listened carefully to the customer and wrote everything down or PM created the functionality list on the basis of his vision of the product. Team spends some time on getting into the project, knowledge transfer from PM, etc. Analysis of the project is not perfectly performed by PM – let’s be honest.
So, as the result when the time comes to the development nothing is ready.

We changed our development processes, implemented scrum, but we didn’t changed this “initial phase”. And soon we got the understanding, that something is wrong – we had to start Sprint 1, but where is backlog? 🙂

Issues to be solved

So, we changed our Sprint 0 and added “Initial” phase to the development process.

Which problems we were going to solve(yes, that was very ambitious):

• Initial estimation was far away from the real budget spent on the project. We had only several house to give some “numbers” to the sales manager, but later found these numbers in the contract.
• Project is not ready for the development, when it comes to the start of the development – team is new to the project, knows almost nothing, but has to estimate features. They don’t “feel” the product yet.
• Often we just develop what our client says – we ask them to provide us all the requirements and details. Sometimes clients are frustrated when they have to answer questions like “Would there be a possibility to send a picture or only text in the message?”.
• Clients have the idea, but it is rough – they don’t know in details what should be in there. It is our common job to discover, what functionality should be in the application.
• We often started with prototypes. The idea was that we visualize the idea and then it is very easy to describe/decide how it works. The problem is we often found out that we “forgot” something and had to find the place for the 8th button in the row on the bar…
• Client will get the features they really need, not they think they need when they come 
to us. That will save our client’s money and set up more trust to our company.
• Present the features value through the analysis and beta-testing results.
• Guide teams through the new processes in analysis phase. New process will be 
presented them step by step using the real examples and will be adopted in a natural way.

Types of projects this process is suitable for

Of course there is no one solution which fist every project. But this seems almost a universal one. We have some large enterprise projects when client came to us with the very detailed description of the application they desire, as several BAs already worked on that. But even with these projects we need “knowledge transfer” from these massive documents to the heads of our development team and transform documents into the backlog.
But the best results it showed with:

1. Startups. Such customers need guidance in defining the importance of the features and their value to the user, mobile UI, releases planning. Sprint 0 is a critical part of the product development for them.
2. Mobile versions of existing web services. These customers need the initial analysis of the service to present it on the mobile version in the best way.
3. Applications for business – they need a complex solution to support their needs and maximum you can expect from them – they can define are their needs( but it is not always true).

Closer look: Sprint -1

When the client is ready to start working with us we will need to analyse the existing project materials and decide, whether they need the project vision analysis – Sprint -1. If not, client can start straight from the Sprint 0 phase, which if the initial stage of every t&m agile project.

When the Project vision analysis (Sprint -1) should be performed: 
Client is coming to us with no clear vision of the project, just the idea. He does not know, if the idea is worth building.  They have only some brief description of the idea, current web service or the description of business needs. They are not sure about anything, they have no idea how big it is, what competitors they have, etc.

How it goes:

1. Sales manager gets the information about the project from the client. On this stage we propose the client to perform the initial analysis phase (Sprint -1) to be able to think his idea over/test it/estimate the rough budget. It is very difficult to say, how much time we will need on the analysis, as we know nothing about the project yet. So, it is natural to treat the projects as Small, Middle, Large and “Oh my god, it is huge!”. For each we had the fixed amount of hours (let’s say 80, 120,160, 240) to spent on the analysis. It is fixed price, it is not expensive for the client. We can say if the project belongs to one of the groups during the first meeting, no long estimations.
2. Client is ok with performing the analysis phase) So, we have 1-4 weeks (for mobile projects that is ok, for big projects we can spent up to 2 months) to do the following:
   • Perform the need finding session:
     • Define the potential users of the system– personas. That should be done with the client. Questions to answers: Who are the system users? What is their portrait (age, habits, needs, tasks, how they perform the activity we are going to support with the application.
     • Storyboardings: illustrating how users will use our application – in what situations, what information get from the application
     • Define features users will need: Brainstorm the list of the features with client, vote for the most important for our users. Use other features discovery and evaluation techniques.
     • Define priorities from the user’s point of view.
     • Rough prototyping session: Create prototypes on the paper/white board.
     • Rough estimation – is project small/middle/big/huge in man-months. So the client can understand, how big it is.
   • We can also create more detailed prototype for the pitches.
   • Some rough design concept
   • Technologies investigation/consultations, if needed.

Output

• Users personas
• Storyboards
• User testing strategy (if needed)
• Features list with priorities
• Prototypes (in Axure, interactive)
• Rought estimation on the features list (if possible)

Persona in progress

 Closer look: Sprint 0

When we are done with the need finding and rough feature list, we have the idea of what we are going to build if it worth building – it is the time to involve the whole team, not only Product manager, PM, Client and design/tech consultants.

What we do during the Sprint 0:

• Storymapping – backlog
• Prototyping
• All documentation needed for the start of development
• Prioritize backlog
• Backlog estimation (not all, we have rather detailed one for 1-2 months and epics then)
• MVP, Releases rough planning
• Design concept
• Before-start investigations on any technologies, which should be used

What we get as the output:

• Estimated backlog: detailed for about 2 months, epic stories for the >2 months period
• Budget for development: detailed for first release (about 2 months), rough for all backlog
• Budget for design: amount of hours we recommend to reserve for design works
• Prototype: wireframes+interactions+story mapping.
• Prototype format should be defined and negotiated with the client: paper, clickable in Axure, etc.
• All the documentation that is required for the start of the development process.  The list of documentation depends a lot on the project, is defined  and negotiated with client during this stage.
• Timelines: rough for the nearest releases
• Consultations – customer can consult experts during this period

Storymapping in progress

Client can quit here. If the client is ok with the development start , team is transferred to the Development PM. Analyst can support the team in the future and take part in the activities mentioned below for the additional hours.

Benefits to the client and teams

• Everyone in the teams became less nervous)
• Analysis on the 1st step of the development process is inevitable. The Sprint 0 provides the compact, planned flow for the start of the project.
• Client and team have a clear vision of the project scope when they start the development. We are not just rush and start coding.
• Prioritized backlog allows to have the huge flexibility in the frames of the existing budget. The most important tasks are done first. For the client it means the much lover risk of getting nothing if his funds are suddenly over – the core functionality is created first and he gets the functional version early.
• Everyone is confident in the next steps. Client side Project manager does not “hope for the best” – he sees the real release planning on such an early stage (of course, everything can change, but it won’t be out of a sudden).
• Client do not lose money on knowledge transfer, when the development is started, as team participated in Sprint 0 and is aware about the project details.
• Client received more engaged team, as developers participated in the backlog creation and it contains some of their own ideas.
• Client has the powerful brainstorming tool – not only the PM and Business analyst, but the whole development team – a lot of new great ideas are usually found during such brainstorms.