Saturday, April 7, 2012

Product Owners can Prioritize their Stakeholders

The product owner role is a critical to the success of an agile team.  Scott Ambler describes the product owner role as a Stakeholder Proxy for Agile Teams. "The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team." Scott Ambler further illustrates this with the following image:
Scott Ambler's Role of Product Owner image
Scott Ambler's Role of Product Owner

If you are a Product Owner and you struggle to partner effectively with the various stakeholders in your company or organization, rest assured that you are NOT alone. Depending on the product you responsible for and size of your organization you may have numerous stakeholders and need to develop ways to coordinate among so many people. We all have limited time, so we need to determine how to invest your it most effectively to deliver value. In traditional project management, a suggested technique is to prioritize stakeholders based on their influence and interest so you can identify who you want to manage closely, keep satisfied, keep informed, and monitor with minimum effort.

The problem with this approach is that it is a power grid and emphasizes a stakeholder's influence, instead of knowledge or value, that a stakeholder can provide to a product owner and agile team.   It positions the stakeholder as a power broker that the team serves, rather than a partner who works with it the team.  

I like the concept of a simple matrix for prioritizing stakeholders, however, I choose not to use the power or influence of the stakeholder as an axis.  Instead, I modify the grid to focus on the value the stakeholders can provide the team.  I define value as knowledge that can take many forms.  It could be domain expertise, understanding of customer needs, business acumen, technical know-how, and the list goes on.   
My form of the stakeholder prioritization matrix looks like this:

  • High Knowledge / High Interest = Stakeholders that you partner closely with
    These are the stakeholders require little effort to involve and willingly work with the team.  As a product owner, I identify touch points (development / updates to product roadmap, prior / following release planning, during backlog grooming sessions) to keep these stakeholders in the loop and often seek their counsel.  
  • High Knowledge / Low Interest =  Stakeholders that you consult with (and try to move to high interest category)
    These are stakeholders that you want to involve but they are either too busy, or may not (yet) see the value to them helping the team.  I seek to convert these stakeholders to willing partners (i.e., high interest) by .   I seek  
  • Low Knowledge / High Interest = Stakeholders who you keep informed
    Agile teams believe in transparency.  I believe demos should and any communication of team progress should be made available to anyone who is interested.  You may discover that one of these stakeholders deep knowledge in an area that you were unaware of.
  • Low Knowledge / Low Interest = Stakeholders who have an open door in get more involvedThese stakeholders are welcome to attend demos or express interest in becoming more informed, but I don't go out of my way to involve them.

If you have a number of stakeholders and find it difficult to keep up, this technique might help you prioritize your efforts accordingly.  While this post is geard at Agile product Owners, it is useful to others who work with Stakeholders on a diaily basis.  

Thursday, April 5, 2012

Example Working Agreement

When a new team forms, it is important from them to consider how they want to work together.  A technique for developing a shared understanding is to have the team co-create a working agreement.  There are many ways to approach this exercise, but it is important that each member have an opportunity to share what they feel will enable the team to be effective and happy working together.  Esther Derby  describes working agreements as "focused on amplifying desired patterns of behavior" and "aimed at helping the team achieve their task and team-work goals." in her post: Norms, Values, Working Agreements, Simple Rules.   Working agreements help teams surface shared values and address what could be issues before they happen.   

A working agreement is an artifact that should be shared publicly and referred to by the team.  It is not a static document.  It should be updated periodically, perhaps during retrospectives. The following is an example working agreement that evolved with a team that I am working with.  I share the following as an  example of what one team came up with.  It is not a template.  I believe working agreements need to be developed together as a team, as they should be tailored to the specific dynamics and needs of a team, and are likely influenced by the culture of the company..   

Sample Working Agreement


  • Product Owner is responsive to team requests for information
  • Team will close higher priority stories first.  To do so, we limit the number of stories in progress at any one time.  NOTE: Rule of thumb is to put as many people on the highest priority story that is still efficient.
  • Team members use information radiators (sprint burndown) to help determine whether we're on track with commitment.
  • All agile ceremonies are time boxed. This means that they start on time and end on time. To maximize the effectiveness of these ceremonies team members show up on time and are committed to being completely focused and dedicated to the task at hand.
  • We use the retrospective to continually inspect, adapt, and therefore improve our work together.
  • Core hours are established between 11:00am and 4:00pm where no non-agile meetings with Team members maybe set up. Informal conversations between team members are ALWAYS fine. 


  • We believe in in the value of planning collectively as a team 
  • Product Owner respects teams estimates coming out of release planning / sprint planning
  • Product Owner keeps the backlog up to date. 
  • Team contributes to product backlog in advance of planning sessions.

During Sprint

  • Team members attend daily scrum at 9:30am
  • Should a team member have a conflict, s/he updates the board in advance of the meeting and sends an email with updates for the team. 
  • Task board is updated during daily stand up meeting so team members can refer to the specific tasks they are working on or completed.
  • Team members may add new tasks any time.
  • Communicate impediments to Scrum Master such as dependencies, issues, waiting, and so on
  • Stories completed to Definition of Done and Product Owner agrees acceptance criteria of story is met.

 NOTE: The above is printed on 11x17 paper, posted in the team room, and signed by all team members.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.