Get certified - Transform your world of work today


Your Product Owner Is Missing in Action — Now What?

25 March 2013

Eric King

We all know that three key groups exist in both the creation and implementation of successful Agile teams. These groups serve basic functions that are important for the team's collective and ultimate success. Many of the functions that each group performs are tightly woven into the fabric of the others. Yet, even with all of the planning, foresight, and intent, there are times when highly visible members of the Agile team go missing in action (MIA).

The intent of this article is to review what bad things happen to the entire team when the product owner goes MIA. I'll also review some preventive-maintenance techniques for keeping the product owner within the collaborative team structure.

What bad things happen when the product owner is MIA from:

  • Stand-ups/the Daily Scrum. Your team may experience situations when your product owner is clearly absent from your stand-up (aka Daily Scrum) huddles. Being absent a few times during a sprint cycle isn't a bad thing, as many of us understand the challenges that a good product owner faces on a daily basis. However, when the attendance record is an abysmal 0 percent, the team will eventually take notice. Some members may begin to wonder if the project they're working on has suddenly taken a backseat to a more important initiative. Others will become disillusioned, thinking that the product owner simply doesn't care about the sprint activities. Both of these sentiments can and will cause a rift between the team members and the product owner. As someone once said, "It's easy to break things, but difficult to build something." Your product owner is an important part of your daily activities, and this 15-minute session is integral to the entire team's success.
  • Demos and retrospectives. A good product owner will do his or her best to accentuate and highlight the accomplishments of the team at the end of each sprint cycle. An important forum where the product owner can accomplish these tasks is found in the demo/retrospective. The product owner should also be leading the charge during the product demonstrations, both so that the audience is as engaged as possible and also to determine whether the strategic approach/prioritization has remained the same. Yet, over time and especially with extended time-line projects, a product owner may become disengaged with the demo/retrospective. The behavior is subtle at first; you may notice that:
    • The product owner slowly starts turning the demo over to the development team, to the point that he or she isn't providing any input or highlights.
    • The product owner starts physically moving back in the room, away from the front.
    • The product owner doesn't appear to be actively engaged in the demonstration.
    • The product owner is buried in his or her laptop during the demo.
    • The product owner slowly withdraws from the retrospectives/reviews.
  • These examples above can and will be very demoralizing to the team members left to take up the slack. The full potential of the self-governing team will not be realized and team performance will suffer.
  • Product backlog. In the early stages of the project and/or program, product owners are heavily involved in helping to determine a product backlog. They work closely with their respective line-of-business counterparts to help determine the necessary product backlog activities as well as their priority sequence. This approach works well as long as the product owner remains actively involved the sequencing and prioritization activities. However, when a product owner loses focus on the backlog, the immediate and ancillary teams will suffer. Immediate team members include the development group and the ScrumMaster, while the ancillary team may include stakeholders as well as line-of-business representatives. The end result often causes an extreme disconnect between everyone on the immediate and ancillary teams. This disconnect will negatively affect product quality, line-of-business confidence, and continued stakeholder support.
  • Sprint backlog. Similar to the product backlog mentioned above, the sprint backlog is an area that requires continual participation by the product owner. Like other members of the immediate team, the product owner should help to ensure that:
    • Stories are sprint ready. A good product owner will help ensure that requirements are clearly articulated and/or documented for the story. More important, an excellent product owner will help make sure that the "latest" requirements are either articulated and/or documented for the story. Fortunately for the continual improvement of the product, requirements should and do change. Unfortunately, requirement changes are not always clearly documented and communicated to the immediate team members. Product owners help manage this overall process to ensure the best outcomes for everyone.
    • Stories are clearly defined and written correctly. Let's be honest with this one. In the initial stages of a new project or program, everyone does an excellent job of story writing. Yet as time goes on, the true art of story writing begins to wane. Usually when this happens, the stories become cryptic and are only understood by a select few. Whether the stories are on a physical or an electronic board, a majority of immediate team members will become confused as to what the stories are attempting to convey. Product owners can provide critical input here; their absence will be immediately felt by everyone.
    • Stories have some success criteria. Stories without some type of success criteria should not be considered "sprint ready" to begin with, yet they will make it into a sprint from time to time. Good product owners will make sure that some type of success criteria exists within the story. Great product owners will help make sure that everyone directly involved in the story completely understands the success criteria. The criteria methods for teams are irrelevant, but what is highly relevant is that the product owner is proactively driving this part of the project/program. If he or she is absent, team members will make their best assessment about what criteria should exist. While the intent is certainly there, this fallback approach will eventually lead to a greater number of application defects.

Based on the real-life examples above, we can definitely see what bad things will happen when a product owner goes MIA. There are a number of different factors that can play into an MIA situation, but some preventive-maintenance techniques exist that can help avoid calamity and team disaster. Below is a simple concept that you can incorporate into your own structure:

Build a cultural atmosphere of team and individual empowerment. For many companies who use Agile/Scrum methods, the team dynamic is blurred. Team members have completely different reporting and chain-of-command structures that don't necessarily lead to open and honest dialogue. I call this "command-structure confusion," and it causes immediate team members, such as the product owner, ScrumMaster, developers, and quality assurance personnel, to hide or mask their true feelings. And the product owner may not even be aware that he or she is letting the other team members down.

Successful organizations recognize this dilemma and take action to break down the command-structure confusion. For some, titles and seniority get thrown out the window for the betterment of everyone. Highly successful organizations will take this one step further and ensure that FTE and contract team members clearly understand and embrace this mind-set. However, don't minimize the effort needed by your company in order to make this happen. This is not a "one-and-done" approach via a corporate e-mail message, employee onboarding, or an executive speech. This is a definitive commitment by the company to continually embrace, articulate, and reinforce empowerment for both teams and individuals. Make this commitment and you'll recognize immeasurable success. Fail to make this commitment, and your company will never achieve its full potential.

Initially, be careful if you decide to empower both the team and individuals on the team! At first you may be shocked at what really gets discussed during retrospective/review meetings. However, I would encourage you to let the shock set in and then let the noise die down. The end result will be the creation of a stellar team that may blow others away with its ability to deliver. I would also recommend that you make sure that there is more than one experienced facilitator for these sessions. An experienced ScrumMaster will help, but you'll be better served if there are other experienced facilitators there as well.

Oh . . . almost forgot . . . how does this happen? Simple: Talk to each other in person and discuss what's really going on in a positive and professional manner. In theory this is a very simple concept to understand. In practice, however, this is an enormous cultural undertaking that must be embraced by senior leaders within the organization. If the culture truly understands and applauds this approach, you will have a definitive advantage in the marketplace. However, don't be completely dismayed if the cultural aspect is not there. Your team can still create a positive atmosphere of open and honest dialogue, but it will have to come from within.

It goes without saying that projects and programs take on lives of their own. There are many reasons why a product owner — or anyone else on the team, for that matter — may go missing in action. Going MIA is actually natural as personal and professional circumstances evolve and change. Recognizing an MIA scenario isn't easy, but others on the team may see the signs well before you do. If either your organization or your team is willing to foster the right culture, you can avoid confusion, frustration, and deteriorating performance. The end result will be a highly effective team that can continually improve with forward momentum.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (2 ratings)


Really nice article. At times organizations do abuse role of a product owner. I have seen few agile teams where Product Owner is also a Scrum Master and also a Lead Developer.

Single Resource = Product Owner + Scrum Master + Lead Developer

Organizations feel proud to say that 'we are fully utilizing our resources, everybody is contributing technically'. But in real they face lot many problems and are not able to identify root cause because of their lack of awareness about Agile roles.
Kapil Dhawan, CSM,CSPO, 3/26/2013 5:33:01 AM
In my opinion, MIA is independent of the project management model but i agree that talk to each other in person is a good way to handle it. The earlier we detect it and more importantly acknowledge it, we can prevent it with leadership support.
TC Gill, CSM, 9/20/2014 9:40:17 AM
Thank you. An interesting article on something that can happen for many reasons. Its good to bring the situation of MIA into the open and discuss. After all its a huge impediment to the team, and potential success of the project.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up