How to Effectively Collaborate in Sprint Meetings
 
 

Sprint meetings are the foundation of the Scrum methodology. It is where all communication takes place, and plans for the product are formed and advanced. Before we advance, let's again define a sprint.

What is a Sprint?

In Scrum, all work is confined to regular work cycles, known as iterations or sprints. Sprints are normally two weeks long, but can be as short as one week, or as long as four weeks. Originally, all sprints were 30 days long, but the methodology has since changed to favor the shorter sprints.

Product teams are able to devise their own sprint time. If a team finds a two-week sprint too difficult, a one-week sprint should be attempted.

The goal of each sprint is to create a potentially shippable product increment, even if that increment is extremely basic. Since the time frame of the sprints are so short, the team is forced to work on the function or feature that is most essential.

The Scrum methodology is iterative and incremental, which means that each iteration builds on the work from the previous increment. This is why multiple sprints are needed. As soon as one sprint ends, there are the required meetings and the next sprint starts right away.

Each sprint begins with the sprint planning meeting. This meeting brings the product owner and team together to discuss what tasks should be moved from the product backlog into the sprint backlog. One thing to remember, the manager never speaks in the meetings!

Key Terms!

Product Backlog

An ordered list of everything that must be done for a product, listed from most important to least important

Sprint Backlog

An ordered list of tasks taken from the product backlog during the sprint planning meeting

In the sprint planning meeting, the product owner determines what work the team must do, and the team decides how to get the work done. The product owner can cancel a sprint, but that rarely happens.

During the sprint, the team writes the code and does the testing required for the product increment. Scrum teams are cross-functional, so they are skilled at working in other fields, such as development, marketing, testing, etc.

During the sprint, members of the team meet each day at the Scrum meeting, which is often called the stand-up. This is when they discuss what happened the day before, what is on schedule for that day, and whether they have faced any obstacles. It is questionable whether the product owner should attend this meeting or not.

At the end of each sprint, there is a sprint review meeting, when the team shows the potentially shippable product increment to the product owner, as well as the stakeholders and users, if they are interested.

Also, at the end of each sprint, is the sprint retrospective meeting, which is more of a personal meeting. It is at this meeting that the team discusses what went well and what, if anything, they would like to change or do differently.

Types of Sprint Meetings

Sprint Planning Meeting

At the beginning of the sprint, the team holds the sprint planning meeting. At this meeting, the team will decide which items to take off of the product backlog and put onto the sprint backlog. The sprint planning meeting is eight hours, broken into two four-hour blocks.

It is the job of the product owner to decide which tasks are most important to the product iteration. Then the team decides which work they feel they can take on and implement without gaining technical debt. The team then takes tasks from the product backlog and puts them on the sprint backlog.

Key Term!

Timebox

In product management a timebox is a fixed amount of time allocated for a planned activity.

The team can only take on so much work at on time. The team must be able to complete a potentially shippable product increment with each sprint, and until it can do that with regularity, it can only commit to so much work. Over-committing leads to technical debt and possible death of the design.

At the end of the sprint planning meeting, the team will make an initial list of sprint tasks, and decide whether to make a commitment to the work. The most time the team can spend (the timebox) is eight hours for a 30-day sprint. And remember, most sprints now are usually two weeks.

Cheat Sheet for Sprint Planning Meeting

What Is the Meeting? – The sprint planning meeting is for the whole team, and they agree to finish a set of items from the product backlog.

Who Is in Meeting? – The sprint planning meeting is a collaborative meeting between the ScrumMaster (who facilitates the meeting), the Product Owner (who clarifies the product backlog and its level of importance), development team (to define work necessary to complete items on the product backlog).

Before It Begins – All items to be discussed must be ready. This means:

  • A relative story point value

  • All problems/bugs removed

  • Testable samples

  • Clearly defined criteria

The Backlog – The backlog can include almost anything, including new functions or bugs/errors. The items on the backlog must be small enough to be able to be completed in the sprint time (usually two weeks).

The Size of Backlog Items

Items that are too large cannot be considered for the sprint backlog. The product owner can split these items into smaller, more manageable sizes that could be handled by the sprint backlog. Each story must be able to stand on its own (a vertical slice) as opposed to an incomplete story (a horizontal slice).

Determine Velocity

The team's velocity is calculated by adding together all the story point estimates from the last sprint. This way the team knows their throughput.

How to Plan

1. Product owner lists backlog items from most important, to least.

2. Team decides what is necessary to complete the backlogged item.

3. Team members volunteer to do the work

4. Team members estimate time it will take to finish work.

Key Term!

Scrum Alliance

Interested in learning more? Why not take an online Product Management course?

https://www.scrumalliance.org/

It is a non-profit organization that encourages the use of the Scrum methodology. It offers certifications for those who want to become a ScrumMaster, but in no way owns the Scrum name or the terms associated with it, such as product owner, stakeholder, or sprint.

Daily Scrum Meeting

Every day there is a daily Scrum meeting, often called the standup (because it is encouraged that you stand up). The Scrum development team, the product owner, and the ScrumMaster all meet at the same time and place each day for this short 15-minute meeting.

The standup meeting (it is called that because it is short and no one needs to sit down) is run by the ScrumMaster, who asks the team a few simple questions.

What did you accomplish yesterday?

What do you plan to accomplish today?

Are there any problems or obstacles that need to be addressed?

Many teams maintain a sprint task list, a sprint burn-down chart, and an impediments list. It is not uncommon to uncover new tasks that are necessary to achieve the sprint goals.

Think!

Daily standup meetings are a great way for team members to regroup everyday. Have you every worked a job that required daily meetings? Can you think of other professions that have daily meetings?

The product owner should attend the daily standups if possible. Although some teams excel at meetings where the product owner is absent. This meeting is meant to change old habits of working separately and independently.

Daily Meeting Cheat Sheet

How to set up the daily Scrum meeting:

1. Set the meeting at the same time every day. The meetings are the same time and place each day. So if 9 a.m. in the break room works for your team, go for it.

2. Keep the meeting to 15 minutes. The goal of the meeting is to update everyone on where the team is. Any longer would be futile and a waste of time.

3. Standing up keeps the meeting short.

4. Answer the three questions:

What did I do yesterday?
What am I doing today?
What issues I have today that I need help from the team?

Criticism of Daily Meetings

Daily standup meetings have their fair share of criticism, with many people believing they are a waste of time.

1. The meetings interrupt the day, especially if they are held in the morning. Some workers have been known to wait for the standup to be over before they begin work.

2. The meetings lower productivity, because they make everyone stop what they're doing to attend the meeting. However, this happens in most offices and is to be expected.

3. Team members don't communicate until the next meeting. Daily team communication must continue outside of the daily meetings. If you must speak with someone, do so right away.

4. People can overtake the meetings. We all know that one guy who totally monopolizes the meeting. If this happens, the ScrumMaster should intervene.

5. Brief meetings can be a waste of time. If team members say things like "nothing is new," try to get them to elaborate and talk. Try to open a dialogue, if necessary.

Tips for More Effective Daily Scrums

The main goal of the daily Scrum is for team members to check in with each other and determine if there are any problems that must be fixed before attacking that days work. But, the meetings can be ineffective if the team is not focused. Here are some tips to keep daily Scrum meetings on task.

1. Have the meeting around the task board. This way members can refer to tasks as they discuss their work. This keeps the focus on work, and not on what you watched on TV the night before.

2. Change up the questions. Instead of the three normal questions, change things by asking something totally random.

3. If you are burning out of the daily Scrum, take a few days off to recharge.

4. Unless you are taking the sprint tasks, don't talk. There is no reason for you to.

5. Use a "parking lot." If you want to discuss items outside of the purview of the daily Scrum, use a parking lot to grab those topics for later. Other team members can add to the parking lot, as well.

6. Actually stand! If you sit, you might get lazy and linger. You want the meeting to be short and sweet. If you do sit, and the meeting lasts longer than 15 minutes, stand up and start moving.

Sprint Review Meeting

Once a sprint has been completed, the team holds the sprint review meeting to prove it has developed a working product increment. The sprint review meeting is four hours long. The product owner will attend this meeting, as will any interested stakeholder.

This meeting should have a live demo of the new shippable feature, and should not just be a report. After the demo, the product owner reviews the commitments made at the planning meeting and decides what is now done and complete.

The ScrumMaster helps the product owner turn their feedback into new product backlog items, which the product owner will prioritize.

The sprint review meeting is the meeting that stakeholders should attend, as it gives them the opportunity to see the product in a live demo and ask any questions they may have.

Cheat Sheet for Sprint Review Meeting

Guidelines:

The goal is to show that the software is useful and valuable to the customer, not just that it works.

Provide scenarios, so stakeholders can understand features.

Make the demo enjoyable for your stakeholders and customers.

Only show work that is 100 percent complete.

Sprint Review Agenda:

1. ScrumMaster opens the meeting and tells the purpose.

  • Shows what the team has built during the last sprint

  • Engages with the audience

  • Gets feedback

2. The Product Owner presents what he wanted to get out of the sprint.

  • Describe the sprint goal, and why it was chosen.

  • Explain why the goal is important for the project.

3. The ScrumMaster presents the sprint

  • Tells story of the sprint: How did it go?

  • Give a status of the sprint and an overview of which tasks were completed, and which ones weren't.

4. For each task:

  • The demoing team member shows the story description and describes the boundaries, and then demonstrates the feature on a real system.

  • Take questions and listen to feedback while you demo. Collect ideas for new features and user stories to include on the product backlog.

5. ScrumMaster closes the demonstration

  • Finish meeting and thank people for attending and participating.

  • Detail the time and date for the next sprint review meeting.

Extra tips for successful sprint review meetings:

  • Audience/customer participation works really well.

  • It is really important to prepare. It is a good idea to trial the demo before showing it to a larger audience to make sure it flows, and that all info is set up correctly.

  • Have the agenda visible on a wall or whiteboard at all times.

Sprint Retrospective Meeting

When the sprint ends, there is a retrospective meeting. This is a meeting for just the team to look back on their process and determine what went well and what didn't. They determine whether there is anything they should change for the next sprint.

The ScrumMaster will often lead this meeting, and find ways to maintain full transparency, so team members can be honest with their findings. It is important the team members feel safe and that they can discuss anything with the team.

Participating in a sprint retrospective
This meeting is action-oriented and should answer three main questions:
1. What was successful about the sprint? 2. What would we want to change? 3. How can we make that change happen? Before the retroactive begins, the members of the team should think about these three questions beforehand. Notes should also be taken. After these three questions are asked, additional topics could be discussed, such as: Results – How did they compare with what was expected? People – How did the team perform? Relationships – How did the team work with each other? Processes – How did processes for support and development work? Tools – Are the current tools working for the team? Should new tools be implemented, and if so, what kind? Productivity – Can the team increase productivity, and if so, how? One of the Scrum rules is the retrospective should last no longer than 45 minutes per week of the sprint, so normally 90 minutes for a two-week sprint.
It can often be difficult for the teams to be open, and if this happens, the ScrumMaster should ask questions to get people talking.

Sprint Meetings

Beginning of Sprint – Sprint Planning Meeting

Daily – Daily Scrum Meeting or Standup

End of Sprint – Sprint Review

End of Sprint – Sprint Retrospective

Definition of Done

How does a team know if a task is done? How does the Product Owner know if the task is done and completed successfully? The answer is to have a definition of done that you all agree upon.

The criteria for a task being done will normally require items from the product backlog be turned into working software. These requirements are then tested during the sprint.

Before the first sprint, the Product Owner must meet with the ScrumMaster to create the definition of done. It should include what every increment is required to fulfill. Once the definition has been agreed upon, it should be written and posted so it is visible to all.

Transparency and Valuing the Whole Team

Transparency is key in Scrum, in both the sprints and the workplace. This includes all interactions between the development team, the Product Owner, and the stakeholders. It is important that all team members are aware of how important transparency is to the Scrum framework.

When being transparent, open and clear communication is key. In a global environment, communications can take up a lot of time, and opportunities to work together are limited. Therefore these teams must work harder so that there isn't an "Us versus Them" attitude for the team. Members of the team should ask themselves the following questions:

  • Are you contacting your team members in other countries or time zones?

  • Do you make an effort to call team members rather than e-mail or text?

  • If you are a part of a group that has distributed members, do you try to include those members in meetings?

  • Do you update other members before you leave for the day?

  • Do you make other team members stay late due to time zone issues?

  • When you have small coffee breaks with office team members, do you share those thoughts with distributed team members?

  • Do you label other team members or stereotype them?