Working agreements, also known as team norms, are guidelines created by teams as to how they must work together to create a positive, productive framework. They include positive behaviors that, although basic, often are not automatically demonstrated in team processes. For example, an agreement might be "We all agree to be punctual at meetings".
Agreements are a powerful tool for teams, and their principles should be posted (written out on a chart or board, or given in a hand-out) for easy reference throughout the team process. They may be set upfront to establish a ONE team culture, and something to refer back when things get rocky within the team.
Working agreements help teams to...
- develop a sense of shared responsibility
- increase members' awareness of their own behavior
- empower facilitators to lead the group according to the agreements
- enhance the quality of the group process
Work agreements should be reviewed at the end of every sprint during the retrospective meeting. Once team members feel they are doing well on one agreement, they can replace it with another agreement to focus on.
Agreements work well when...
- they are important to the team
- they are limited in number
- they are fully supported by each member
- the members are reminded of agreements during process checks
- the members are reminded of agreements when they are broken
Some examples of Team Working Agreements are "Definition of Ready" and "Definition of Done".
SCRUM has two stable states, Ready and Done, which are linked to User Stories. These two states lead to the following SCRUM principle:
Never pull anything into a sprint that is not ready, and never let anything out of the sprint that is not done.
The Definition of Ready (DoR) defines the ready state. In simple terms, an User Story needs to meet some criteria (or conditions) before it can be picked up for a Sprint. The DoR collects all necessary conditions for an User Story to be developed in the current sprint. These conditions are defined via discussion among the Team, the Product Owner, and the Scrum Master. The DoR is important so that every Team member is aware of when to pull a user story in which sprint.
In DoR, the team is the "client" and the product owner is the "supplier". Some examples of criteria on a DoR, defined as Team Working Agreements, are listed below:
- Story contains actors, problem, and value
- Story should fit in a sprint
- Story should be properly documented (does it require wireframes? User-journeys?)
- Value should be obvious, if not, it should be explicitly stated
- Story should have reasonable conditions of satisfaction
- Story should focus on problems, not solutions
In order to come up with the DoR for an User Story, the Team conducts regular backlog refinement sessions with the Product Owner. During these sessions, the Product Owner presents stories to the Team and explains them one by one. Any doubts about Stories should be cleared by the Team posing questions to the Product Owner.
** Benefits of having an established DoR:**
- Avoids wasting time once a Story is started
- Helps the team to identify when a Team member becomes overwhelmed
- Reduces requirement changes during development
- Keeps the Team members focused and accountable to each other
In the end, an User Story is ready if the Team can implement it, and the Product Owner can prioritize it.
The Definition of Done (DoD) is a checklist of activities that adds verifiable and demonstrable value to the product, not only in terms of functionality but also in terms of quality. Focusing on value-added steps allows the Team to focus on what must be completed in order to build software while eliminating waste.
An example of Definition of Done for a Feature or User Story can be:
- Writing code
- Coding comments
- Code coverage unit testing >= 80%
- Integration testing
- Release notes
- Design documents
The DoD is the primary reporting mechanism for team members and allows to be certain of when a Feature is completed. After all, a Feature or Product Backlog Item has two states: done or not-done. The DoD is a simple artifact that adds clarity to the Feature’s "done" state.
SCRUM states that Teams deliver “potentially shippable software” at the end of every Sprint. The team agrees on, and displays prominently somewhere in the team room, the list of criteria which must be met before a “potentially shippable software” is considered "done". Such teams may have a different DoD at various levels:
- Definition of Done for a Feature (Story or Product Backlog Item)
- Definition of Done for a Sprint (collection of Features developed within a Sprint)
- Definition of Done for a Release (potentially shippable state)
The Definition of Done is a live element that changes over time. Organizational support and the Team’s ability to remove impediments may enable the inclusion of additional activities into the DoD for features or sprints. Furthermore, the DoD is an verifiable checklist. The Features or Stories are broken down into tasks both during Sprint Planning and also within a Sprint. The DoD is used to validate whether all major tasks are accounted for (hours remaining). Also, after a feature or sprint is done, the DoD is used as a checklist to verify whether all necessary value-added activities were completed.
Common pitfalls:
- Obsessing over the list of criteria can be counter-productive; the list needs to define the minimum work generally required to get a product increment to the "done" state.
- Individual Features or User Stories may have specific "done" criteria in addition to the ones that apply to work in general.
- If the DoD is merely a shared understanding, rather than spelled out and displayed on a wall, it may lose its effectiveness; a good part of its value lies in being an explicit contract known to all Team members.
Benefits of having an established DoD:
- Provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design.
- Limits the cost of rework once a feature has been accepted as "done".
- Having an explicit contract limits the risk of misunderstanding and conflict between the Development team and the Product Owner.
- What is Definition of Done?
- Definition of Done
- Multiple Levels of Done
- User Stories Applied: For Agile Software Development - Mike Cohn
BEEVA | Technology and innovative solutions for companies