🆔💡 Crawling/Harvesting from websites for contact details and business hours (WIP)
To comment on a FP:
Date, name: comment
Status Feature Passport
THOUGHTS
There are a number of service providers who deliver websites for local governments:
LCP: +/- 100 websites of local governments
The set-up of the websites will probably be the same.
TO DO: find the service providers who deliver several websites.
ANALYSIS
This part of the feature passport is owned by the analyst
Current state
[The analyst describes the current state of the feature that needs to be improved, highlighting any known problems and linking them, so that everyone reading the FP can find background information on the problem mentioned.
If the feature is a new feature that doesn't exist yet, the analyst can explain where the need for this feature comes from: business need/what problem are we trying to solve?]
Problems
In this feature passport, we will tackle the problems the current state of the feature has:
[the analyst explains the problems we need to solve in this feature]
The analyst does not provide with solutions. This is the task of the technical and design team.
e.g.
❌ There should be a button in the bottom-left corner so the user can send an email
✅ The user needs the ability to send emails to customer service
After the analyst is done with this, there needs to be a meeting (this can become part of the BRM) where the analyst talks through the expectations with the technical and design team. The team can then decide which problems are feasible to solve for this feature and create tickets accordingly.
This means that if, for example, the technical team thinks that one of the problems will take a lot longer than the analyst anticipated, the PO can still decide to work on that problem as part of another feature passport (* this then needs to be amended in the Problems section and a new feature passport can be created.)
Once the team has agreed on the problems to solve and the tickets have been created, acceptance criteria can be added on the tickets in jira.
This includes any dependencies, e.g.: Story: A user needs to be able to add a position to person Acceptance criteria:
The position needs to be automatically added to the relevant organisation
The position needs to be automatically added to the list of all the positions
🤩 Expectations
🕵️♂️ Use Cases
🤔 Discussion points
SOLUTION
The next two parts of the FP can [sometimes] be worked on simultaneously
Design
This part of the feature passport is owned by the designer
User research
[If there is any user research preceding the wireframe mock-up stage, it needs to be documented here]
Mock-ups
[link to figma mockups + any explanation or extra documentation]
Technical
This part of the feature passport is owned by the technical team
[Information about the technical solutions for expectations that need it - e.g. using mu-search for showing all types of positions in one table.]
After the designer and/or the technical team finish their task, a meeting follows where the solutions are presented. The team exchanges feedback and amends the feature passport where necessary.
Last updated