Team Tasks are activities and actions that a Working Team plans and carries out in order to achieve Team Goals . Team tasks are part of the Iteration Backlog and are usually only crated and planned in the Team Planning event.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team
. |
Team Backlog |
Team goals are the most used elements of the Team Backlog . They describe the goals and (interim) results of the team regarding a Feature, a Module or a Service , depending on the type and responsibility of the Team .
Generally speaking, the Working Team turns Team Goals into Inspectable Results.
The Team Retrospective gives the team the opportunity to review themselves and to identify and plan improvements in the way they work for the upcoming iteration . It takes place between the Team Review and the next iteration planning. For a four-week iteration, an upper limit of three hours is set. The meeting is usually shorter for shorter iterations. The Scrum Master ensures that the meeting takes place and that all participants understand its purpose. The Scrum Master ensures that the meeting is constructive and productive. The Scrum Master teaches everyone how to adhere to the time frame (time box). Due to its responsibility for the P4 process, the Scrum Master takes part in the Team Retrospective as an equal member. The Team Retrospective is being held to …
The Scrum Master encourages the team to improve their development processes and practices within the P4 framework to work more effectively and satisfactorily in the upcoming iteration. In each Team Retrospective, the team works out ways to improve result quality by adapting the processes accordingly or by defining-of-done, provided these changes are appropriate and do not conflict with product or company standards. At the end of the Team Retrospective, the team should have identified improvements for the upcoming iteration. The implementation of these improvements in the next iteration is the adaptation effort for self-examination of the team.
In the meantime, there are many methodological approaches and questions for the course of the Team Retrospective, e.g.
There are many more ideas and suggestions under Fun Retrospectives or Retromat .
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner | Working Team | Team Backlog |
At the end of each iteration, an Team Review is held in which the Team presents the results to the Stakeholders, with the Team receiving feedback from the Stakeholders and then jointly adjusting the Team Backlog when needed. Together with any changes to Team Backlog during the past Iteration (within the Team Backlog Refinement meetings), these provide the basis for the work on possible new value-added items. The Team Review is an informal meeting, not a status report. The demonstration of the results is intended as a stimulus for feedback and the basis for cooperation. At the end of the Team Review, the Product Owner may present an update on costs and scheduled dates or milestones.
For a four-week Iteration, an upper limit of four hours is used as the timebox for this meeting. For shorter Iterations, a shorter timebox is used. The Team Scrum Master ensures that the event takes place and the participants understand its purpose. The Team Scrum Master teaches all participants to complete the event within the given timebox.
The Team Review includes the following elements:
The result of the Team Review is a reworked Team Backlog that matches the participants’ common knowledge and allows the Team to work on the highest value Team Backlog Items in the next Iteration. The Team Backlog can also be extensively redesigned to take advantage of new opportunities.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner | Working Team | Team Backlog |
The Team Backlog Refinement is the process of adding details to the Team Backlog entries, making estimates, and determining the order of the Team Backlog entries. Refinement is a continuous process in which the Team Product Owner and the Working Team together detail the Team Backlog entries. When the Team Backlog is refined, the entries are examined and revised. It should normally not take up more than 10% of the Working Team’s capacity. However, the Team Product Owner can update or have the entries in the Team Backlog updated at any time.
The Team Backlog Refinement mainly serves to prepare the next Team Planning . In this case, the Team Product Owner the Working Team new team Backlog Items before and can appreciate this from the Working Team. If entries are about to begin, the team makes sure that the entries are small enough that they can be dragged into an iteration. (This is a prerequisite for the “pull” and is often also referred to as part of the Definition of Ready (DoR) ). If this is not the case, the team refines the corresponding entry by splitting it into several entries (splitting).
If the team does not work in iterations, but continuously using Kanban, the team agrees on an estimate limit from which it is necessary to split Backlog Items.
Estimates by the entire team are important for two reasons
The team uses the Planning-Poker ® method to estimate the effort .
–
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner | Working Team | Team Backlog |
The Team Sync is a daily recurring team event of no more than 15 minutes in which the members of the Working Team synchronize themselves “on eye-level” without reporting to a supervisor. The Team Product Owner only takes part if the team invites him. Even the Team Scrum Master does not have to participate, but is needed especially for not yet mature teams as support.
The Team Sync takes place in front of the team’s task board, usually in a semicircle. Team Members move task cards and TBI cards during this event.
Typically, each team member answers three questions:
To support the process, many teams use an item as a “token” that moves from team member to team member indicating who’s turn it is.
Due to the shortness of the maximum of 15 minutes, the Daily is only suitable for identifying problems, but not discussing them. For discussion of issues, the required team members can do so after the Daily, while the unneeded team members can continue to work.
Visitors who want to witness the Daily can participate with the permission of the Working Team. The visitors stand in the second row and only listen, unless they are addressed by a team member. Visitors can be:
Once or several times a week, members of the Extended Team come to the Daily, which is referred to as the Extended Daily. They answer their three questions accordingly …
Because members of the Extended Team are by definition working with several teams, it is important to ensure that the extended dailies of these teams take place at different times, so members of the Extended Team have the opportunity to attend. Within the organization, at least within the cluster, a coordinated cadence of events allows for minimal overlap and optimal workflow.
If two teams work together very closely, it may make sense to have a joint daily or weekly session. One team listens while the other carries out his daily and vice versa.
–
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner | Working Team | Team Backlog |
Each Iteration begins with the Team Planning event of the Team. Here, the Team Product Owner presents the Working Team with the current state of the Team Backlog. New entries or changes that are not yet known to the Working Team since the last Team Backlog Refinement are estimated, and if necessary supplemented by Acceptance Criteria and prioritized by the Team Product Owner within the Team Backlog.
The Working Team determines the capacity for the next Iteration by looking at the team’s previous work rate (Team Velocity) and filling the Team Calendar, which shows the time that each Team Member can spend for the Working Team.
The Working Team pulls the number of TBIs into the Iteration Backlog that matches the teams capacity for the next Iteration. Afterwards the Working Team refines the TBIs by creating Tasks, depending on the complexity.
Then, the Working Team starts the Iteration by pulling the first Tasks (or TBIs) from “open” to “in progress”.
As an alternative to the planning rhythm in Iterations, the planning of work for the team can also be done continuously. This is done during, the Team Backlog Refinements, whereby the work on a Team Backlog Item can be started directly after the analysis and estimation.
–
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Sync
. . |
Team Product Owner | Working Team | Team Backlog |
The TSM ensures that the members of his Team can work optimally. He ensures an optimal work flow between the team members, by discovering improvements and solving disabilities and problems (presented managed in the Team Improvement Backlog) that arise in the cooperation of the teams. This especially concerns those that cannot be solved independently by the self-organized Working Team.
For this purpose, she organizes and moderates the Team Retrospective, in which the team members exchange ideas and experiences in order to strive for an optimum of working conditions and workflow within the team.
The Team Scrum Master works together with other TSMs within the Cluster (Team Scrum Master Group (TSMG) ) to prevent local optimization within the team and to solve problems between teams.
Click here for a general description of the Scrum Master role.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner
. . |
Working Team | Team Backlog |
The Team is the basic element of an agile organization and forms the home of employees.
Most of the work takes place in stable and long-lasting Teams. Due to the stability or “longevity”, the teams are available in the event of problems even if the Application or Market Variant is not currently being revised (ie when the classic project teams no longer exist).
P4 adopts the basic structure of a Scrum team. It consists of a Team Product Owner , Team Scrum Master and the Working Team who works together to create value for the Stakeholders. The principle of the separation of powers creates clearly defined areas of role responsibility that complement each other in the Team.
The Team Product Owner is responsible for maximizing the value of the “Product” resulting from the work of the Working Team. How this happens can vary greatly depending on the organization and Working Team, as well as the experts working in them. The Team Product Owner is the only person responsible for managing the Team Backlog.
The Working Team consists of three to nine members and the Team System Engineer , who work out finished and inspectable results in each Iteration and ideally present a potentially deliverable system or subsystem in the Team Review at the end of the Iteration .
The Team Scrum Master is a “Servant Manager” and is responsible for encouraging and supporting team work in accordance with the Scrum and P4 rules by helping everyone involved to understand the values and practices.
