On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.
The Product Owner is a full member of the Scrum Team and should be present at all Scrum meetings (Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
In one case with a team I was coaching at Capital One, the Product Owner didn’t show up for the Sprint Review and then didn’t show up for the Sprint Planning meeting. The rest of the team decided to delay the start of the Sprint until the Product Owner did show up. The director-level manager of the team, a deeply insightful individual, insisted that all team members take paid days off until the Product Owner was ready to attend the Sprint Review… kind of like a mini-strike. It only took two days for the Product Owner to clear his schedule to attend the Sprint Planning meeting.
Product Owner as Scrum Team Member
The Scrum Guide defines the membership of the Scrum Team as follows:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. 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…. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
As a member of the Scrum Team, the product owner should have the same level of commitment, courage, focus, openness, and respect (the five Scrum values) as any other Scrum Team member. The Product Owner needs to collaborate actively with the Scrum Team. One way to gauge the involvement of the Product Owner is in the Sprint Review. If the Product Owner is giving feedback to the rest of the Team in the Sprint Review, it’s too late! The Product Owner should never be surprised by the product increment shown in the Sprint Review. Instead, the Product Owner should be leading the discussion to get feedback from customers, users and other stakeholders during the Sprint Review.
Being Away from the Team
There are some interesting exceptions to the Product Owner being present. Here are some of the most common:
- The Product Owner needs to be away from the team to work directly with customers, users, sales teams, marketing, customer service people, etc. This work is essential for making sure that the Product Backlog contains the most up-to-date information every Sprint. This time away should normally be scheduled outside of the Scrum meeting times.
- The Product Owner may need to travel to meet with customers and be away from the Scrum Team for an extended period of time.
- Of course, like any other team member, the Product Owner can and should take vacation and may be ill from time-to-time. This may seem trivially obvious. What is not obvious is that it often helps the team to leave another team member with temporary responsibility to fill in for the Product Owner. This temporary fill-in should not be someone from outside the team.
Special Case: The Daily Scrum Meeting
The latest version of the Scrum Guide also puts the Daily Scrum meeting in a special category. The meeting is for the Development Team (the subset of the Scrum Team that excludes the ScrumMaster and the Product Owner). Former versions of the Scrum Guide and other official Scrum documentation have changed this rule in various ways. As a personal comment, I believe this is a serious internal contradiction in the definition of Scrum. If the Scrum Team is self-organizing, then the Daily Scrum should include the ScrumMaster and Product Owner. I have seen this work successfully. The Scrum Guide says nothing about other people observing the Daily Scrum. I strongly recommend that the ScrumMaster and Product Owner observe the meeting even if you wish to follow Scrum strictly and restrict their participation.
If you decide to allow the Product Owner to participate in the meeting, then the Product Owner should restrict their comments to changes in the Product Backlog that require the team’s help for refinement. For example, the Product Owner could report in the Daily Scrum as follows:
“Yesterday I met with Sanjay at Deal Maker Industries and he suggested that we add a feature to allow car manufacturers to ping various stakeholders about risks and options. I think that will mean adding several new user stories to the Product Backlog. I need help from the team to write and estimate the new PBIs. Today I also have a re-prioritization meeting with three key internal stakeholders. My only obstacle is that I still can’t get a meeting with Karen about the marketing of the features from our last few Sprints and I’m worried that will delay our next release.”
In this example, the team and the ScrumMaster are kept apprised of key developments at the product level and know that there will be some extra work during the day to work on Product Backlog Refinement. The Scrum Guide says:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Balance in the Product Owner Role
Ideally, the Product Owner would spend an equal amount of time with their Scrum Team and with outside customers and users. The Product Owner is the key conduit of information from the market to the Development Team. Not being present with the Scrum Team can hinder this flow of information and cause quality problems and unnecessary rework. Again, the Product Owner should never be surprised in the Sprint Review.
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.
From the Scrum Guide:
The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:
- What did I do since the last time we checked in as a team?
- What am I planning to do before the next check in time?
- What impediments, if any, are preventing us from getting our work done?
Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.
Struggling with the Daily Scrum
There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:
- One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
- One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
- An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
- Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.
Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.
Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.
This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.
The Daily Scrum meeting supports the Scrum value of Openness and the principle of self-organizing teams. This rule of Scrum also aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and self-organization becomes compromised. Compromised self-organization yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the openness and self-organization will lack effectiveness.
The principles of openness and transparency include being able to be truthful about ways that you are struggling. A Team Member must share their struggles with their Scrum Team and with the ScrumMaster so that the team, at least, knows your status. Without that visibility, the Scrum Team may make decisions that are difficult or impossible to implement due to hidden obstacles. At every Daily Scrum, each Team Member should think carefully about the challenges they are currently facing, and share those challenges. The ScrumMaster cannot do a good job without that transparency since a core part of their work is to deal with obstacles. If a Team Member fails to be open about obstacles, or fails to recognize something in their environment as an obstacle, this can slow the team in its progress towards becoming a high-performance team. Obstacles that persist for a long period of time simply because they are not openly discussed can have a demoralizing effect on the team. On the other hand, a team that creates full visibility into their obstacles can enlist the help of stakeholders, work together to overcome those obstacles, and systematically become better and better at doing their work.
The Daily Scrum meeting is a critical method for creating transparency between Team Members. Every day, each Team Member in turn answers the three questions of the Daily Scrum: what tasks have I completed, what tasks will I complete before the next Daily Scrum, and what obstacles do I have to doing my work? These questions are designed to ensure that all team members know what everyone else is doing regardless of if one or another team member thinks something is “important” to know. This transparency gives the team a regular rhythm of “Inspect and Adapt”. Since the Daily Scrum is meant to be short, any discussion of the work should be held until after the Daily Scrum is complete. To be clear: the Daily Scrum is not meant to be a problem solving meeting and treating it so can lead to people failing to be as transparent as needed (or to breaking the timebox for the Daily Scrum which leads to other problems).
The Daily Scrum is most effective when it is held at a regular time of day so that all team members can easily remember it, schedule for it, and it becomes a habit for the team. Although technically this is simply a guideline rather than an “official” rule, it nevertheless has a positive impact when done, and a negative impact when not done. If the team fails to have the Daily Scrum at a regular time, Team Members will need constant reminding of when it is going to occur, and there is a greater risk that it will be missed by some Team Members. Missing the Daily Scrum reduces transparency between Team Members. Another minor negative consequence is that if the Daily Scrum is not held at a regular time, then the Sprint Burndown Chart will have an uneven horizontal scale (if measurement is made at the end of the Daily Scrums) or it will be more difficult for the ScrumMaster to measure the state of the Sprint for tracking on the burndown (if measurement is made at a regular time of day independent of the Daily Scrum).
The Daily Scrum is designed to dramatically improve transparency among Scrum Team Members and out to any stakeholders who are interested in observing the meeting. The timebox is a fixed limit on the duration of the meeting. The 15 minute limit on the Daily Scrum is sufficient for each Team Member to take a turn and briefly answer each of the three questions required in the meeting. The timebox forces the Team Members to be brief, to be focused, to be on-topic and to be respectful of other Team Members’ time. If the Daily Scrum meeting takes longer than 15 minutes, some Team Members and stakeholders will stop feeling like the meeting is worth the time investment, particularly since it is daily. Even five additional minutes for a 12 person team adds up to a person-hour of time lost every day! Losing people’s interest or respect for the meeting will decrease transparency and can hamper the team in numerous ways, including the ScrumMaster’s ability to see and deal with obstacles in a timely manner.