Sprint-plannings, Backlog-grooming And Sprint-retrospectives
Updated 1,328 Days AgoPublic

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 Process Managers 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 Quality Assurance 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 Process Managers 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, Quality Assurance and Process Managers) get a chance to get their opinions out. The Process Managers ensure that the atmosphere is constructive.

Last Author
petersen
Projects
None
Subscribers
None