Sprint Planning meeting: ==================== The Kolab sprints begins with the sprint planning meeting. At this meeting, the team negotiate which Tasks from the backlog the team will work on during the next sprint. The meeting is happening during (the end) of the current sprint. The meeting is online, and needs to be limited to 2 hours. If 2 hours is not enough, a new meeting will need to be planned. The team is looking at the backlog (in Phabricator) in the workboard of #sprint_xxx_next, where the #product_owners already has placed the highest priority tasks of the product backlog. The team evaluates each task from the top down, give it story-points, and evaluates how much of the backlog can be done. The #scrum_masters remove the #sprint_xxx_next tag from the tasks if they are estimated not to be done in this sprint. These tasks will then not be visible in the sprint backlog anymore. Backlog grooming (Triage): ===================== Backlog grooming (In Kolab called Triage) is not a formal meeting in this process. It is an ongoing activity facilitated by the #product_owners when needed. The #product_owners, the #architecture_design and the #qa is getting together online and evaluate the product backlog, which is the collection of tasks listed in the //In Triage// step of the #product_owners workboard. Other parties (developers, community members, SMEs, sales or support engineers) can be invited to take part in the triage or in the evaluation of specific tasks. The goal is to define if a task is workable. If: * ..the description of the task is clear enough * ..the user-story is valid * ..the test-case is valid After the triage, the #produt_owners are moving the approved tasks to the //Ready for Sprint// step in the workboard. Sprint retrospective: ================= The sprint retrospective is a meeting facilitated (online) by the #scrum_masters in which the team discuss the result of the just ended sprint (usually on the last day of the sprint). It should be limited to 2 hours. It starts with a run through the tasks, run of test-cases and working software is demonstrated (if possible). Three questions are discussed: * What went well during the sprint cycle? * What went wrong during the sprint cycle? * What could we do different next time? The sprint retrospective is an important mechanism that allows a team to continuously evolve and improve. It is important that everyone involved (development team, #product_owners, #architecture_design, #qa and #scrum_masters) get a chance to get their opinions out. The #scrum_masters ensure that the atmosphere is constructive.

Sprint Planning Meeting ======================= The Kolab sprints begin with the sprint planning meeting. At this meeting, the team negotiates which Tasks from the sprint backlog the team will work on during the next sprint. This meeting, preparing the next sprint, occurs at the end of the current sprint. The meeting is online, and needs to be limited to 2 hours. If 2 hours is not enough, a new meeting will need to be planned. The team looks at the sprint backlog (in Phabricator) in the workboard of `#sprint_desktop_next` and/or `#sprint_server_next`, where the #product_owners have placed the highest priority tasks of the global product backlog (the open tasks from all software development projects). The team evaluates each task from the top down, gives it story points, and evaluates how much of the sprint backlog can be completed. The #scrum_masters remove the association of tasks with the next sprint if they are estimated not to be completed in this sprint. These tasks will then not be visible in the sprint backlog anymore. Backlog Grooming (Triaging) =========================== Backlog grooming (called Triaging) is not a formal meeting in this process. It is an ongoing activity facilitated by the #product_owners when needed. The #product_owners, #architecture_design and #qa get together online and evaluate the (global) product backlog, which is the collection of tasks listed in the //In Triage// column of the #product_owners workboard. Other parties (developers, community members, SMEs, sales or support engineers) can be invited to take part in the triage or in the evaluation of specific tasks. The goal is to define if a task is workable; * ... the description of the task is clear enough * ... the user-story is valid * ... the test-case is valid After the triage, the #product_owners move the approved tasks to the //Ready for Sprint// column in the #product_owners workboard. Sprint Retrospective ==================== The sprint retrospective is a meeting facilitated (online) by the #scrum_masters in which the team discuss the result of the sprint that just ended (usually on the last day of the sprint). It should be limited to 2 hours. It starts with a run through the tasks in the //Done// column of the sprint workboard. Test-cases are run and working software is demonstrated if possible. Three questions are discussed: * What went well during the sprint cycle? * What went wrong during the sprint cycle? * What could we do different next time? It is important that everyone involved (development teams, #product_owners, #architecture_design, #qa and #scrum_masters) get a chance to get their opinions out. The #scrum_masters ensure that the atmosphere is constructive.

Sprint Planning mMeeting: ======================= The Kolab sprints begins with the sprint planning meeting. At this meeting, the team negotiates which Tasks from the sprint backlog the team will work on during the next sprint. This meeting, the team negotiate which Tasks from the backlog the team will work on dupreparing the next sprint., The meeting is happening during (occurs at the end) of the current sprint. The meeting is online, and needs to be limited to 2 hours. If 2 hours is not enough, a new meeting will need to be planned. The team is lookings at the sprint backlog (in Phabricator) in the workboard of `#sprint_xxxt_desktop_next` and/or `#sprint_server_next`, where the #product_owners already hashave placed the highest priority tasks of the global product backlog (the open tasks from all software development projects). The team evaluates each task from the top down, gives it story- points, and evaluates how much of the sprint backlog can be donecompleted. The #scrum_masters remove the #sprint_xxx_next tag fromassociation of tasks with the tasksnext sprint if they are estimated not to be donecompleted in this sprint. These tasks will then not be visible in the sprint backlog anymore. Backlog gGrooming (Triage):ing) =========================== Backlog grooming (In Kolab called Triageing) is not a formal meeting in this process. It is an ongoing activity facilitated by the #product_owners when needed. The #product_owners, the #architecture_design and the #qa is gettingget together online and evaluate the (global) product backlog, which is the collection of tasks listed in the //In Triage// stepcolumn of the #product_owners workboard. Other parties (developers, community members, SMEs, sales or support engineers) can be invited to take part in the triage or in the evaluation of specific tasks. The goal is to define if a task is workable. If: * ..; * ... the description of the task is clear enough * ... the user-story is valid * ... the test-case is valid After the triage, the #product_owners are movinge the approved tasks to the //Ready for Sprint// stepcolumn in thee #product_owners workboard. Sprint rRetrospective: ==================== The sprint retrospective is a meeting facilitated (online) by the #scrum_masters in which the team discuss the result of the sprint that just ended (usually on the last day of the sprint). It should be limited to 2 hours. The sprint retrospective is a meeting facilitated (online) by the #scrum_masters in which the team discuss the result of the just ended sprint (usually on the last day of the sprint)It starts with a run through the tasks in the //Done// column of the sprint workboard. It should be limiTest-cases are run and working software is demonstrated to 2 hoursif possible. It starts with a run through the tasks, run of test-cases and working software is demonstrated (if possible). Three questions are discussed: * What went well during the sprint cycle? * What went wrong during the sprint cycle? * What could we do different next time? The sprint retrospective is an important mechanism that allows a team to continuously evolve and improve. It is important that everyone involved (development teams, #product_owners, #architecture_design, #qa and #scrum_masters) get a chance to get their opinions out. The #scrum_masters ensure that the atmosphere is constructive.