The Discovery Phase: Why You Need It, and Why Ours Is Different

Did you know that Syndey’s iconic Opera House is one of the largest project time and cost overruns in history? The project took 14 years instead of the planned five and exceeded the budgeted amount by 15 times — all because its creator had to get down to implementation without time to figure out how exactly they’d bring the sketch to life. 

So, planning is vital. This rule applies to any niche, and software development is no exception. 

In IT projects, the planning stage is known as the discovery phase. And in this article, you’ll learn what this phase implies, what it looks like in waterfall and agile, and how Alpacked approaches it.

A discovery phase, or product (project) discovery, is the very first stage of the software development process. 

Carried out by a business analyst, software engineer, UX/UI designer, and project manager, it helps you gain an understanding of what exactly (or approximately) you are going to do throughout the project. It typically involves the following: 

• Analyzing the client’s needs against the business context, defining model, risks, and limitations
• Identifying and segmenting users, as well as identifying their needs in the context of the client’s idea
• Brainstorming a solution to meet the users’ pain points, including details on how a product will look like, how it will work, which capabilities it will have, how and in what cases users will use it
• Defining how the development team will bring the idea to life, which involves choosing the tech stack, outlining a quality assurance plan, as well as deciding how the project will be structured in terms of responsibilities and roles and how communication will be carried about
• Defining budget and deadlines
• Identifying risks and their mitigation
• Understanding whether you have a needed talent on board 

This is the basic overview of the project discovery phase. And here’s one important caveat: while product discovery is an essential element of any software development incentive, there’s no universal way to do it right. How you and your development team approach it will mostly rely on your software development model. 

So let’s consider the most popular methodologies, waterfall and agile.

The key difference between the discovery stage in waterfall and agile is the level of detail and flexibility of the results. 

That is, at the end of the discovery stage in a waterfall setup, you have detailed project specifications and a plan that can’t be changed. Meanwhile, the agile project discovery results in a more high-level plan that can be modified. This primary distinction underpins other differences, such as duration, deliverables, and cost.

A project discovery in waterfall

In a traditional waterfall model, a discovery phase is carried out only once in the project lifecycle, takes somewhere between four and eight weeks, and can amount to 10-15% of the total project cost. 

All the vital information collected and suggestions produced in this stage are distilled into the following deliverables:

• UX/UI deliverables. A clickable UX/UI prototype — an interactive visual representation of a future product — is a must-have discovery deliverable in a waterfall model. It typically comes along with 
  undefinedundefinedundefined
• Software requirement specification (SRS). This document contains the product description, requirements, risks and limitations, and technology stack. It also provides recommendations on the implementation for the team members.
• Architecture design. It’s the visual scheme of the software product’s components, as well as their organization and relationships.
• Project schedule. This is a detailed description of the project implementation with all the tasks, milestones, deliverables, and activity duration estimates. 
• Budget estimates. This is a detailed estimation of the entire project's cost. 

Notably, even in a waterfall setup, a list of deliverables can vary depending on a project and a team’s approach to software development. For example, your deliverables can also include a product scope and vision statement, which covers a product concept, as well as business requirements, risks, opportunities, success metrics, priorities, scope breakdown, and stakeholder profiles. The key consideration is that these deliverables are immutable, and you must stick to them. 

The waterfall approach to product discovery works well in small projects with fixed requirements. In all the other cases, it’s quite risky, and that’s where an agile approach steps in. 

A project discovery in agile 

In an agile software development model (particularly in Scrum, its key framework), a discovery phase is typically called Sprint 0 or the Inception Phase. This phase usually takes about two weeks, and its objective is to gain a high-level understanding of a project and to prepare for Sprint 1.

What is Sprint 0?

Basically, Sprint 0 is very similar to the discovery phase in the waterfall. But the entire "project research" with subsequent planning is done with less granularity. The main goal of Sprint 0 is to set the right direction for the development process. 

For this purpose, a development team can formulate a product vision, define functional and non-functional requirements, as well as risk limitations, make team composition and organization recommendations, create a high-level architecture design, make suggestions on UX and UI, set up a development environment, and make preliminary budget estimates. 

But the key deliverable of the discovery phase in agile is the product backlog, which is essentially the team's to-do list, where tasks are arranged based on the level of priority. This backlog, like the rest of the deliverables, undergoes modifications throughout the development processes. Yes, project discovery in agile is continuous. 

What is continuous discovery? 

In Scrum, project discovery is an ongoing process and typically comes in the form of the discovery track. The discovery track runs in parallel with the development process, a couple of iterations ahead of the latter. 

During the discovery track, a cross-functional team is continuously exploring the market, adding new use cases and features to the product, and brainstorming improvements. It may remove previous suggestions that don’t work and test and improve prototypes based on user feedback, thus honing and detailing the initial deliverables with every new iteration. In addition to continuous brainstorming and experimentation, issues or findings during implementation can also change your project development plan. 

This way, the continuous discovery allows you to get down to implementation more quickly, minimizing risk in a fast-changing environment.

Before we get deeper into the nuances of our project discovery at Alpacked, let’s make a brief detour into how and why we’ve settled for this approach.  

In the good old days, when our company was small and not very experienced, we used to create the project roadmap during the first weeks of work. To collect the necessary information for the roadmap, we conducted knowledge transfer sessions — meetings where a client’s team explained the project’s details to our developers, so our team would have a better understanding of what was going on and how everything fitted together. 

Sounds reasonable, right? Well, in reality, those meetings weren’t useful at all. And it’s not because developers didn’t do their job - both sides were active at such sessions. But the trick was that everything sounded reasonable to newcomers only during the meetings. Once the team started working on a project and diving deep, there was always something that didn’t fit into this puzzle.

So, to avoid resolving this puzzle when the project was already in full swing, we decided to go for a different way. Now, before conducting knowledge transfer, we do the following:

1. Get all the technical requirements a client wants to meet.
2. Understand the long-term business needs of the company.
3. Get access to everything the client has in their development — in the cloud, their repositories, and beyond — and assess a picture of how things stand according to our standards.
4. Get the report from our discovery team.
5. Match what the discovery team found with what the client requested initially.
6. Organize the call with the client and ask questions. Sometimes they may sound silly, but more often than not, they turn out to be the most useful ones and shed light on the customer problems.
7. Work tightly with the client to create a roadmap for the project. This allows the client to rely on our expertise in terms of understanding what should be resolved. As a result, we can prioritize the milestones based on the business needs.

By partnering with your team and maintaining constant communication, we'll collaboratively elevate your technical DevOps operations into a highly-efficient and effective system. 

The tailored improvement set will include a range of enhancements, from automating your AWS infrastructure to streamlining your CI/CD pipeline. With our expert guidance and your company's invaluable insights, we can create a DevOps framework that is lean, agile, and perfectly tailored to your needs. Say goodbye to inefficient processes and hello to a smoother, more productive workflow with our innovative DevOps solutions.