Tag Archives: product owner
This is the second in a series of blogs about our upcoming textbook called Introduction to Agile Methods that I have written with Sondra Ashmore. The first blog spotlighted Roles and our second post was a guest blog by Sondra on Agile in Academics. I hope these blogs inspire you to want to read the whole book! Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan. The chapter spotlight for this post concerns Requirements and how they are approached very differently in Agile, as opposed to Waterfall. Within Agile, the terms around requirements include User Stories, Epics, Acceptance Criteria, Personas, Release Management and much more. The excerpt that I have chosen to share here addresses a particularly challenging aspect of managing requirements and priorities – Customer Specific Code Requests. First, here are the learning objectives for the chapter.
- Recognize the differences between Agile and Waterfall with regard to requirements gathering and documentation
- Understand the format used within Scrum for user stories, including epics and acceptance criteria
- Explore several examples of how user stories are broken down from epics to child user stories and how acceptance criteria add important details to the story
- Learn how the other methodologies differ from Scrum in their terminology and practices
- Examine how requirements can be enhanced by using personas or engaging User Experience (UX) designers to better understand potential system users
- Understand how user stories and Agile development efforts map into a marketplace driven by consumer demands and customer-specific development requests
- Value the importance of communication and transparency when it comes to requirement specifications and priorities
- Explore Lean software development and the Lean start-up concepts and how they influence the product development process
We are getting closer to the publication of the Agile textbook that I have co-authored with Sondra Ashmore. It is such an exciting time for us and I want to use this blog series to highlight chapters from the book. I hope you enjoy this so much that you want to order the book. Pre-orders are available on Amazon right now – just search Introduction to Agile Methods by Sondra Ashmore and Kristin Runyan.
One of the chapters that I was responsible for addresses the roles within Agile and specifically Scrum teams. Here are the chapter learning objectives as well as an excerpt from the section about Product Owners, something I am very passionate about.
- Understand the roles in Scrum with their specific responsibilities—product owner, Scrum master, and team
- Identify the attributes and personality types that are most successful in the various roles
- Learn the Agile definitions of “chickens” and “pigs”
- See how extended team members interact with the team
- Compare and contrast the roles in Scrum and the other methodologies
- Walk through practical examples of how the roles are filled in different-sized organizations
Product Ownership – Breadth
Another nuance of the product owner role is the breadth of his or her ownership. Does one product owner manage multiple products? Or is one product so big that it requires multiple product owners? Both of these situations are common in the workplace where teams are thin and expectations are high.
To examine the first instance, what are the advantages and disadvantages of having one product owner responsible for multiple products? The biggest risk factor is time and attention. Can the product owner devote adequate time to every product that he or she is responsible for? Does this person have the necessary depth of understanding to truly collaborate with IT on the best solutions? It is a risk, but certainly one that can be overcome.
In the instance where the product is large enough to have multiple product owners, there is a chance that the priorities will not align. Related to the previous reference of business value, if one product owner wants to expand to new cities to attract new users but another product owner places top priority on improving the processing speed, then you can run into conflicts. However, one of the core tenets of Agile is collaboration, which includes collaboration between product owners. Product owners need to be in communication with each other to clearly articulate the best plan for all groups—knowing that at any given time, one group’s needs will take precedence over another’s.
Even if you have a single product owner for every product, that does not mean that things are easy. Between systems there are interactions, and to create a new feature or make a modification, the product owner may need to consider dependencies.
Product Owners – like great products – must be developed. While some skills are innate, others must be learned and organizations tend to throw new Product Owners into the mix without adequate information. In this blog series, we have explored new product owners who are assigned to new products and those owning a system migration. Now we are going to explore a new product owner who takes over an existing product with a robust product backlog. In some respects, one might think this is the easiest of the three scenarios but it comes with its own set of challenges. Here are some tips for how to get started.
1. Get to know your customers
The first step to get your arms around an existing backlog is to understand your current customers. To do this, you need both
qualitative and quantitative information. Data is always your friend. How many customers do you have? Are they profitable? Are they the ideal customers that you want to attract? Once you understand the numbers, now you need to actually talk to customers. Schedule interviews with key customers – both happy ones and those that are frustrated. Use your strong product management skills by asking open ended questions. My favorite is “What keeps you up at night?” Let your customers talk or complaint or suggest – wherever the conversation goes can be valuable. Knowing who is buying your product is very important.
We have a problem with Product Owners in Agile. These are incredibly difficult jobs and it is easy to blame the product owner when things go wrong because “the requirements were not clearly articulated or prioritized.” That might be an easy path, but it often is neither correct nor fair. Instead of pointing fingers, let’s support our Product Owner and give them the training and tools that they need to be successful. Just like we introduced with developing New Products and explored with existing backlogs, here are some tips and tricks to managing system migrations.
Moving from old technology to new is a common project for Agile teams. Many companies have platforms that are no longer providing the necessary value and features to the marketplace and IT organizations are faced with the challenge of moving from an old, tired, inflexible system to a new, dynamic, configurable system. Or it might not be that dramatic – perhaps you just need to move from one software package to another for cost or vendor relationship reasons. Either way, a new product owner must discover how to break this big effort down into manageable chunks. How do you get started?
1. Analyze what is being used
The first step is to figure out what pieces of the legacy software are actually being used. There is no sense migrating functions or features that no longer matter to the organization. If you can weed out some portions of the migration to minimize the size of the effort, that is great news for the company. Some firms want to skip this analysis step and just build “like for like.” This approach will save time as part of the project prep, but it will cost precious developer time down the road.
Many of the complaints that I hear often about Agile implementations concern the product owner. Either the business is not engaged appropriately, or the product owner is indecisive or unavailable, or the quality of the requirements/user stories is poor. Whatever the situation, the product owner is often “at fault.”
Instead of lamenting why we do not have good product owners, I would like to shift our thinking to: How can we build a Product Owner? These are challenging jobs and often the people put in them have little background on what is expected of them. This is the first in a series of three blogs to help us build better product owners, which will lead to better products. First, let’s examine a new product offering. Where would a new product owner start?
For this effort, I recommend a three step process and I have to give credit to David Hussman who provided some of the inspiration for this topic.
1. Create personas
Who is going to use this new product? Who is your buyer? Will you have power users and casual users? Do you need to consider administrative users?
Personas first came into the conversation with Alan Cooper’s book “The Inmates are Running the Asylum” in 1999. Personas are fictitious people who are going to use the system so the Product Owner can think about user interactions and how best to optimize the experience. Let’s map out a few personas.
I went to a meeting last week and we were discussing how to measure a Product Owner. The concept is completely understandable, but there was something about the meeting that didn’t sit well with me so I am devoting this blog to trying articulate my concerns and things that I think need to be considered.
The premise is sound – how do you know if the Product Owner is leading you down the right path? What if you build the wrong thing? And how can you assess their mis-direction before precious time and resources are spent?
That is a 100% valid question and one that we should certainly spend time and thought to resolve. The idea that there are ratio-driven metrics to measure the PO’s performance, though, seems counter-productive.
First, I think Product Owners have a very difficult job and I think very few people are naturally great Product Owners, if you go by the broad definition. Product Owners are supposed to understand the market place, stay on top of the competition, interview current and prospective clients, and break down all of that data into meaningful features that will be delivered in order to drive the most business value. They are also supposed to be experts at writing user stories, adding acceptance criteria, understanding at least some level of the technical details associated with the application, and they need to be decisive, informed and immediately available for the Scrum Team. That is a tall order. In fact, I recommend splitting the Product Owner’s responsibilities between the Product Owner and a Product Manager, as I referenced in a previous blog.
This is an excerpt from the textbook that I am writing with a co-author on Agile. Here are examples of a strong and weak Product Owner. (Names are made-up so don’t think you know them 🙂
Would love to hear your thoughts and comments.
There are many examples of good and bad Product Owners in the workplace. These are challenging jobs with a number of conflicting inputs with regards to prioritization so it takes a strong personality with a collaborative work behavior to be successful.
Let’s look at Keith. He was assigned as the Product Owner to an application that had several high profile and demanding clients. Keith researched all of the necessary competitive and market information so he could ascertain the best prioritization for the development work that needed to be done. One Account Manager who handles one of the high profile clients didn’t like Keith’s prioritization because something that their client wanted was not at the top of the list. Keith was very deliberate in his analysis and he felt that the requested feature would not be adopted by others in the marketplace – it would really just apply to this one client almost as if it was custom code. Therefore, Keith put other features that he felt would drive more business value before the requested client feature. But that didn’t satisfy the Account Manager as she felt like her client’s request was vitally important. So she pleaded with Keith again and again. She called him and sent him e-mails and held meetings and just pestered Keith relentlessly to try and get him to change the prioritization. Finally, in a moment of frustration, Keith said “Fine. You go talk to the IT manager of the Development team. If she thinks they can get it done, then so be it.”
Keith was having a bad day and in that moment, was a very bad product owner. The Product Owner sets the priority for the work of the IT team based on their knowledge and research of the marketplace and what will drive the highest business value. Further, the Product Owner must collaborate with all of the constituents to “sell” the prioritization. The product owner must be collaborative and must hear input from a number of sources, including account management. So it was Keith’s decision as to whether or not the client request would be prioritized high on the list. His decision and his alone. By deferring to the IT Manager, he was shirking his responsibilities. He should have either convinced the account manager that his backlog was prioritized correctly by articulating the business value of the high priority items and clearly explaining to the account manager why their desired task did not have the same business value – or, if he couldn’t do that – then he should have reprioritized the backlog to move up the client’s task, based on the information learned from the account manager. Being a Product Owner is a difficult balancing act but the role is critical and must be performed well for Scrum to be effective.
By contrast, Sam is a great product owner. He actually moved his desk to sit with the Scrum team so he could be immediately available to answer questions of the team. Sam spent a portion of his time with the account managers, salespeople and actual customers so he could stay on top of how customers were using the product and what problems they were having. He also learned from the salespeople what objections they were hearing from prospective clients. He was able to distill all of that feedback into the user stories that he created and he understood which features would drive the most business value so he could effectively prioritize. Sam also listened to his Scrum team and understood enough about the technology to contribute to the discussion around various choices that could be made to solve a particular problem. The best product owners have enough technical expertise to be able to follow a technical conversation and contribute salient points to the discussion. Product Owners do not have to be developers by any means but they should demonstrate a technical aptitude.