-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Sprint Planning
- Goal - keep
- Capacity planning - how much time each team member has
- User role?
Definition of Done
Sprint 1 Goal
Sprint 2 Goal
Business
Mobile app for individuals and aid volunteers
Main objective is to guide users/individuals to the right organisations Save data for the users that interacted with the system - google analytics Language: English initially and translated to other languages Organisations should be able to register themselves on the Services
Use Case
Rules engine
- Father with 2 issues
- What area are you seeking help? Education
- Are you looking for help for yourself or someone else Someone else
- What age is the person? 8-12
- Are you from the nationality
1.1. How are we going to work on branches? Convention? 1.2. How/Who is going to merge pull requests? (Suggestion: Any other developer should review the code of the pull request and approve it. The person that opened the pull request closes it and moves the ticket that originated it to "Done" for example) If the task is small and doesn't have dependencies we merge ourselves. 1.3. Structure of our task board: Backlog - tasks not part of the current sprint and haven’t been tackled yet To do - tasks part of the current sprint that have not been tackled yet In Progress - tasks someone is working on Review/Testing - tasks waiting for code review (after a pull request is done) Done - tasks completed during this sprint (that should be archive at the end of the sprint)
- Should we schedule meetings to features/tasks that we want to decide as a team instead of doing it on the already fixed ones? Ex: - "Feature kick-off" - features that are presented by product owner and discussed by the team
- "Task grooming" - create tickets for tasks presented during “Feature kick-off” plus other things the developers think should be tackled
- "Demo" - developers show everyone what has been done (maybe before product owner meetings)
-
Participation form mentions sprint deliverables that are to be deliver on Sundays and our sprint retrospectives are on Monday mornings 3.1. Should we change our sprint retrospective meeting to meet the sprint deliverables? 3.2. Who is going to be in charge of filling the Participation form with the sprint deliverables every week?
-
Sprint planning ###Suggested approach:
- Create tasks that we think should be on the backlog (can be added at any moment of the sprint)
- Select which tasks on the “Backlog” are ready to be worked on. A task is ready if people have a common understanding of what it means for that task to be accomplished. Take dependencies into account.
- Assign tasks to people. Discuss if it’s too much or too little and adjust. Each task should be assigned to only 1 person unless the people will be working simultaneously together on it.
- Move the assigned tasks from “Backlog” to “To Do”.
- “Archive all” the “Done” tasks from the last sprints.
- Sprint retrospective ###Suggested template:
- What went well (personal tasks, team) - 1 row per person, people paste on their row and read
- What could have gone better (personal tasks, team) - same as previous
- Look into “What could have gone better” and create tickets or add points for discussion (next section) - no content, just to be done together
- Topics for discussion - single list, everyone can add to it
- (optional) Why did we not achieve our target for the sprint? - 1 row per domain of work
List of possible backlog tasks:
- Bolor - Devops - create github action (pipeline on gitlab) that builds the frontend to run every time you open a pull request or push new commits
- Bolor - Devops - create github action (pipeline on gitlab) that check if the code formatter (Prettier) has been run every time you open a pull request or push new commits
- Natayra - Devops - confirm if main/master branch is protected and if is not to do it
- Backend - create endpoint “create organization”
- Backend - create endpoint “edit organization”
- Backend - create endpoint “delete organization”
- Backend - create endpoint “list all organization”
- Bolor - Backend - create endpoint “registration”
- Bolor - Backend - create endpoint “login”
- Katlego and Kiran - Design - user journey
- Justyna - Frontend - define conventions and folder structure of the app
- Justyna - Frontend - decide on how we are going to write the style and share it
- Natayra - Frontend - add a new page/screen with a button to navigate to another page and back
- Claudia and Bolor - Database - connect to PostgreSQL from Flask
PS: Conventions should be written in a doc in the project (.md file)
1.1. How are we going to work on branches? Conventions?
A: We are going to have a Development branch where all of our personal branches will be merged and both Dev and Main/Master branches will be protected. Everyone should work on their own branches with their own names and write the description of the ticket done on the commit message.
1.2. How/Who is going to merge pull requests?
**A: **Any other developer should review the code of the pull request and approve it. The person that opened the pull request closes it and moves the ticket that originated it to "Done". If the task is too simple/small and doesn't have dependencies we merge ourselves without need to code review and approval.
1.3. Structure of our task board:
**### Backlog **- tasks not part of the current sprint and haven’t been tackled yet
To do - tasks part of the current sprint that have not been tackled yet
In Progress - tasks someone is working on
Review/Testing - tasks waiting for code review (after a pull request is done)
Done - tasks completed during this sprint (that should be archive at the end of the sprint)
- Should we schedule meetings to features/tasks that we want to decide as a team instead of doing it on the already fixed ones? Ex: - "Feature kick-off" - features that are presented by product owner and discussed by the team
- "Task grooming" - create tickets for tasks presented during “Feature kick-off” plus other things the developers think should be tackled
- "Demo" - developers show everyone what has been done (maybe before product owner meetings)
**A: **Yes, we have available 2 slots for meetings that we think should happen with the whole team (Tuesday and Thursday at 12:30 if nobody objects to it) that should happen only if necessary and the person that calls for the meeting should inform the others and prepare it to be the shortest and most productive possible.
- Participation form mentions sprint deliverables that are to be deliver on Sundays and our sprint retrospectives are on Monday mornings 3.1. Should we change our sprint retrospective meeting to meet the sprint deliverables?
A: Yes, we will do sprint retrospective and planning on Friday mornings from 8:30 to 9:30 instead of Monday mornings. Monday mornings will be a 30min meeting from 8:30 to 9:00 to do a Daily Standup. We keep another Daily Standup on Wednesday mornings from 8:30 to 9:00.
3.2. Who is going to be in charge of filling the Participation form with the sprint deliverables every week?
A: Kiran will be in charge of filling the sprint deliverables.
- Sprint planning ###Suggested approach:
- Create tasks that we think should be on the backlog (can be added at any moment of the sprint)
- Select which tasks on the “Backlog” are ready to be worked on. A task is ready if people have a common understanding of what it means for that task to be accomplished. Take dependencies into account.
- Assign tasks to people. Discuss if it’s too much or too little and adjust. Each task should be assigned to only 1 person unless the people will be working simultaneously together on it.
- Move the assigned tasks from “Backlog” to “To Do”.
- “Archive all” the “Done” tasks from the last sprints.
- Sprint retrospective ###Suggested template:
- What went well (personal tasks, team) - 1 row per person, people paste on their row and read
- What could have gone better (personal tasks, team) - same as previous
- Look into “What could have gone better” and create tickets or add points for discussion (next section) - no content, just to be done together
- Topics for discussion - single list, everyone can add to it
- (optional) Why did we not achieve our target for the sprint? - 1 row per domain of work
Others notes/decisions during this meeting:
Kiran will create a doc where we can share our “Sprint retrospective” thoughts. Every time that we are going to meet with someone else for a decision, we should share that we are meeting, where and when on the Discord channel so if somebody else is interested in joining.