Vision and Scope Document
We use a discovery phase for each of our projects, whether it's a one-month MVP or a multi-year contract. This phase helps us understand the closest month scope of work, detect risks, and set priorities.
Deliverables
At the end of the discovery phase, we provide our customers with the following deliverables:
Vision and Scope Document
Let's take a closer look at the vision and scope document.
When we just started it was a template from the internet and over years we added items from our experience.
Finally, we have such sections:
0. Versioning - an important part where we describe the priority of the scope.
1. Project vision - why this product is needed.
1.1 Product goals - what we expect to achieve with this product.
1.2 Stakeholders - if the customer is not a single person, we need to know with whom we can discuss certain questions.
2. Project scope
2.1 Scope of work - list of the screens or features. It's essential that this describes version 1 in most cases.
2.2 Glossary - any term that will help make communication clear. We were skeptical about it when we started discovery, but after many years, we think it's one of the most important items, especially when onboarding new team members.
2.3 User roles description - if the system has more than one role, we create a matrix where we set the list of screens in the first column and the list of roles in the first row. We use a plus or minus sign to indicate which role has access to which functionality, to avoid any miscommunication.
3. Requirements
3.1 Functional requirements - here, we add a link to our Excel file or board (Jira in our case), which includes stories and acceptance criterias.
3.2 Non-functional requirements - we include details such as: which browser we will test, mobile devices, etc.
3.4 Notifications lists(push, email, sms) - we put it as a separate section as it's much faster to read than the entire document all the time.
3.5 Mockups - a link to schemas (Miro), mockups, and/or design (Figma).
3.6 Risks - we put project management risks that we detect based on requirements.
4. Technical side - here, we add recommended technologies and libraries. It also includes architecture solutions.
Timeframe
We try not to make the discovery phase longer than 2 weeks (about 40 hours of work). This is because our goal is to set up the scope for the next 2 months, and taking longer than that doesn't make sense for both sides. However, there are situations where the discovery phase may take longer than 2 weeks.
Communication
Different situations can arise during the delivery phase of the project, and it's essential to have clear communication and agreement on the features and deliverables. To ensure that there are no misunderstandings or miscommunications, we recommend getting approval on features through a sign-off acceptance criteria document or at least an email confirmation from the customer.
When the customer agrees with the acceptance criteria or sends an email stating their approval, it provides a clear record of what was agreed upon and reduces the risk of misunderstandings or disputes. This also helps to maintain a good working relationship between the client and the development team, as it establishes a sense of trust and transparency.
It's also essential to have a process in place for handling changes or revisions to the project scope or features. While changes are sometimes necessary, it's important to evaluate the impact on the project timeline and budget and communicate these changes clearly to the client.
What I still see, as tasks to improve:
- Prepare features and story templates - we didn't think about it before, as our projects are different. Now, when we have big statistics, I see that features are repeated like: auth, chats, and profile. And to make some ready-described templates will decrease discovery time
- KPI - we are still playing with it, the most obvious is the customer satisfaction rate, and the next one is the satisfaction rate of the team that works based on gathered requirements, and then result. I would say, that we finally can say, that we did a good or bad job, only after features have been implemented in the project, which can be up to 2 months, we are looking for more points that will give us feedback earlier
In conclusion, a well-planned discovery phase is crucial to the success of a project. While improvements have been made in recent years, there are still areas that can be improved upon. Teams should continue to identify and mitigate risks, as well as constantly seek opportunities for improvement in order to ensure a more efficient and confident workflow