Why Is A Discovery Phase Team And Plan Crucial For Your Project?

This is the second of several articles in a series explaining why the Discovery Phase is needed, how it benefits the Product Owner, and how it should be managed. The first article can be found here. 

The Discovery Phase Team

A strong team is one of the most important points for the successful implementation of a product. The structure of the team is just as critical as the selection of specialists with sufficient qualifications. This article will not address the issues of building a Discovery Phase Team and the needed leadership but will focus on the set of roles necessary and their primary responsibilities.

In an ideal world, one person would be well versed in requirements analysis, user experience design, project architecture, and more. But even in this case, the calendar for the implementation of the Discovery Phase would be greatly extended. The structure of the Discovery Phase team’s roles allows specialists to better perform their assigned tasks, assist team members, and move the process forward much faster than one person could.

The standard set of roles for the Discovery Phase includes:

1. Business Analyst – main tasks:

• collect and document requirements, which allows the entire team (including the Product Owner) to be on the same page;
• detail the product vision via user stories based on the Product Owner’s primary goals;
• analyze competitors’ products and other products of a similar degree that can be used as references;
• help the Product Owner build a business model based on research;
• work with the UX Designer on prototypes;
• work with the Product Owner to create a list of project-orientated risks;
• participate in the estimation process and the formation of deadlines.

2. Architect – main tasks:

• prepare a high-level description for the technical process for the implementation of the Product Owner’s goals;
• work with the Business Analyst on finding the best paths for implementation;
• develop goals, principles, and rules for the team to follow during the implementation of the product according to the project goals;
• design a high-level structure for the project, dividing it into components and layers;
• creation logical and physical topology diagrams of the project;
• create a unified project vocabulary along with  the Business Analyst that will allow all team members to speak and write code using the same terminology;
• carry out technical research into systems that the product will be integrated with (in the case of large-scale Discovery Phases, this task can be assigned to the additional role of Technical Researcher);
• conduct technical studies to find solutions to complex engineering problems with a high degree of risk (in the case of large-scale Discovery Phases, this task can be assigned to the additional role of Technical Researcher);
• work on compiling a list of technical risks;
• take a leading role in project estimation and the formation of deadlines.

3. UX Designer – main tasks:

• create clickable prototypes that will help the whole team understand how the product will look and work;
• create UI Kit;
• analyze the UX habits of the target audience (to create a good user experience, it’s important to understand trends and create optimal scenarios, but also to understand what the target audience is used to and develop solutions that will be familiar and intuitive for this them);
• conduct UX research;
• participate in the estimation process and the formation of deadlines.

4. Project Manager – main tasks:

• organize the Discovery Phase and its stages;
• manage the Discovery Phase and keep all team members on track to meet deadlines;
• draft the substantive clauses in the contract according to the team’s capabilities;
• work on compiling a list of organizational risks;
• participate in the estimation process and the formation of deadlines.

5. Lead QA;

• draw up a test strategy (this stage, in addition to creating a test plan for the future project, helps to more accurately formulate the requirements for product responsiveness, supported client devices, etc.)
• test requirements and prototypes (this stage is very important for saving budget since the price of fixing an error early on is much cheaper than fixing written code);
• participate in the estimation process and the formation of deadlines.

Within the Discovery Phase and the upcoming development phase, the principle of T-shaped responsibility is used. This is a scenario when each specialist understands more than just their own field and role to better help move the project forward.

The Discovery Phase Plan

Let’s take a look at an overview of the main stages of the Discovery Phase. Something that should be understood is that several stages are being executed in parallel, and their sequence should be considered for each user story. It’s also important to note that many of the Discovery Phase Plan’s tasks will be performed iteratively.

Define the Product’s Scope and Sync the Vision with the Product Owner

At this stage, the Business Analyst and Product Owner form a holistic vision for the project. The Business Analyst first asks for basic information about the project, highlights the main stakeholders and their goals. Next, skeleton user roles and their main use cases are composed and visualized in the form of a map.

Well-coordinated work between the Business Analyst and Product Owner along with properly identified stakeholders is important for synchronization and streamlined communication. For synchronization, a double verification approach is used; first, the Business Analyst draws up documentation and visualizes it based on deep interviews with the Product Owner and stakeholders. Then the Product Owner reads and accepts the requirements. Double validation of requirements prevents desynchronization and errors, creating a product that meets all participants’ needs and vision.

In addition to bilateral validation, it’s important to identify as many stakeholders and requirements as possible. It’s crucial to take into account the interests of not only end-user groups but also the internal organizational structure of the Product Owner’s team, possible requirements of government regulations, requirements for migration from the old system or data import, etc.

At the end of this stage, the Lead QA validates the logical consistency of the requirements.

Formalize the Scope and Develop Wireframes

At this stage, the UX Designer and the Architect get involved.

The Business Analyst’s main task is to decompose and formalize the previously identified requirements in a detailed form so that the UX Designer and Architect can begin to perform their tasks.

The UX Designer starts developing stories based on the Business Analyst’s requirements. The interaction between the UX Designer and the Business Analyst is iterative since visualization helps to form a more complete and optimal (from the point of view of user convenience) vision of requirements, which in turn entails changes in requirements and designs. Also, a change in both requirements and prototypes can come from the Product Owner; at this stage, it’s not uncommon that stakeholder goals or even the overall goals of the product can change.

In parallel to the UX Designer’s work, the Architect and Business Analyst begin work on a domain map and a unified project vocabulary. On one hand, this allows you to start working on the project’s architecture and on the other hand, to finalize the requirements.

At the end of this stage, The Lead QA validates the logical consistency of the requirements, the completeness of the unified vocabulary, and the compliance of prototypes with the requirements.

Architecture

Within this stage, research into the technical implementation of the project is carried out.

A high-level architecture, which consists of a set of goals for the development process is also developed. The main goal is to implement the requirements compiled by the Business Analyst. Depending on the product’s goals at this stage of development and its life cycle, additional goals are developed, for example, the pace at which code is written, new features are developed, how requirements can be changed, how to scale the team, etc. To achieve these goals, a set of principles and rules is formed, the main architectural patterns are selected, and a technical project stack is formed.

Also, within this stage, the logical and physical topology of the project, the CI/CD strategy, and approaches to the deployment of both development and production environments are developed.

Estimation

Time and budget parameters are very important for a Product Owner, and the estimation process requires a high level of professionalism from the team and previous experience with similar or related products.

Creating an accurate estimate requires a decomposition of the product vision into small tasks, and the subsequent assessment of each element. Those elements that are difficult to assess at this stage are allocated to research tasks (for this type of task, two assessments are given: an assessment for research and an expected estimate for implementation, which can vary significantly after research). In addition to the assessment, a register of currently identified risks and their estimated cost in hours can be compiled.

The whole team is involved in the estimation process.

At the end of this stage, the Lead QA validates whether everything is taken into account in the assessment and whether it meets the requirements and prototypes.

Computools’s practical experience is represented in its years of successful work on many projects and allows us to say confidently that the selection and structure of the Discovery Phase Team has a significant impact on the Discovery Phase.

If you would like to discuss your idea or estimate your project, please, feel free to contact an expert by email at info@computools.com or use the form below.