Author: Zac Broitman, Business Analyst

What is the Discovery Process?

General Idea and Purpose

Whether your project is for a large scale enterprise system or a startup app, it is important that you and your team include a discovery phase in your software development plan. This is because in all software development projects, miscommunication or misunderstandings can lead to missed deadlines and exceeded budgets, which no one wants. Small cross-functional teams may be able to quickly communicate and adapt to changes, but to better mitigate those risks it is crucial that everyone involved in the project is able to provide their input early and understand both the vision and the restrictions (like cost and time).

The discovery phase provides a time for all stakeholders of the project to come together and create a shared understanding of the project goals. This collaborative vision helps ensure that in each step of the project, the end goal remains the same: provide business value. A powerful outcome of this discovery process in software development is the relationships built between project members; these relationships bridge the gaps between the development team and the client or business development teams.

Who is Involved?

An effective discovery process should include as many stakeholders as possible. Stakeholders include those affected by or those who are a part of the project, ranging from all members of the development team to end users and subject matter experts. You should bring multiple points of view into the process because this will allow for discussion around technological feasibility, provide a clearer focus on overarching business requirements, and garner invaluable user insights.

Ideally, the entire development team should be involved in this process, including programmers and quality assurance testers, and at a minimum, the Project Manager, Business Analyst, Solution Architect and User Experience Designer, as well as representative end users, should be present. In an Agile Scrum environment, it is critical that the Product Owner is present for all activities in this phase. As part of the Discovery Process, representative end users should also be included (at the end of the day, end users are who you are building this for).

• Product Owner (PO)

• Project Manager

• Business Analyst

• Solution Architect

• UX Designer

• Programmers

• QA Testers

• Representative end users

User Experience (UX) Designers can be extremely useful in the discovery process, as many functional constraints can be informed by user interface (UI) requirements. A common practice to bring the Discovery and Design processes together is to conduct a design thinking workshop, where stakeholders come together to comprehensively discuss the motivations, requirements, and vision for the project.

It may seem obvious but the most important participant in the discovery process is you (the client). If you are building software (or having a team build it for you) the team is beholden to you; you are the client, and you are also very likely the product owner. But always remember that at the end of the day, you are beholden to the end user – whoever that is.

“It may seem obvious but the most important participant in the discovery process is you (the client.)’‘

The discovery period is the best opportunity for you to share your ideas with the team and make any changes to your business plan. It is easy to get excited about a new idea and discuss the main features of it. However, it is important that the development team and the client both buy into the Discovery Process to ensure that they do not skip past the more granular details of a project or have one party unnecessarily increase the scope. Committing to the discovery process also makes it more likely to surface requirements that were not considered by the client. These will then be discussed early on which saves further work down the line.

Why is Discovery Useful?

Conducting a discovery period allows your team to analyze and discuss the project goals. Ambiguities will be elaborated to prevent mistakes in development because the earlier a defect in a software development project can be found, the less time it will take to resolve. In software and app development the discovery process is a period for requirements to be clearly defined and misunderstandings quickly resolved. It also helps create a culture of consistent communication early which will greatly improve the feedback cycle during the development process.

Often when discovery is ignored, users are not consulted until too late in development; your digital product may have already missed the mark from their perspective. Involving users early will confirm the goals of the project and the potential value this software will deliver. Users will provide feedback which can tweak the direction of the project if the value is not initially clear to them. To make adjustments at the end you now have to modify completed work, which can result in new bugs or require further (and sometimes larger) changes according to that feedback. By consulting with users early on you can modify the requirements rather than the code and save a significant amount of time and budget.

How does Discovery Work?

Discovery can take form through a variety of processes, but one common factor is creating a precedent for clear and consistent communication between the development team and the client. At FreshWorks, we start with a pre-discovery process, to ease the transition from our sales team to the operations (development) team. We reach out to collect basic project information, which allows us to make the discovery process more effective by moving past initial FAQ’s that come up nearly all the time. This will maximize the amount of time that we spend discussing your specific needs and considerations during discovery, and answer or clarify general questions that aren’t as project specific.

Your needs will dictate the processes used in the Discovery phase. At minimum, an initial kick-off meeting should be held with you and the development team so that the project can be introduced to everyone and specific questions about you (the client) and the project can be brought up in a collaborative environment. Next, a design thinking workshop focusing on user-centred design should also take place. This is where project stakeholders are brought together to discuss the problem, users, needs, and wants for the project. After collecting as much information as possible, a set of User Stories will be created to detail the specific functionality of the system. These user stories should be reviewed in detail by the development team and the client, working through each one to ensure that the requirements for the project are explored and clarified.

Outcomes

The key outcome of the Discovery Process is the shared, documented understanding of project goals, requirements and vision. This typically takes form through documents such as User Stories, Acceptance Criteria, a Software Requirements Specification document (SRS), as well as User Personas. Depending on the project nature other supporting documentation such as Data Flow Diagrams and/or Entity Relationship models may be created as well to better understand the processes and data involved.

User Stories

User Stories allow for each piece of functionality to be documented and organized. User stories are paired with Acceptance Criteria to describe the exact requirements of implementing each feature. Note that, on an agile project, especially a large one, getting into more detailed user stories and acceptance criteria would be the next step after Discovery.

During discovery, our goal is to identify the business goals and create enough user stories to kick off the project. To achieve this, all the stakeholders (including client, users, project team, sponsor, etc.) need to have a common understanding. One technique for achieving a common understanding is a User Story Mapping exercise, a short intensive process designed to facilitate collaboration and bring out clarity on a complex problem with a diverse group. At FreshWorks we facilitate this process as it requires someone experienced to do so. Detailed acceptance criteria for those user stories and full system design generally happen after discovery is complete.

Here’s an example of a User Story with Acceptance Criteria. Keep in mind, this is much more detailed than what’s included in the typical preliminary Discovery Process, but it does give you a good idea of what a typical User Story + Acceptance criteria example might look like:

Software Requirements Specification

A Software Requirements Specification is often used in large scale projects to capture project details such as scope, user groups, requirements, and objectives. Below is an example of a typical SRS backbone.

User Personas

A User Persona provides a representation of potential user groups and can be used to form requirements and design the system. The key of this documentation is to provide a source of truth that can be referenced and updated throughout the rest of the project.

Next Steps After Discovery

Once a project completes its Discovery Process it can move into design and development much more efficiently. A good discovery done early on will allow designers to craft an effective user experience to match the end user’s needs and habits. Development will be done more efficiently because of the clear requirements. This means easier backlog grooming for tasks during development and fewer instances where you have to request that the team make a change part way through development.

It will be tempting to wipe your hands and say “okay discovery is done great.”, but It is important to not abandon the concepts and the mindset you’ve now adopted. In an Agile setting, Discovery should remain continuous through each development sprint, allowing the project to effectively take in new requirements. Even in a traditional waterfall project, keeping up a shared understanding will ensure the project stays on track and the team is working together towards fulfilling your vision.

Questions about what a discovery process would look like specifically for your software development project?

Contact us anytime to find out.