🆔GN: Information from LBLOD (NL)
To comment on a FP:
Date, name: comment
Status Feature Passport
STATUS | OWNER | DATE |
---|---|---|
In proposal | ||
In refinement - Design Research | ||
In refinement - Technical Research/Feedback | ||
In development | ||
In QA/ Testing | ||
In Final state |
Voorbereiding
1. Informatie uit besluiten
Onderzoeken welke informatie we uit besluiten kunnen halen die we kunnen hergebruiken in het OrganisatiePortaal.
Van welke bestuurstypes (naast gemeenten en OCMW) kunnen we besluiten onderzoeken?
Gemeente
college van Burgemeester en Schepenen
Gemeenteraad
Burgemeester
OCMW
bijzonder comité voor de Sociale Dienst
voorzichter van het bijzonder comité voor de Sociale Dienst
Raad voor Maatschappelijk welzijn
Vast bureau
Provincie
Andere?
Voorbeelden bestuurseenheden:
wijziging contactgegevens maatschappelijke zetel
Adres
Telefoonnummer
E-mail
Website
nieuwe vestiging (met eigen contactgegevens)
toetreden tot een IGS (of uittreden)
beslissing tot oprichting/stoppen van een AGB
start- en einddatum
Voorbeelden personen: (= via mandaten- en leidinggevenden beheer van Loket)
verkiezingen 2024
2. Uitbreiding bestaande sjablonen?
Tekst toevoegen > moet dan ook doorgegeven worden aan de verschillende vendors.
3. Nieuwe sjablonen?
Overleg met LSV en GN op 18/10/2023
Welke annotaties zijn wenselijk
statutenwijziging
melding van DV
Besluiten in OP
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