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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
Team agreements can be defined and agreed upon in a meeting facilitated by the ScrumMaster. Various steps that can performed in this meeting are: prepare<\/em>, brainstorm<\/em>, sort<\/em>, categorize<\/em>, agree<\/em>, and refine<\/em>.<\/p>\n Team members themselves set agreements. The ScrumMaster may play the role of facilitating the meeting that’s held to come up with work agreements, but it is the team that decides on the agreements themselves. The team also reviews them periodically during retrospective meetings.<\/p>\n First sprint 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.<\/p>\n Team agreements are required within each sprint ceremony.<\/p>\n 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.<\/p>\n Backlog refinement is a collaborative effort involving the facilitator (ScrumMaster), representative(s) from the management team (product owner), and the development team.<\/p>\n 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 middle of the sprint. This will help the team plan its work for the current sprint.<\/p>\n 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.<\/p>\n There is a need for agreement between the team and the product owner regarding the details of the user stories the team requires for development. This can be a measure of the quality of those user stories.<\/p>\n 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.<\/p>\n 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.<\/p>\n The team should agree on the techniques used for estimation. Expert opinion, analogy, and disaggregation 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 disaggregation in an enjoyable approach to estimating that results in quick but reliable estimates.<\/p>\n The Definition of Ready (DOR) ensures that the stories are ready to be taken in the sprint planning meeting for the next sprint.<\/p>\n The product owner and the development team will agree on the DOR criteria for user stories. Below are some important DOR criteria:<\/p>\n At the beginning of each sprint, the product owner and 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.<\/p>\n 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.<\/p>\n As 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The team should know its capacity and velocity and should agree on the number of stories to be picked for the sprint.<\/p>\n 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.<\/p>\n 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 sprint planning or keep it in the product backlog to further break it down and then take it for the next sprint planning.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n During the sprint, the development team works on 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.<\/p>\n All necessary documentation is prepared and updated. Story points are burned as per priority and efforts are made to the achieve the sprint goal.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The ScrumMaster and team should agree on a process for communicating and tracking impediments, escalations, and risks.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n It’s important to ensure that the environment for the demo is set up the day before the review meeting.<\/p>\n 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.<\/p>\n 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.<\/p>\n There are various methods for sprint retrospectives. The team should be aware of activities such as timelines<\/em>, triple nickels<\/em>, team radar<\/em>, and force field analysis<\/em>, which can help team members surface the team agreements required for sprint retrospective.<\/p>\n 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.<\/p>\n 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.<\/p>\n Someone from the team should volunteer to take notes.<\/p>\n 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.<\/p>\n 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.<\/p>\n There are some agreements that can be made quickly, and there are some that are not as easy. There might be 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.<\/p>\n What next?<\/strong><\/p>\n Agreements with your boss?<\/em><\/p>\n \u00a0<\/p>\n Browse our Scaled Agile training courses here<\/a>.<\/p>\n\n Scrum teams set the work agreements<\/strong><\/h2>\n
The best time to organize this meeting<\/strong><\/h4>\n
Team agreements — Backlog refinement meeting<\/strong><\/h4>\n
What is the suitable time and duration for this activity?<\/strong><\/h4>\n
Who will participate in this activity?<\/strong><\/h4>\n
Agreement between product owner and team, regarding the details in user stories, wire frames, prototypes, etc.<\/span><\/h4>\n
What should be the maximum size of a user story?<\/strong><\/h4>\n
Choosing the baseline user stories and their points<\/strong><\/h4>\n
Which estimation technique should be used?<\/strong><\/h4>\n
What will be the Definition of Ready?<\/strong><\/h4>\n
\n
Team agreements — Sprint planning meeting<\/strong><\/h4>\n
Duration and time of the sprint planning meeting<\/strong><\/h4>\n
Input criteria for the sprint planning meeting<\/strong><\/h4>\n
Deciding on the number of stories being picked for the current sprint<\/strong><\/h4>\n
How do the tasks break down?<\/strong><\/h4>\n
How to handle big user stories?<\/strong><\/h4>\n
What will be the Definition of Done?<\/strong><\/h4>\n
Team agreements — Daily Scrum\/Daily stand-up<\/strong><\/h4>\n
What should be the time for the Daily Scrum?<\/strong><\/h4>\n
Location for the Daily Scrum<\/strong><\/h4>\n
Duration for the Daily Scrum<\/strong><\/h4>\n
Team Agreements — During the sprint<\/strong><\/h4>\n
Coding standards<\/strong><\/h4>\n
Pair programming<\/strong><\/h4>\n
Leave planning<\/strong><\/h4>\n
Impediments, escalations, and risk handling<\/strong><\/h4>\n
“Soft skills” agreements<\/strong><\/h4>\n
Team agreements — Sprint review meeting<\/strong><\/span><\/h4>\n
Who will give the demo?<\/strong><\/h4>\n
Who will set up the environment for the demo?<\/strong><\/h4>\n
Who will take notes on the feedback given by stakeholders?<\/strong><\/span><\/h4>\n
Team agreements — Sprint retrospective meeting<\/strong><\/span><\/h4>\n
What is the technique or structure used for the sprint retrospective?<\/strong><\/h4>\n
Who will be the invited participants, other than the team members?<\/strong><\/h4>\n
Plan the action items<\/strong><\/span><\/h4>\n
Maintaining the work agreements<\/strong><\/h4>\n
Conclusion<\/strong><\/h5>\n