Scrum meeting

Scrum meeting

The Scrum Training Series is provided free of charge by CollabNet, Inc. and used by thousands of Agile practitioners, coaches, and trainers around the world.

Scrum Reference Card Excerpt: Daily Scrum and Sprint Execution

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.

Standing up at the Daily Scrum will help keep it short. Topics that require additional attention may be discussed by whomever is interested after every team member has reported.

The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List. During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments.

The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the Scrum Master when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.

Notes For Certification Test Takers

Q: Why should the Product Owner attend the Daily Scrum?

A: This question is inconsistent with the current Scrum Guide. According to the Scrum Guide, the Scrum Master enforces the rule that only the development team participates in the Daily Scrum. See the section above about why this question is based on a flawed assumption. If we’re serious about team self organization (remember principles before practices), inviting the Product Owner to the standup is a Team and Product Owner decision. The Intel case study found their teams did better work when they didn’t invite the Product Owners, due to years of command and control habits (see the thumbs down for «PO on the Team» on page 10). All of the answer choices are probably wrong so I guess you’ll have to pick the one that sounds the least like traditional command and control.

Scrum Reference Card Excerpt: Team Self Organization, Engaged Teams Outperform Manipulated Teams

During Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them. The natural human tendency to be accountable to a peer group contradicts years of habit for workers. Allowing a team to become self-propelled, rather than manipulated through extrinsic punishments and rewards, contradicts years of habit for some managers. The Scrum Master’s observation and persuasion skills increase the probability of success, despite the initial discomfort.

Scrum Reference Card Excerpt: Team Self Organization, Challenges and Opportunities

Self-organizing teams can radically outperform larger, traditionally managed teams. Family-sized groups naturally self-organize when the right conditions are met:

  • members are committed to clear, short-term goals
  • members can gauge the group’s progress
  • members can observe each other’s contribution
  • members feel safe to give each other unvarnished feedback

Psychologist Bruce Tuckman describes stages of group development as “forming, storming, norming, performing.” Optimal self-organization takes time. The team may perform worse during early iterations than it would have performed as a traditionally managed working group.

Heterogeneous teams outperform homogeneous teams at complex work. They also experience more conflict. Disagreements are normal and healthy on an engaged team; team performance will be determined by how well the team handles these conflicts.

Bad apple theory suggests that a single negative individual (“withholding effort from the group, expressing negative affect, or violating important interpersonal norms”) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team’s reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them.

Other individuals who underperform in a boss/worker situation (due to being under-challenged or micromanaged) will shine on a Scrum team.

Self-organization is hampered by conditions such as geographic distribution, boss/worker dynamics, part-time team members, and interruptions unrelated to Sprint goals. Most teams will benefit from a full-time Scrum Master who works hard to mitigate these kinds of impediments.

Scrum Reference Card Excerpt: Related Practices, eXtreme Programming (XP)

While Scrum does not prescribe specific engineering practices, Scrum Masters are responsible for promoting increased rigor in the definition of done. Items that are called “done” should stay done. Automated regression testing prevents vampire stories that leap out of the grave. Design, architecture, and infrastructure must emerge over time, subject to continuous reconsideration and refinement, instead of being “finalized” at the beginning, when we know nothing.

The Scrum Master can inspire the team to learn engineering practices associated with XP: Continuous Integration (continuous automated testing), Test-Driven Development (TDD), constant merciless refactoring, pair programming, frequent check-ins, etc. Informed application of these practices prevents technical debt [high cost of future change —mj].

Scrum Meetings

Scrum meetings happen at particular points in the sprint cycle. These pages will guide you through setting up regular meetings with your team.

Prepare for daily meetings with the daily Scrum meeting. The “daily Scrum” is meant to be consistent – same place and time each day, preferably in the morning. Further, they are meant to be no longer than 15 minutes. The meeting is for the entire team, including the Scrum Master and product owner. It’s important that the meeting is more about status updates than problem solving, which should be solved with appropriate subgroups. Further, the status updates are not to inform the boss on who’s behind, but to keep team members committed to one other. It’s also a way for the Scrum Master to learn about impediments that need addressing.

The sprint planning meeting is another meeting for the entire team. In these, the product owner lays out the highest priorities of the product (enough for two sprints), and the team asks questions that will help break the big concepts into detailed tasks. The idea is to come away from the meeting with both a sprint goal (a short description of achievement goals) and a sprint backlog (list of product features to be delivered and the tasks to make that happen). It’s up to the team, not the product owner, to determine how much work they can do in the coming sprint.

In the sprint retrospective meeting, you reach a point when the Scrum team looks for ways to improve in the wake of a sprint. Once again, this is for the whole team, and can usually happen in about an hour. We recommend structuring the meeting around what the team should start doing, stop doing and continue doing. This is simple and effective, and can be customized to individual teams. The Scrum Master can facilitate and even ask for a vote on items brought up by the team.

The sprint review meeting discusses the actual product produced at the end of a sprint. This is the actual piece of software or product that can be demoed in an informal way. The final product is also measured against the original sprint goals. The overall goal is more important than getting to every product backlog item in the sprint.

Scrum Foundations Video Series

All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.

Daily Scrum Meeting

In Scrum, on each day of a sprint, the team holds a daily scrum meeting called the «daily scrum.” Meetings are typically held in the same location and at the same time each day. Ideally, a daily scrum meeting is held in the morning, as it helps set the context for the coming day’s work. These scrum meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.

There is an old joke in Scrum about a chicken and a pig that illustrates the differences between being committed and being involved.

Scrum affords special status to those who are committed, and many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum meeting.

The team and Scrum Master are considered committed by nearly everyone in the Scrum community. There is some disagreement about the product owner. My view is that a product owner should be considered a dedicated participant of the project. (And should behave as one, too.)

All team members are required to attend scrum meetings. Since both the Scrum Master and product owner are committed team members, they are expected to attend and participate. Anyone else (for example, a departmental VP, a salesperson or a developer from another project) is allowed to attend, but is there only to listen. This makes scrum meetings an excellent way for a Scrum team to disseminate information — if you’re interested in hearing where things are at, attend that day’s meeting.

The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?

By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.

If a programmer stands up and says, «Today, I will finish the data storage module,» everyone knows that in tomorrow’s meeting, he will say whether or not he finished. This has the wonderful effect of helping a team realize the significance of these commitments, and that their commitments are to one another, not to some far-off customer or salesman.

Any impediments that are raised in the scrum meeting become the ScrumMaster’s responsibility to resolve as quickly as possible. Typical impediments are:

  • My ____ broke and I need a new one today.
  • I still haven’t got the software I ordered a month ago.
  • I need help debugging a problem with ______.
  • I’m struggling to learn ______ and would like to pair with someone on it.
  • I can’t get the vendor’s tech support group to call me back.
  • Our new contractor can’t start because no one is here to sign her contract.
  • I can’t get the ____ group to give me any time and I need to meet with them.
  • The department VP has asked me to work on something else «for a day or two.»

In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues), he still takes responsibility for making sure someone on the team does quickly resolve the issue.

The vast majority of teams conduct the daily scrum meeting by having each person answer the three questions in order. You answer all three, then the next person, the next and so on. An interesting alternative that some teams find helpful is to talk through one product backlog item before moving on to the next. In this way, an individual may give an update at multiple different times during the same meeting.

Scrum Foundations Video Series

All the foundational knowledge of Scrum including: the framework, values, different roles, meetings, backlogs, and improving efficiency & quality.

Why Us?

The Daily Scrum Meeting solves practical issues that every project experiences in the development stage.

Who is listening at your stand up meetings? Why “working the board or working the wall” doesn’t solve the major problem, that team members are focused on building “stories” in their minds about what they are going to say, while waiting until the team gets to their assignments at the daily stand up meetings. This happens because, as a human beings, when we speak in public, we want to impress the others and don’t want to embarrass ourselves, that is why we totally focus on what we have to say, rather than listening to each other.

“Can’t beat them — join them!” Our solution is to give the team members a platform to build their “stories”, about what they are going to say, before the meeting along with the status report and therefore focus on the issues during the meeting and significantly reduce the meeting durations. The meetings become more effective and productive giving a true meaning to “inspect and adapt” aspects of the stand up meetings.

What is the “correct board”? Why is transparency so scary? What is wrong with the existing boards? They show the last state of the project or interaction only. There is no option to know the meeting status of what happened at the meeting once it finished. The development process is less transparent for teams themselves who are missing the ability to analyse the data in daily resolution and prepare points for sprint retrospective discussions, for example. Also for supervisors and clients, there is no simple meeting summary at the end of the day.

Be proud of what you did. We’re providing a timeline to navigate between days that includes unique relevant data regarding all teams assignments with goals indication and a full summary for multiple projects in several resolutions such as daily, selected interaction or entire project.

What is “done”? Do you use what you learn? Teams are missing an ability to define accomplished work along with usage of retrospective conclusions which aren’t available in the daily routine. That alone can increase bugs found late by 35% and increase maintenance costs by 20%.

“Say what you do and do what you’ve say.” The Daily Scrum Meeting (DSM) application, gives you the ability to define the milestones which determine that work is accomplished. Its main purpose is to aggregate your teams ideas and relevant retrospective conclusions and to use them in your daily routine to dramatically improve your work quality.

Is there anything blocking your progress? Existing tools are missing an ability to manage individual blocking issues such as, ‘visual studio licence is expired’ or ‘missing an answers from a service provider’ or ‘internet connection is not stable’ or anything else that could block your team progress. Another aspect, that existing tools are missing is an indication of how long the blocker was opened until it was closed.

Timing is critical. Get advantage of real time monitoring. Real time blocking issues management of the DSM, as an entire application, is created to accelerate your development process and get to relevant assignments immediately once the blocker is solved, instead of waiting until the next day meeting update. The DSM’s analytics dashboard provides a clear indication of blockers and the time required to resolve the blocking issue.

Struggling to analyse data? How efficient are you in tool usage? Existing tools are very complex and to extract the relevant data for analytics is near impossible. There is no way to know what features of the tool were used, how often and status. There is no tool today, that gives you an indication of system usage efficiency.

Enjoy the DSM’s analytics dashboard. The DSM’s analytics dashboard contains unique information as summaries, which can be leveraged when analysing reports on a daily basis. Whether your interest is defects indication, providing value and remaining work or monetary settings and ability to convert hours or abstract points to exact profit, DSM is the only tool that provides a detailed summary of tool usage efficiency.

5 Scrum Meeting Best Practices: Master the Daily Stand-Up

The scrum meeting, aka the daily stand-up, is the 15 minute meeting that makes product development teams more productive and efficient.

Yet, sometimes the scrum meeting gets a bad rap. Some even argue it’s an outdated practice and a waste of time. We disagree. So do most of our customers at Sprintly who run agile processes. We’ve all found that this meeting style helps us run our team more effectively.

We’ve also noticed some pretty big differences between those who value scrum meetings and those who don’t. And most of those have to do with how the meeting is run. When mastered, scrum meetings can become an invaluable tool for keeping your development team on track.

So we’ve put together the best tips and tricks to help your scrum meeting run like a lean, mean, effective machine.

So here’s 5 best practices to keep your scrum meeting on track.

Let’s be clear. Everyone does stand-ups a little differently. That’s ok. But no matter what you do, focus and efficiency are priorities.

1/ Remain standing!

It may sound like a gimmick… it may sound like a formality — trust us, it’s not. Staying on your feet is the core principle of the scrum meeting. It reduces rambling and keeps you focused.

An easy solution to eliminate sitters? Hold the meeting in a room without chairs or keep all chairs on one side of the room. Forcing someone to go out of their way to pull up a chair is an excellent way of silently keeping your team on their feet.

2/ Your 3-question agenda

The scrum meeting, in an agile development world, has every team member answer three simple questions:

i) What did you accomplish since the last meeting?

ii) What are you working on until the next meeting?

iii) What is getting in your way or keeping you from doing your job?

This tells the team exactly what is getting done and what needs improvement. Listing any problems or issues you may have is crucial, so that your team will know to help you out. And small problems should always be addressed so that they don’t turn into big problems.

Note: The answer to the first question should only be a brief mention. Far more time should be spent talking about current tasks and the issues you may face.

3/ Have your project management tool visible

This could be in the form of a physical kanban board or software like Sprintly — it’s important for your team to see what is being finished and what is taking longer than expected. This is especially helpful for teams that spend too long answering key question #1. Also, getting everyone into the habit of reviewing the project management tool right before the meeting results in a big efficiency boost.

4/ It’s a collaborative effort

One of the most common scrum meeting mistakes is making it a turn-based 1:1 chat with the project manager or scrum master. This completely defeats the purpose of the stand-up and should be avoided at all costs. This is valuable time that should be treated as collaborative effort for the whole team.

A good way to keep scrum meetings efficient is to establish a simple rule:

Everything you say should be valuable to everyone in the room. Individual talks can happen at any time of the day aside from the stand up meeting.

5/ Plan the meeting around your team

We get that in the real world it’s impossible to adhere to a strict schedule, but it’s important to develop some sort of routine for your stand up meetings. Without a routine, procrastination will take effect and meetings will never happen.

Whether you have it everyday or every week, consistency is key. If your team gets to the office early everyday, hold your meetings first thing in the morning as to not interrupt valuable work time. Is your team’s arrival staggered? Do your team mates have other commitments in the morning? Hold your stand-ups in the afternoon.

The scrum meeting is less about strict rules and more about maximizing productivity. Turning the daily or weekly stand up into a regular routine that accommodates your team’s unique schedule helps ensure scrum meetings are an effective tool for your development team.

Avoidance alert: 4 bad habits that derail scrum meetings.

1. Waiting around for your team

Always start your meeting at the set time. Those who miss it or who are late will feel guilty and try harder to make it to the next one.

2. Introducing new ideas

The scrum meeting is not a planning meeting. Introducing new topics will divert attention away from answering your strict 3 question agenda.

3. Letting people ramble

We get it — asking people to stop talking can be awkward. In general, adhering to the rule, “everything you say should be valuable to everyone in the room” will keep rambling down. If that’s not enough, another simple fix is to set a strict time limit for each speaker.

4. Abandoning team communication in favor of the stand up

The scrum meeting should not be the sole means of team communication. It’s easy to wait around for the next meeting to bring up an issue, but this just slows down your team and bloats the stand up meeting.

Tired of managing your software project with a checklist? Sprintly requires no configuration or training and your team can be up and running in seconds. Click here to try it for free (no credit card required).