The teams of all Clusters in the organization , the Cluster System Engineer Group , the Cluster Product Owner Group and the stakeholders must understand what it means when a backlog entry or a result is referred to as “done”. Although the Cluster DoDs can differ significantly from Cluster to cluster, there is only one portfolio-level DoD for the entire Organization.
Tag: done
Cluster DoD
The Teams of the Cluster , the Team System Engineer Group , the Team Product Owner Group and the Stakeholders must agree on what it means when a Backlog Item or a result is marked as “done”. Although this can vary significantly from Cluster to cluster, everyone must have a common understanding of when work is done to ensure transparency. This is done through the Definition-of-done of the respective Cluster.
The Cluster DoD is the quality promise of the Cluster
The DoD also guides the Team System Engineer Group in deciding how many Cluster Backlog Items it can pull into the Cycle Backlog during Cluster Planning. The purpose of each Cycle is to provide Inspectable Results, Usable Knowledge, or potentially deliverable functionality within a System Increment that correspond to the current Definition-of-done. Clusters provide an increment of results, knowledge and / or system functionality in each Cycle. This increment is fully usable so that the Cluster Product Owner can choose to release it at any time.
If the Definition-of-done for a product is part of an organization’s conventions, standards, or guidelines, all Clusters must follow them as a minimum goal. If “Done” for a result is not part of the organization’s convention, the Cluster (ie the TSEG) must formulate a definition-of-done that is appropriate for the product. If there are several Clusters working on the same system, all Clusters must create a definition of done together. Each system increment is additive to all previous increments and has been thoroughly tested to ensure that all increments work together. More mature Clusters are expected to expand their respective definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the definition-of-done can cause
Every single result, product or system should have a definition of done, which is the standard for any work performed on it.
The DoD therefore is the essence of the process descriptions and “standard operation procedures” of a classic organization, but in a strongly condensed form.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | Cluster Product Owner | Team Product Owner Group | Team DoD
. Usable Knowledge & System Increment . |
Team Backlog, Iteration Backlog & Team Kanban
Team Backlog
Each Team has exactly one Backlog for its area of responsibility and tasks . It consists in the finest level of granularity of Team Goals for the Team. The Team Product Owner is responsible for and prioritizes the Team Backlog . A large part of the Team Backlog is derived by the Team Product Owner Group and the Team System Engineer Group from the Cluster Backlog , or the System Backlogs by refinement of the entries.
The other part of the Team Backlog consists of work and measures that the team carries out to improve the quality of work and results, e.g.
- Quality measures and improvement of the team process from the team’s Improvement Backlog
- Maintenance of the products, systems and Modules responsible for the team
- Maintenance and servicing of tools and tools.
In order to make the team’s working speed more predictable, the proportion of backlog entries derived from the Cluster Backlog should be relatively stable over time (e.g. 80% of the team’s capacity).
The Team Backlog is prioritized by the Team Product Owner.
In Team Backlog Refinement , the Team Backlog Items are presented by the Team Product Owner and estimated by the Working Team.
In Team Planning, the Working Team pulls as many Team Backlog Items as the it believes it can handle due to its previous speed of work. This is the Iteration Backlog, which is the plan for the next Iteration.
Work in iterations or in continuous Kanban-mode
Teams have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Iterations, or in a continuous flow, with each Backlog Item individually going through the different states of the team’s work process. This is then made transparent on a Kanban Board.
As a rule, teams that provide a service for other teams (Service Teams) work with Kanban, since new work can be planned and started at any time, and finished work can be delivered at any time.
Iteration Backlog
The Iteration Backlog reflects the work of a Team for a currently running iteration. The planned work, reflected by backlog elements, is pulled into the Iteration Backlog by the Working Team at the start of the Iteration, which is referred to as Pull.
Team Kanban
If the Team works in Kanban-mode, it uses a Team Kanban Board instead of the Iteration Backlog. The first column corresponds to the Team Backlog and the last column to the status “Done”. All other columns are defined by the Team, according to the team’s internal work process.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team | Inspectable Results
. . |
Team DoD (Definition of Done)
The Team , the Team Product Owner and the Stakeholders must agree on what it means when a backlog entry or a result is referred to as “done”. Although this can vary significantly from team to team, all Team Members must have a common understanding of when work is done to ensure transparency. This is realized through the definition-of-done of the respective Team , Cluster or Organization .
The DoD is the team’s promise of quality
The DoD also guides the Working Team in deciding how many Team Backlog Items it can pull into the Iteration Backlog during the Team Planning. The purpose of each Iteration is to provide inspectable results, Usable Knowledge, or potentially deliverable Features within a System Increment that correspond to the current Definition-of-done. Working Teams deliver an increment of results, knowledge and / or system functionality in each Iteration . This increment is fully usable, so the Team Product Owner can choose to release it at any time.
If the Definition-of-done for a Team is part of the conventions, standards, or guidelines of the Cluster or Organization, all Teams must use this Cluster DoD as a minimal goal. If “done” for a Team is not part of the convention of the Cluster or Organization, the Team must formulate a Definition-of-done that is appropriate for the Team results. If there are several teams working on the same system, all teams have to create a definition of done together. Each System Increment is additive to all previous increments and has been thoroughly tested to ensure that all increments work together. More mature Teams are expected to adjust their respective Definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the Definition-of-done can result in work to be done being uncovered in earlier “done” system increments.
Every single result, product or system should have a Definition of done, which is the standard for any work performed on it.
The DoD therefore is the essence of the process descriptions and “standard operation procedures” of a classic organization, but in a strongly condensed form.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team | Team Backlog
. . |
Team Retrospective
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 …
- to review how the past iteration was in terms of people, relationships, processes, infrastructure and tools involved;
- identify the most important and possible improvements and put them in order; and
- create a plan for implementing improvements to the way the team works.
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.
- Glad, Sad, Mad
- Keep, change, puzzled
- Good, problems, questions
- Start, stop, keep, more, less
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 |
Team Review
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 participants, consisting of the Team and the Stakeholders invited by the Product Owner.
- The Product Owner explains which Team Backlog entries are done.
- The Working Team explains what went well during the Iteration, what Impediments and problems arose, and how the Team solved those. If necessary, the Team asks for support from the Stakeholders regarding Impediments
- The Working Team presents the “done” work results and answers questions. Work results can be:
- Inspectable Results,
- Usable Knowledge,
- an integrated sample of the System, Platform or Application
- The Product Owner presents the current status of the Team Backlog. If required, he provides an updated forecast of delivery dates based on the development progress, e.g. by using a Burn-up-Chart based on the Velocity of the Team
- All participants work together on what to do next so that the Product Owner gets valuable input for the upcoming Team Planning.
- All participants reviews the schedule, budget, potential properties, and market expectations for the next version of the System or Application (aka Release).
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 |