.png)
Why do we need team agreements?
Scrum teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. To become self-organized, a team has to go through various stages of team development.
Tuckman's stages of team development
The "forming, storming, norming, performing" model of team development was first proposed by Bruce Tuckman in 1965. He maintained that these phases are all necessary and inevitable in order for a team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.
A Scrum team does not have the luxury to be in each of these stages for much time, as it is expected to deliver right from the first sprint. Thus the need for formulating team agreements arises at an early stage. Sprint Zero is the ideal time for a Scrum team to go through all of these stages within a very short period. As Scrum is iterative and incremental, a Scrum team goes through Tuckman's stages in each sprint and improves its performance in every new sprint.
Knowing what kind team agreement a Scrum team might need is useful for the team members. It helps avoid conflicts. This knowledge can help them set the team agreements in advance during Sprint Zero rather than deciding what should be done at the last moment, in the middle of working sprints.
Team agreements can be defined and agreed upon in a meeting facilitated by the ScrumMaster. Various steps that can perform in this meeting are: prepare, brainstorm, sort, categorize, agree, and refine.
Scrum teams set the work agreements
Team members themselves set agreements. The Scrum Master may play the role of facilitating the meeting that's held to come up with workable agreements, but it is the team that decides on the agreements themselves. The team also reviews them periodically during retrospective meetings.
The best time to organize this meeting
Sprint Zero is the best time to set the team agreements. Sprint retrospective meetings are also times when team agreements can be formulated and old agreements can be challenged and changed.
Team agreements are required within each sprint ceremony.
Team agreements -- Backlog refinement meeting
The purpose of backlog refinement (grooming) is to make improvements to the product backlog. Backlog refinement is done before development of a user story in the current sprint (iteration). Generally, sometime during the previous one or two sprints, the team sits down to discuss the upcoming work.
Backlog refinement is a collaborative effort involving the facilitator (ScrumMaster), representative(s) from the management team (product owner), and the development team.
What is the suitable time and duration OF this activity?
Backlog refinement is a ceremony for which there is no specific time prescribed in Scrum. The toughest part is that team members have to take out time for this meeting within their existing sprint. It's like saving 10 percent of your salary for future use. The ScrumMaster should facilitate and get the team members and product owner to agree on a few slots of one to two hours each, sometime during the middle of the sprint. This will help the team plan its work for the current sprint.
Who will participate in this activity?
Ideally the entire Scrum team participates in the backlog refinement meeting. If everyone can't attend, the participants should be identified depending on the current workload and tasks.
Agreement between product owner and team, regarding the details in user stories, wireframes, prototypes, etc.
There is a need for agreement between the team and the product owner regarding the details of the user stories the team is required for development. This can be a measure of the quality of those user stories.
What should be the maximum size of a user story?
When refining the backlog, it's important to size the user stories. It's important for the team to decide on the maximum size of the user story they can pick up, and complete in an iteration. Ideally, the user story should be small enough to be completed within 25 percent of the sprint time.
Choosing the baseline user stories and their points
It's important to have some baseline user stories with defined points, to make a relative comparison of the stories to be estimated. All the team members should agree on these baseline user stories.
Which estimation technique should be used?
The team should agree with the techniques used for estimation. Expert opinion, analogy, and desegregation are some of the techniques used. Each of these techniques may be used on its own, but they should be combined for best results. The best way for Agile teams to estimate is by playing Planning Poker. Planning Poker combines expert opinion, analogy, and desegregation in an enjoyable approach to estimating that results in quick but reliable estimates.
What will be the Definition of Ready?
The Definition of Ready (DOR) ensures that the stories are ready to be taken in the sprint planning meeting for the next sprint.
The product owner and the development team will agree on the DOR criteria for user stories. Below are some important DOR criteria:
The user story must meet the INVEST principle.
The user story must have clarity from the "what" point of view.
All assumptions, constraints, and dependencies must be identified and addressed.
Team agreements -- Sprint planning meeting
At the beginning of each sprint, the product owner and the team hold a sprint planning meeting to negotiate which product backlog items they will attempt to convert to working products during the sprint. Toward the end, the team breaks the selected items into an initial list of sprint tasks and makes a final commitment to attempt the work.
Duration and time of the sprint planning meeting
The maximum allotted time for planning a 30-day sprint is eight hours. The team can agree to reduce that, proportionally, for a shorter duration. Team members should agree on having this meeting on the first day of the sprint. The product owner should agree to provide his or her dedicated time for this meeting.
This meeting runs long, the team can agree to break it into two parts. In one the product owner can demonstrate the user stories to the team and, based on capacity/velocity, the team can agree on the sprint backlog and define the sprint goal. In the second part, team members can break the user story into tasks.
Another agreement can be to have a user story demonstration by the product owner followed by task breakdowns done together. This gives the advantage of the product owner being involved when task breakdown is done, and he or she can clarify any queries surfacing during the task breakdown. The team may plan short breaks after 20 to 30 percent of the capacity is covered.
Input criteria for the sprint planning meeting
It has been observed in various projects that when the team is holding the sprint planning meeting, there are members who have not read and understood the story even once. All team members participating in sprint planning meetings should read and understand a few of the top-priority product backlog stories, which should be agreed upon as input criteria for the sprint planning meeting. The product owner should ensure that enough prioritized backlog is available for the team to go through before the sprint starts.
Deciding on the number of stories being picked for the current sprint
The team should know its capacity and velocity and should agree on the number of stories to be picked for the sprint.
How the tasks break down
The process of task breakdown should be predefined in order to avoid conflicts at the last moment. This is mostly done in the second part of the sprint planning meeting. It's best to agree on doing the task breakdown together for each user story selected for the sprint backlog, rather than in isolation by the members who have picked the user story.
How to handle big user stories?
The product owner and development team should decide on the size of user stories that can be picked for the sprint backlog. If any user story doesn't fit, a process should be defined either to break it down within the sprint planning or keep it in the product backlog to further break it down and then take it for the next sprint planning.
What will be the Definition of Done?
The Definition of Done (DoD) is the most critical item that needs to be agreed upon between the product owner and the development team. The DoD may be different for different user stories. Usually the team and product owner agree on a generalized DoD at a high level in Sprint Zero and then attach an amended version of it for each story during sprint planning.
Team agreements -- Daily Scrum/Daily stand-up
Every day at the same time and place, the Scrum development team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces. The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach.
What should be the time for the Daily Scrum?
The Daily Scrum is usually held at the beginning of the day. For a distributed team, it is necessary to get a team agreement for the Daily Scrum time, one suitable for all team members.
Location for the Daily Scrum
In order to avoid any confusion, the Daily Scrum should be done at the same location every day. Distributed teams can use online meeting services.
Duration for the Daily Scrum
Given a team of about seven people, the Daily Scrum should not last longer than 15 minutes. Based on the number of team members, location, and technology used, the Scrum team can agree to a realistic timebox for this meeting.
Team Agreements -- During the sprint
During the sprint, the development team works in the stories committed for delivery based on priority. Any queries regarding requirements and business logic are clarified by the product owner. Any impediments faced by team members are communicated to the ScrumMaster, who resolves them and helps the team stay focused.
All necessary documentation is prepared and updated. Story points are burned as per priority and efforts are made to the achieve the sprint goal.
Coding standards
Coding standards should be agreed upon in Sprint Zero. Sometimes not all team members have read the document listing the coding standards. The entire team should schedule a meeting to discuss and understand these coding standards.
Pair programming
Pair programming techniques are not very common. It takes time for a developer to get into the pair programming habit to gain its benefits. Team members should practice this activity.
Leave planning
Leave panning is another critical factor that can have a recursive effect on delivery. Team members should agree on communication channels to inform each other of all leave plans. It is advisable to update the leave plans on the Scrum board.
Impediments, escalations, and risk handling
The ScrumMaster and team should agree on a process for communicating and tracking impediments, escalations, and risks.
"Soft skills" agreements
There are various common agreements that go unspoken but that the team should review from time to time. The team should be sure to keep the minimum work in progress, to concentrate on the sprint backlog and not on other unrelated items, and to follow and practice the Agile values and principles.
Team agreements -- Sprint review meeting
The team demonstrates a working product increment to the product owner and everyone else who is interested. The product owner reviews the commitments made at the sprint planning meeting and declares which items he or she now considers done.
Who will give the demo?
The demo should be ideally given by the person who has developed the functionality. The team can agree on the business analyst giving the demo rather than different members explaining the functionality developed.
Who will set up the environment for the demo?
It's important to ensure that the environment for the demo is set up the day before the review meeting.
Who will take notes for the feedback given by stakeholders?
During the demo and feedback session from the client, the team should take notes. Someone from the team, or everyone, should take feedback notes. The product backlog should be updated with the feedback.
Team agreements -- Sprint retrospective meeting
Each sprint ends with a retrospective meeting. Team members inspect their behavior and take action to adapt it for future sprints. An in-depth retrospective requires an environment of psychological safety not found in most organizations.
What is the technique or structure used for the sprint retrospective?
There are various methods for sprint retrospectives. The team should be aware of activities such as timelines, triple nickels, team radar, and force field analysis, which can help team members surface the team agreements required for sprint retrospective.
Who will be the invited participants, other than the team members?
There are instances when the team does not feel comfortable holding the retrospective in the presence of the ScrumMaster or product owner. The team should decide on the participants to be invited for the sprint retrospective, and this may differ from one sprint to another.
Plan the action items
All the items discussed in the sprint retrospective may not be converted to action items for the next sprint. The team has to decide on an approach to prioritize the items and decide on some feasible action items that can be implemented and executed in the next sprint.
Someone from the team should volunteer to take notes.
Maintaining the work agreements
Once the work agreements are defined, they may or may not be documented. There might be some agreement, such as coding standards, that are important to note down; others, such as timings and timeboxing for meetings, may not need to be documented.
Once the work agreements are in place, they should be reviewed from time to time. Work agreements can be reviewed at the end of every sprint, during the retrospective meeting, or at any time during the sprint as required. Once team members feel they are doing well on one agreement, they can replace it with another agreement.
Conclusion
There are some agreements that can be made quickly, and there are some that are not as easy. There might be a conflict between team members as they try to reach consensus. The ScrumMaster plays a critical role in helping them. The team agreements, once formulated, make the work environment suitable and help the team become self-organized.
About Advance Agility
We, at Advance Agility, are the new-age Agile Coaching, Consulting and IT services company. We enable end-to-end Digital Transformation. Agile execution is integral to our being. We are doing SAFe implementation with small, medium and large organization across the globe. Our vision is to be the leading Agile execution player globally.
To keep adding value at every process stage, we are on a mission to empower our clients, move from concept to cash in the shortest sustainable lead time by adopting human centric approach to business agility. Embracing the change is in our DNA. Things that keep us apart are Quicker and Seamless execution with End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitor.
Connect with us at advanceagility.com to learn about SAFe and SAFe Implementation. We provide various SAFe certification courses along with DevOps, Scrum, Agile Coaching and more trainings. Write to us at contact@advanceagilty.com for any agile training or consulting needs. We are always looking for competent agile trainers as well. So if you are a good trainer or want to become one, do get in touch with us to that we can learn, grow and achieve together.
.png)
Comments