Process for Use Case Creation/Modification (Draft document - this process has not been approved)

Below is a proposed process for how a new Product use case is created and existing use cases are modified in coordination with the Country Engagement’s user journey priorities and the Building Blocks technical leads.

Phase 1 – Use Case Topic Identification & Selection Process

• Country Engagement User Journey Priorities: based on consultation workshops with governments (Egypt. HoA, Rwanda, Ukraine etc), the Country Engagement Team have already identified country specific user journeys to support these government entities with. Documentations pertaining to each prioritized country specific user journey are all kept up to date on the Country Engagement Confluence page, with links to all relevant user journey documentations they have collated.

• The Country Engagement Team holds weekly meetings where updates are provided on the activities and user journeys they are working on, the Business Analyst in the Product Team should always attend these meetings to stay aligned with this work.

• The Country Engagement Team are responsible for ensuring all user journey documentations are up-to-date and accessible.

Phase 2 – Use Case Process within the Product Team

The Product Team should implement the following structure:

1. Review user journey documentations available on the Country Engagement Confluence page and GIZ SharePoint folder to ensure there is sufficient content to build Product use cases.

2. Product Team technical leads – (Wes &Steve) to identify which user journey(s) are more relevant/pertinent for GovStack and the Building Blocks specification priority areas.

3. Present during a weekly Product Committee meeting, the user journeys that will be prioritized to develop into Product use cases. Open floor for feedback on the selected use case topics, and confirmation/validation from Committee members.

4. Select a member within the Product Team (could be the Business Analyst) to be the lead in charge of outlining the Product use case and its general coordination and dissemination process.

5. The topics of the Product use cases should be listed in the Product Committee’s Confluence page – a table will be created and updated with information on the sectorial area, the Product Team member in charge of outlining the use case, the BB lead(s) it pertains to and will be shared with for feedback, its draft/review phase on GitBook and estimated publication date.

6. Coordinate/inform country engagement lead (Yolanda) that the Product Team is working on the Product use case for the specific user journey use case. This ensures the Country Engagement Team is aware and can flag to the Product Team, any new documents or relevant content they have uploaded/plan to upload on Confluence.

7. For every new Product use case, create a new page on the GitBook Product Use Case section using the use case template. Ensure the use case is generic and focuses on mapping/identifying the applicable building blocks and workflows.

8. Once all content for the use case has been outlined, it will be submitted for internal appraisal/review within the Product Team – (i.e., by the Product Team Technical Lead(s) (Steve or GovStack Product Owner (Wes)) – to review and ensure building blocks and workflows are correctly included/classified in the document.

Phase 3 – External Review by Building Block Leads

1. A glossary with information on who the lead is for each Building Block will be displayed/embedded on the Product Team’s Confluence page.

2. The link to this Use Case Creation/Modification process will be shared with the relevant BB leads so they are informed on the use case review process and their role.

3. To coordinate use case feedback directly with the BB lead(s) a ticket on Jira will be assigned to each BB lead every time a use case is ready for their review and feedback. The use case GitBook link will be embedded in the Jira assigned task as well as the deadline for appraisal.

   1. The BB leads are in charge of deciding how they wish to internally proceed with incorporating feedback and input from their respective team members. The Product Team only liaises directly with the BB lead for input on the use case.

4. BB leads will be asked to provide feedback directly in the use case GitBook page by adding comments to the document. Once they have added their comments and general feedback on the use case then they should mark the assigned Jira task as complete.

   1. BB leads will be given a week to incorporate their feedback/input.

   2. The Product Team member in charge of the use case will follow-up with each BB lead on slack three days before the deadline to make sure the BB lead(s) has access to the use case link, can meet the deadline and answer any questions.

5. A week following the completion of review and feedback from the specific BB lead, a (30-45-minute) meeting will be organized (coordinated by the Product Team Business Analyst) between the relevant BB lead, the GovStack Product Owner, and Product Team member in charge of the use case, to discuss the BB lead’s comments and finalize the relevant building block content in the use case.

Phase 4 – Product Committee Final Review and Publication

1. The link to the final use case will be shared with the Product Committee members two days prior to the weekly Product Committee meeting for them to review the use case.

2. The use case will be added as an agenda point during the Product Committee meeting to open the floor for final feedback before the use case is published and made publicly available.

3. Work with the GovStack comms team to write blogs on some of the use cases publicly published to disseminate widely.

Additional idea

• We could assign the BB leads a minimum on 2 use cases to review and add their feedback. Then during our meetings with them, we can go through their feedback on the 2 uses cases just to be more efficient with the 1-1 meetings with the BB leads and get more use cases finalized and ready for publication.