Refinement of the Cluster Backlog is viewed as the process of adding details to backlog entries, making estimates, or determining the order of entries in the Cluster Backlog.
Tag: Acceptance Criteria
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
. . |
Backlog Item Types
“The Backlog is the only source of the work.” The general description of Backlogs and their properties can be found here.
Backlog entries or Backlog Items are the individual building blocks of backlogs. They are clearly ranked within the backlogs, i.e. clearly prioritized. The higher a backlog entry is, the more important it is and the earlier it is processed.
Similarities
All backlog entries have the following properties and attributes:
- A unique short name or other identification (e.g. a number)
- A description that is as short as possible but meaningful
- An indication of who the source or author of the backlog entry is. This should make it clear who you can ask if anything is unclear.
- Acceptance criteria are defined for concretization and delimitation
- (Optional) At the Portfolio and system level, the respective Product Owners estimate the benefit/value of Applications and Features. For this purpose, benefit values of different applications/features are evaluated relatively against each other, whereby the Product Owners use Planning Poker, for example.
- To indicate that the team in question has performed an analysis and assessment, the estimated effort is noted on the backlog entry
Subdivision of Backlog Items according to type, level, size and format
Formats
In software development, specifying Backlog Items in the format of User Stories has become established. Here, a user request is described in the form of a sentence (who wants what, why). P4 prefers the term Stakeholder Story here, since the users of the system represent only a part of the requestors.
Use Cases that can be divided into different scenarios are often used for further elaboration .
Using Text Requirements , individual Components, interfaces and their abilities and properties can be described.
Size
For a team to edit a Story , it must be small enough to fit into an iteration. Larger stories are Epics by definition , whereby epics in turn have to be divided into several stories.
Type and level
The sum of each Backlog Item level represents the total effort of product development or a System, Market or Application variant that can be delivered.
This is also the idea of epics, stories and tasks that many teams use when using Scrum. The sum of the effort in all epics corresponds to the sum of the effort in all stories. This is based on the (theoretical) assumption that a story is done when all tasks are done and an epic is done when all the contained stories are done. It is the same with the total effort.
If an Application Team or the Cluster System Engineer Group is able to estimate all backlog entries based on the System Requirements & Functions with the limiting Quality Attributes & Constraints , the total effort of an application is completely estimated. Since this is usually not easy, the requirements must be broken down further to the solution level of the System Concepts, architecture and capabilities . At this level, too, it will usually not be possible to estimate all concept elements precisely enough, as there are still many unknowns and uncertainties (in P4: Knowledge Gaps ) regarding the feasibility and the type of implementation.
The concept of Knowledge Gaps is based on the assumption that after all Knowledge Gaps have been closed, product development is successfully completed. The sum of the efforts to close all Knowledge Gaps also corresponds to the total effort of product development. However, making the estimation possible at this level requires a certain amount of time before the organization has learned to do so with sufficient accuracy.
Organizations normally estimate their efforts based on the Samples & Integrations , since the efforts to close the Knowledge Gaps, their boundary conditions and assumptions are defined in a much more concrete way and the backlog entries are refined down to the level of the simulations, patterns and prototypes to be built. It is important here that the incremental and possibly multiple generation and integration of patterns is sufficiently taken into account and depending on the degree of innovation and the degree of risk of Knowledge Gaps, several “proven-of-concepts” or disposable prototypes may be necessary.
A further breakdown at the working level is necessary when Samples & Integrations are implemented by several teams. For this purpose, the backlog entries are divided into Team Goals according to the teams involved , and each team estimates the effort they incur. These can be retrospectively assigned to actual expenses and the relative estimates standardized or calibrated.
At every level of the backlog types, product development is completely described and appreciated. When using relative points for the assessment, a separate “currency” is used at each level. The currencies can be converted into each other if, after some time, data are available that show the speed at which the organization is developing at the various levels (Velocity ).
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner
. . |
Working Team
. . |
Team Backlog
. . |
Team Planning
Iteration Planning (Scrum)
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”.
Continuous Team Planning (Kanban-mode)
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 |