Breaking Bad Story Point Anti-Patterns

There is occasional controversy in the Agile coaching community on whether to apply Story Points on user stories. This often stems from the challenge where some think that story points are a direct replacement for estimation and an expectation of precision while others suggest that instead of story point sizing, we should focus on focusing on small pieces of work. In other words, when applying a practice (e.g., story points), a bad pattern is implemented which is opposed to the way practice is meant to be applied. This is known as an anti-pattern. Anti-patterns lead to results that are counterproductive to the intent of the practice and reduce their effectiveness. In other words, not good. 

What is Story Point Sizing? 

Before we go further, let’s take a moment to define what is a story point? A story point is a unit of measure describing the size, complexity, and risk to gauge the amount of work needed to complete a particular user story. 

Story points are also a relative measure to a specific team. Every team creates their own story point sizing framework based on the type of work they do, the skills and experience of the team, and what they personally perceive to be a small, medium, or large amount of work. The team collaboratively determines the story points for each story based on its perceived size, complexity, and risk. 

Story points are often correlated with small, medium, and large sized work. Some use the Fibonacci as it provides a numeric distribution that can be used to differentiate between sizes of work typically using 1, 2, 3, 5, 8, 13, 21. When using Fibonacci numbers, 1, 2, and 3 are aligned with small work, 5 and 8 are medium sized work, and 13 and 21 denote large pieces of work. 

Velocity is a metric that can help a team understand their sustainable pace by identifying the amount of story points of work a team can complete in an iteration. In each case (e.g., story points and velocity), this is why you should not compare the story point velocity across different teams. Story points and velocity are very specifically a team measure and should not be tampered with by those outside of the team. 

Anti-patterns of applying Story Points 

The reason there is concern surrounding applying story points is the ways it gets applied. As mentioned, story points are a combination of size, complexity, and risk of that specific piece of work (aka., user story). This means they are not meant to be used as a predictor or for accuracy. Here are several anti-patterns of story points in the way they get applied: 

• Hours-Days Effort anti-pattern - Some apply story point sizing as if it is nothing more than an estimated effort of hours and days. There is often a direct translation of number of hours and/or days and forget (or ignore) the complexity, risk, and uncertainty in the work.  
• Pretend Certainty anti-pattern - There is often ascribed a sense of certainty when applying story point sizing where it gets used to predict when work will get done. At best, it can help with understanding progress, but you would never estimate “all” of the work up front anyway as priorities (and requirements) tend to shift so it would be a waste to do so. 
• Pretend Precision anti-pattern – There is precision when using story points which isn’t appropriate. The numbers that story points represent are meant to be ball-park numbers as it is an amalgamation of size, complexity, and risk. 
• Contrived Comparison anti-pattern – Some organizations attempt to compare story points and velocity across teams even though they are relative to the team’s composition and the type of work they focus on. This is inappropriate and decreases the integrity of story points and velocity. 
• Effort Tampering anti-pattern – This occurs when someone outside of the team (usually management) attempts to influence the amount a work a team does by insisting on improvement. This impacts the integrity of the story point sizing framework and the velocity data as those are meant specifically for that team to have meaning. 
• Inflation anti-pattern – This can be the result of when someone outside of the team applies the Effort Tampering anti-pattern by attempts to make the team “work harder”. The result may be that the team inflates their numbers to ‘satisfy’ the influencer and effectively impact the integrity of the story point sizing framework. 
• Productivity anti-pattern – This is when story points and velocity get conflated as a productivity measure by those outside of the team. They are not productivity measures and will warp the intent of both story points and velocity. 

Mending Anti-Patterns  

The best way to eliminate or reduce anti-patterns, is to first understand what anti-patterns look like (see Anti-Pattern section above and search of other information on anti-patterns). Then do detective work to uncover what anti-patterns may exist. Follow this with determining an action to remove or eliminate them. You can do this through a theme-based retrospective where the focus is on identifying anti-patterns. 

Anti-patterns within an organization are more commonplace than you think. They are often due to a lack of clarity of what are story points, how they should be applied, and a lack of awareness that they are specifically a team-based measure. There may also be management or team member influence to use the practice or technique incorrectly. If too many of these anti-patterns exist, then the value of using story points as a team measure and as an instructive tool to help team gauge what is considered small diminishes.

Can your Desk become your Kanban Board? Yes, it Kanban!

Once upon a time, I found I had little space in the office to organize my work.  With the more recent office hoteling policies, while there is more flexible space, there is less of one’s own personal space.  I wanted a place where every morning I can quickly visualize my work for the day ahead. While there are online tools that I can use, I wanted something more tactile.  What I did have was a desktop surface.  I did have post-its, and sharpies.  I decided to experiment with Kanban on a physical desktop. 

As an Agile Coach, I work in iterations and increments much like I educate and coach teams and organizations.  It allows me to listen to what my customers want and prioritize the work based on value, much like a Product Owner should do. With this in mind, I used my simple tools to craft a kanban board on my desk.

Before I go any further, allow me to provide you with a brief description of what is a kanban board.  It is a work board that helps you visualize both the work and the flow of that work. It helps you optimize the flow of your work by understanding your WIP (work in progress) limit. In its physical form, it is usually shaped by a few state transitions as columns, the most basic include ‘To Do”, “Doing”, and “Done”. My work card (where I write the activity) was written in canonical form and I added when the task was written and then when I completed the work on the card, the “done” date so I could understand my flow.

I took the initial discovery activities that my client (aka., customer) and I agreed to, wrote them onto post-its with my sharpie, and added them to the kanban board in priority order based on both value and order dependency.  As I completed some of the discovery tasks, I added new tasks from my customers to the “To Do” column and reprioritized on a regular basis.  I experimented with keeping my WIP limit to about 3 activities in “Doing” at a time.

What I liked about this kanban experiment was that each morning when I got to my desk, I had my work right in front of me.  This immediately reminded me of my work for the day. It was very easy to maintain as it only took some post-its and markers to update the board. Every morning I checked the work that was in “Doing” so I knew what I had to get done for the day. I also enacted a quick reprioritization of the work so I knew what to pull from the “To Do” column when I had available WIP.  I managed to get a lot of work done this way. 

I’d say the experiment was a success.  What did I learn? That it is too easy to add more activities into “Doing” adding to WIP. This had the unfortunate result of slowing my throughput. What else did I learn?  That yes I kanban!

Top 5 ways to adapt your Agile Enterprise for a better Year ahead!

A New Year is upon us!  What is in store for 2018?  Better yet, what changes might you apply for a better Agile transformation and better business outcomes?  Here are a few to consider.

1) Focus more (much more) on the Agile mindset and the Agile values and principles.  Without this, people aren’t quite sure whey they are implementing the Agile mechanics (practices and tools).  Ask your employees if they know why they are applying the Agile methods and practices.  If they don’t really know, more strongly relate them to the Agile values and principles. 

2) Place Coaches high enough in to make a difference.  Placing them too low in an organization will give them little or no influence to change anything that matters.  Gauge your current placement of Agile Coaches and determine if they have the right access and influence to leadership.

3) Ensure leaders in your organization are educated in Agile.  Provide a combination of the Agile values and principles and Agile concepts, mindset, and practices that will help them support and lead an Agile transformation.  This includes understanding and establishing a high performing Agile workplace.

4) Focus on the employee side of Agile and what it takes to build a high performing team.  This includes establishing psychological safety, demonstrating servant leadership, creating a culture of self-organizing teams and even self-management, introducing continuous peer-to-peer feedback loops, and more. 

5) Become totally customer-value driven. Stop doing Agile for Agile’s sake and focus on the customer benefits.  Bring a customer mindset to Agile.  This means more closely identify with your customers (e.g., personas) and capture and apply more customer feedback along the way. 

I will go so far to say if you don't do anything else this year but these, you will have a stronger Agile enterprise that brings you more aligned with building high value products and services.  Give them a try!

Learn more by reading The Agile Enterprise.   

Psychological Safety leads to High-Performing Agile Teams

There are two types of safety that factor into a healthy and productive enterprise environment and high-performing teams.  The first is physical safety. This is where employees have an environment where they are free from physical hazards and can focus on the work at hand. This type of safety should be part of the standard workplace promoted by company and government regulations.

The second is psychological safety that is core to enterprise effectiveness. According to Google research, high performing teams always display psychological safety.  This phenomenon has two aspects.  The first is where there is a shared belief that the team is safe to take interpersonal risks and be vulnerable in front of each other.  The second is how this type of safety along with increased accountability leads to increased employee productivity and ergo high-performing teams. 

Psychological safety helps establish Agile in that it promotes a safe space for employees to share their ideas, discuss options, take methodical risks, and become productive.  An Agile mindset promotes self-organizing teams around the work, taking ownership and accountability, and creating an environment for learning what is customer value through the discovery mindset, divergent thinking, and feedback loops. Agile with psychological safety can be a powerful pairing toward high-performing teams.   

However, accountability without psychological safety, leads to great anxiety.  This is why there is a need to move away from a negative mindset when results aren’t positive or new ideas are seen as different. If this occurs, employees are less willing to share ideas and take risks.  Instead consider ways to build psychological safety paired with team ownership and accountability of the work. This can lead to high performing teams. 

Everyone has a role to play in establishing a psychologically safe environment.  Agile Coaches and ScrumMasters can help you evolve to an enterprise where psychological safety and accountability are paired. Leadership has a strong role to play to provide awareness of the importance of a safe environment, provide education on this topic, and build positive patterns in the way they respond to results of risk taking by teams.  Team members must adopt an open, divergent, and positive mindset that is focused on accepting differences and coaching each other for better business outcomes.  Employees at all levels must be aware of the attitudes and mindset they bring.   

What Colors are on your Agile Career Palette?

For those that advocate for Agile within their organization or help organizations adopt Agile, often times your career path is opportunistic based on what opportunities appear before you. This helps the Agile advocate at one level gain experience but can prevent the more methodical thinking of where you want your career to go.  At some point, isn’t it good to be in the driver’s seat of your own growth? 

For example, if the Agile advocate (e.g., Agile Coach) only has team level coaching opportunities, they will never gain the experience and skills needed to coach at a management or organization level.  If the Agile advocate only has Scrum based opportunities, they will not gain the experience of working with Kanban, Lean Development, or scaled frameworks.  Instead a methodical aspect to their career must be incorporated.  This is where the Agile Career Palette can be useful.  

The Agile Career Palette provides a colorful approach to better understand what Agile capabilities and experience an Agile advocate currently has and then provides an incremental approach to explore, learn, experience opportunities in the future based on gaps and interest. An Agile Career Palette provides the Agile advocate with what is artistically known as the colors they bring to their work.

These colors represent several key facets (IMHO) of what it means to be an Agile advocate of any type.  The key facets include the agile experience acquired, levels coached, agile roles played, fields where you apply agile, agile processes implemented, business and technical practices applied, agile training delivered, agile change management and soft skills applied, agile certifications acquired, and giving back to the agile community in the form of articles and seminars.  While there may be other areas of focus, I have found that these tend to cover most of the important Agile areas. 

Those who benefit most from the Agile Coaching Palette are the Agile advocates who play a role as Agile Coach, Agile Champion, Agile Sponsor, Team level advocates (e.g., ScrumMasters, Product Owner, etc), and Agile leaders of any kind who are looking to advance in their Agile journey. The Palette approach reminds those on their agile journey of the many areas they may desire to experience, learn, and play along the way.

Based on real experience, the Agile Career Palette is a methodical and incremental approach in helping you consider what you may want to do next, depending on where you’ve been and more importantly where you would like to go.  The “where you would like to go” is meant to be applied in an incremental manner.  Usually about 6 months gives you enough time to make progress but short enough to reflect on where you’ve been and where they want to go next.  

If you are an Agile advocate, consider trying an Agile Career Palette approach to help you better shape and color your future.  First start by establishing your current state of the key facets mentioned about.  Then, commit to an increment of improvement based on your interests or gaps.  It will help you be more laser-focused on building your future!

You may be FrAgile if...

Moving to the Agile can be challenging.  It implies a behavioral change to the Agile mindset supported by the Agile Principles found in the Agile Manifesto. However,  many find themselves in the land of FrAgile (i.e., fake Agile), Scrumbut (i.e., we are doing Scrum but not some of the practices), Scrumfall (i.e., some elements of scrum within a waterfall lifecycle), and even Kantban (i.e., Kanban without respecting the queues). 

What is FrAgile? This is where there either isn't really a commitment to go Agile, there isn't an understanding of what "being Agile" means, there isn't the talent like an Agile Coach to help bring about that change, or an incremental deployment approach stalls along the way. And most importantly, frAgile is when Agile very quickly becomes brittle, lacking in vigor, and shatters once there is tension applied leading to a regression to past ways of working.    

When "Fragile" happens...

Some may ask, “why do I care if Agile is not quite right”.  When a form of Fragile is applied, you will not gain the business benefits of aligning better with customer value and the many other benefits Agile can bring. When you see that you are not gaining the business benefits of Agile, instead of blaming Agile, look to see how you have implemented Agile and whether you are really aligning with its values and principles. 

In honor of Jeff Foxworthy and his "You might be a Redneck if" routine, I thought I would adapt his saying to fit the Agile message of this article.  I present several areas which can be problematic if they are not in place and you are serious about Agile.  So without further ado, "You may be FrAgile if": 

• ...you do not want to hire or identify a Product Owner (or similar) who works with both the customers to gather requirements and Engineering team to describe the requirements in more detail.  The result is that there engineering will build what they think the customer wants and then you will wonder why the customer doesn't want it.  
• ...you continue to have the Project Manager or Functional Manager assign the work to the Team.  The result is that your team will not be self-organizing and you will wonder why your team members are not engaged.  
• ...you continue to collect your requirements upfront and lock them in for the remainder of the project.  The result is that you may build the wrong thing for the customer and you will wonder why the customers are not very excited about the release and few are buying or upgrading to it. 
• ...you do not want to have a healthy balance of test/QA minded folks on the team.  The result is that the testing activities will become the bottleneck or worse yet, the testing aspects will become watered down (i.e., skip testing steps), ergo releasing a product with low quality and subject to many defects.  
• ...you mechanically know how to do the Scrum and XP events and practices but can't remember any of the Agile values nor any of the 12 Agile principles.  

Let me know what you think about the results of "You may be FrAgile if".  If you believe there are other Fragile, Scrumbut, Scrumfall, Kantban, and other related Agile challenges that could be non-starters or significantly impact the ability to "be Agile", please feel free to share.     

Benefits of Agile Coaches for your Agile Transformation

Many companies begin their introduction to Agile by trying it on a project or two.  If they believe they have ‘enough’ success with Agile, then typically more projects deploy Agile.  The challenge is that at some point the company is unclear on what level of Agile deployment has occurred and what type of Agile is really being adopted.  Senior Management may hear things like “we are Agile” and not really sure what that means.  Worse yet, because of the inconsistency of understanding Agile, some teams will say things like, “we don’t need to document anything because we are Agile”, other teams will say “we don’t need any management support because we are self-organized”, while others will say “we can’t tell you what we’re building until the end of the project because we are using Agile”.  Now what do you do? 

This becomes even more challenging when the company begins to realize the amount of effort they are haphazardly spending on Agile adoption.  Sometimes the company learns that they are spending twice for the same thing like training and/or tools and often overspending because they are not leveraging the volume discount strength of the whole company.  This is particularly relevant to medium and large companies.  

Whether you realize it or not, when you have multiple teams heading in roughly the same Agile direction, you have already embarked on an Agile transformation.  So the question is, do you want to let the change occur in an unorganized and ad hoc manner or do you want to manage that change in an organized way and gleam the most benefit from the effort.

I do not believe there should be a prescriptive way to deploy Agile.  However, there needs to be some way to ensure the teams are working on the highest customer value work. An enterprise level approach can help.  This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures all teams are building the highest customer value work.      

When you find yourself in the situation where there are many in your company wanting to adopt a certain tool, process, method, and/or culture, or if it is already happening in an ad-hoc manner, it is highly recommended to initiate an organized approach to the enterprise change.  In Michael Spayd’s “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale”, he recommends that an “effective Change team” is established.  In my experience, seasoned Agile Coaches and/or an Agile enterprise leadership team provides significant leadership for the change effort.  The Agile Coaches/Agile leadership team (aka, change team) provides the framework for the enterprise but still allows for adaptability and decision-points by the teams so they feel ownership of their working process.

The Agile enterprise leadership team should include talent that has experience in Agile enterprise change such as seasoned Agile Coaches and those who have organizational level change experience.  Some members can be matrix-ed in from internal organizations.  They should function as a team and can be distributed according to the areas within the organization that they will support.   It is often best to bring in either full-time regular talent or external long-term consultants to ensure that they don’t just make recommendations, but live through the challenges of the change as they help product teams, senior management, and others.

What are some of the benefits of Agile coaches and/or Agile enterprise leadership team?  This leadership can help you establish and manage the following: 

• Agile Vision - create a vision for where you can go.  A strong Agile coach has been to where you want to go. Without this experience, a company may never get there.  This may include a focus on the Customer to build the right thing and on the Employees to build the thing right" or similar.  By having a central Agile leadership team to focus you, you can better gain buy-in or at least get folks to understand why you are going in this direction.   
• Agile Transformation Roadmap - identify common activities to help a product team come up to speed with Agile.  This includes establishing a set of “ready for deployment” materials to help teams get ready for the change to Agile.  By having Agile Coaches help you, it will save time and effort from each product team having to figure out the adoption activities themselves
• Agile framework and practices - collaboratively establish an adaptable set of Agile methods and practices with the rest of the organization.  By having central Agile leadership coordinate this, it will save time and effort from each product team having to establish Agile methods and practices, although they will need to tailor them for their specific team. 
• Agile terminology – establish a common working language for Agile so that members from across the organization can communicate and interact effectively with each other.  By having central Agile leadership establish this, this reduces the miscommunication issues that will arise across the organization regarding various and sundry definitions of Agile terminology.   
• Agile training – establish a common set of Agile Training aimed at various levels of the organization (e.g., Scrum Team, Scrum Masters,  Product Owner, Middle Mgt, Senior Mgt).  By using a managed training deployment approach via the central Agile leadership team and education group, we will have consistent training and can get a better understanding of who has and hasn’t been trained.  By providing an in-house training approach, this reduces the cost of utilizing multiple vendors.  This increases common Agile understanding across the organization and product teams.
• Agile Communities – establish a common organizational Agile website with links to internal and external Agile communities.  Having the central Agile leadership team establish and support this, ensure that there is a managed approached to sharing online Agile related information and resources (framework, practices, etc.) across the company site that is kept up-to-date.    
• Agile Coaching - A key aspect of the leadership team is to provide Agile Coaching via the Agile leadership team to projects/product teams across the enterprise.  They may start with a small core of dedicated Agile Coaches and then can leverage existing Agile talent across the enterprise in establishing an Agile Coaching Circle.  Coaching significantly reduces the effort involved with “correctly” getting a team to adopt Agile and more importantly ensures they do not regress into their old traditional habits. 
• Agile Adoption measures – establish a common and reasonable set of adoption measures to see what progress is being made in the Agile adoption within the company.  By having the Agile leadership team manage this, we have common adoption measures to ensure that the leadership team and product teams are meeting the organization objectives for Agile adoption.  Senior management can more readily get a pulse of the Agile status across the organization.
• Agile Challenges Point of Contact (PoC) – establish a central point to manage Agile related challenges and issues.  This would include website, email PoC and the establishment of an Agile FAQ.  The benefit to having a go-to centralized Agile leadership team to manage this is that they can both become aware of these issues and then resolve the issues and challenges before they cause an impact.
• Agile Vendor Liaison PoC – utilize the Agile leadership team to become the PoC for managing the company relationships with the various Agile vendors.  By using a central Agile leadership team ensures that the organization or company is gaining the most leverage from the volume discounts and negotiations for Agile related materials and tools.  

Finally, when employees within a company see that many are going Agile, sometimes it is comforting to see that the organization is providing support in the adoption effort.  It is even more comforting when those employees that haven’t yet gone Agile see that there is ready support for their deployment.   It is particularly problematic when the employees are seeing wide variations of “agile” being deployed some of which is not really Agile, and they wonder when the organization may provide some guidance in this matter.  Introducing Agile really is a culture shift.  If you are thinking about adopting it or already are, then it can be a benefit to have Agile Coaches and/or a centralized Agile leadership team to help you navigate to a success adoption of Agile.  

Good luck on your Agile adventure!

Note: this was originally written in 2008 with minor updates in 2012.    

Size Matters – using “size” instead of “estimate” on Agile projects

When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.

When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.

With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).

It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.

So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…

Who makes the Best Product Owner?

In one of my recent articles entitled Who makes the best ScrumMaster?, I discussed the attributes needed to make an effective ScrumMaster and what traditional roles may play the ScrumMaster best. From the feedback, those who can best exemplify the attributes of a ScrumMaster made the best ScrumMaster and it did not appear to be strongly aligned with any particular traditional role.

In this article, the focus is the Product Owner role. Much like the ScrumMaster, the Product Owner role is very important to a successfully running Agile team. In fact as teams consider adopting Agile, who plays the Product Owner is critical to gaining the benefits of Agile due to the importance of identifying customer value and enacting the customer validation activities to ensure we are building something that the customer actually wants.

What are some important attributes of an effective Product Owner? A Product Owner recognizes what customers want and translates their needs into meaningful epics and user stories (aka, requirements). A Product Owner must intuitively adapt requirements (aka, user stories) when customer needs and market conditions change, to ensure what is built and delivered aligns with customer needs. This may sound obvious but the Product Owner must have the wherewithal to ensure that the organization in which the team works in will positively support and welcome change. A Product Owner must have the attributes to be a good voice-of-the-customer (VoC) and communicate the customer needs to the Team so they can build what the customer needs. It can be quite challenging to commit time to customers and team members.  Some attributes that an effective Product Owner must have include:

• Parsing customer and business problems and turn them into meaningful user stories  
• Working with sales and marketing to get their ideas into the backlog
• Establishing a directional Product Roadmap and Product Strategy
• Understanding the business marketplace
• Understanding and interacting with the customer domain 
• Establishing effective Customer validation (e.g., end-of-sprint reviews/demos, alphas, etc.) to ensure you are building a product the customer wants   
• Understanding that it takes a trusting environment where problems can be raised without fear of blame, retribution, or judgement, with an emphasis of healing, collaboration, and problem solving  
• Facilitating and influencing the work without coercion, assigning, or dictating

So the question arises, is there a traditional role that plays the Product Owner the best? Let’s examine a few of these roles.

Business Analyst as Product Owner?

What does a traditional Business Analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders in order to understand their needs, and to recommend solutions that meets these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. They also act as a liaison between business and technical groups. It is because of the work a Business Analyst already does and in particular their focus on requirements and their liaison role between the business and technical groups that makes them a good candidate for the Product Owner role. A traditional BA would have to gain the experience in working in an Agile manner including the continuous requirements elicitation process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Product Manager as Product Owner?

What does a traditional Product Manager (PM) do? A PM examines the market, the competition, and customer needs and establishes the product direction that is considered valuable to the market and the customers therein. A good PM focuses on the financial considerations including the return on investment (ROI). In addition, the PM is involved in the requirements gathering and management process. It is because of the work a Product Manager already does particularly their focus on what is considered valuable by the customer that makes them a good candidate for the Product Owner role. A traditional PM may not have the experience in working in an Agile manner including a continuous requirements gathering process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Project Manager as Product Owner?

What does a traditional Project Manager (PjM) do? The primary responsibility of a Project Manager is to plan and execute a project from the beginning to closure. A PjM focuses on the project costs, schedule, and scope. A PjM may also help build the project objectives, help manage the requirements management process, manage project risks, issues, and dependencies. While there are some attributes a PjM brings that can help in the Product Owner role, there is very little direct customer focus which is a big part of the Product Owner role so this experience would have to be gained. A PjM may have to unlearn some "assigning work" and "driving the work" as this can inhibit the team's ability to become self-organizing.

Technical Manager as Product Owner?

I have found that some Technical Managers (TM) provide aspects of product ownership to their work. The Technical Manager may get input from Product Managers, Sales, and Marketing and then crafts them into meaningful customer needs.  While there are some attributes a TM brings that can help in the Product Owner role such as crafting a product or service direction, there may be little direct customer focus which is a big part of the Product Owner role. This experience would have to be gained. In addition, a TM will need to break from the "team are my direct reports" mindset and "assigning the work" as this can inhibit the ability for the team to become self-organizing.

Other Roles as Product Owner?
There are other roles that may be considered.  A select example are those in the marketing space (e.g., Market Researcher), service space (e.g., Service Consultant), user or customer experience space (e.g., UX Designer), and entrepreneurs. These are roles that understand the market, customers, and the continuous feedback from the customer.  As organizations have various roles in this capacity, it is worth investigating those current roles that are customer facing and understand how to translate feedback and strategy into user stories. 

Summary

IMHO, those who have played either a Business Analyst or Product Manager can become an effective Product Owner. However, anyone who has played a role where they work with customers to collect their needs and then work with teams to build products or solutions that meet those needs can evolve into an effective Product Owner. I would suggest that anyone who becomes a Product Owner (or is interested in doing so) should consider taking Agile Product Owner education, reading related books, and/or gaining guidance in this area through an Agile Coach in order to help them better understand this role and the activities they will need to perform in order to play this role effectively.

Robust Agile Organization - Core Roles and Beyond!

To establish to a fully robust Agile enterprise, it is important for everyone to play a role in Agile. I have found that being successful from an Agile perspective requires "core" roles and but must include the "across the enterprise" roles to ensure success.  Let's focus on each of these areas.

Core   

The core roles provide the nucleus for building customer value.  This starts with the Development Team. I prefer to use the term Agile Team (or something similar) since I want to ensure folks understand that it is not just development-centric but includes other key cross-functional roles and disciplines.  This cross-functional team is made up of around 7-9 members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), UX, DB, tech writers, and CM/build talent. The key is to ensure you have all of the roles you need to build an idea with sufficient skills to get the job done. You may also need a Product Architect which is a role that may not be considered full-time because they can support more than one team related to an idea.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the team.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team on Agile processes and practices, and helps them apply those practices. The Scrum Master takes the responsibility of a team coach ensuring the team stays true to the Agile values and principles as articulated in the Agile Manifesto including applying self-organization around the work. The Scrum Master helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, Daily Stand-ups, Retrospectives, and the Agile Release Planning session. Learn more about the Scrum Master in the Who makes the Best Scrum Master article.

Equally important is the role of Product Owner (PO), the driver of customer value. This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the customer into the picture to validate that what the team is building is something that the customer actually wants.  Learn more about the PO in the Who makes the Best PO article.

The final core role that is often forgotten in many Agile environments is the Customer.  The customer is core to determining what is value.  With the customer, you are not really enacting Agile. The customer is where many of the ideas of value come from.  The customer provides the valuable feedback along the way that validates (or adapts) what is considered value.  The customer may be in the form of multiple personas depending on their motivations and pain points. 

Across the Enterprise (aka, Beyond) 

If this is your first foray into the Agile space or you want advance in your state of Agile, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily revert back to old traditional habits. The Agile Coach understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

We then turn to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove roadblocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.  Learn more about Agile and middle management by visiting the Agile and Middle Management article.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).  Learn more about Agile and the Executive role by visiting the Agile Executives Playbook article.

Then we bring in roles like Sales and Marketing, Finance, and HR. These roles should adapt toward the same concepts of agile leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement.

Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable.  Finance and Portfolio should adapt to a continuous budgeting approach where ideas are continuously added to an enterprise kanban prioritized by value instead of fixing the work at the beginning of an annual budgeting process. You can learn more in the book Beyond Budgeting. 

If performance objectives are part of the organizational processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.  HR can also help the enterprise move from an annual performance review to continuous review and feedback. Learn more about this in the Agile is creating a new horizon for HR article. 

If an idea or product is made up of more than one Agile Team (e.g., for a team of twenty you would want to break them into three teams of around 7), then there may be a need for an Agile Project Manager (APM) to help manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  They may support a Scrum of Scrums (SoS) or similar.  The APM also handles the interaction with the business governance of the organization.  If your organization is large, you will need an Agile Portfolio Management Leader or team.  This leader focuses on providing visibility to the highest value work so that the organization (and teams therein) are building the highest value work to the customer.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

----------------------------------------------------------------

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf