Get in touch →

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

Learn more about a Discovery Phase team’s roles, their main responsibilities, and a quick overview of the Discovery Phase in stages.

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:

 

2. Architect – main tasks:

 

3. UX Designer – main tasks:

 

4. Project Manager – main tasks:

 

5. Lead QA;

 

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.

Discovery phase table

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.

Looking for a team of experienced engineers who knows exactly how to implement your idea?

Contact us →

 

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.

Computools is a full-service software company that designs solutions to help companies meet the needs of tomorrow. Our clients represent a wide range of industries, including retail, finance, healthcare, consumer service and more.

Contact us →

Contact Us

Let's talk about your project.
Use the form to drop a line or
write us an e-mail: info@computools.com

Thank you for your message!

Your request will be carefully researched by our experts. We will get in touch with you within one business day.

Related Articles

Explore all
Articles

COMPUTOOLS BUSINESS WEBINAR

TRENDS TO FORGE
AHEAD IN 2022

3205045
dayshoursminutesseconds

When

October 7, 2021 | 6PM (CEST+2)

Where

Online (Zoom)

Participation

Free

USE AN OUTSTANDING OPPORTUNITY TO ASK OUR EXPERTS QUESTIONS ABOUT YOUR OWN PROJECT

REGISTER HERE →