Robbin Schuurman

The Product Owner role is implemented in organizations in various different ways. The responsibilities and authorities of Product Owners vary across organizations, departments, teams and Product Owners. This can be explained to some extend, because it is a role that people need to grow into. The role requires some specific competences and a specific mindset. In addition, for many organizations it is a new and unknown role in which people (typically management) are trying to find the right balance of responsibilities and mandate. Preferably, a Product Owner has a lot of mandate and he or she is the final decision maker for the product. In many organizations this is not (yet) the case however. In order to create clarity about the level of Product Ownership in your organization, we distinguish five types of Product Owners: The Scribe The Proxy The Business Representative The Sponsor The Entrepreneur The figure shows these different types of Product Owners visually. In this figure you'll see the expected benefits that can be achieved, based on the authorities (or maturity) of the Product Owner. A 'Scribe' therefore has few responsibilities and authorities, an 'Entrepreneur' has many responsibilities and authorities. The image shows the growth path of the Product Owner as we often see it at organizations. Product Owners grow in their authorities and herewith, the added value of their role increases for the product, organization and customers. Having more mature Product Owners will enable organizations to experience more benefits of applying Scrum and value delivery will typically increase for the better. In the following paragraphs the different types of Product Owners are explained in more detail, and we will discuss how you as a Product Owner can take a step in the authorities that you have. The Scribe We often find the Scribe Product Owner role in organizations that are just starting out with Scrum, and/or in organizations that have not completely embraced the Agile mindset (and therefore do not apply Scrum properly). These organizations see the Product Owner primarily as someone who administers the Product Backlog, collects the wishes from the stakeholders and translates them into User Stories for the Development Team. This type of Product Owner often has none to very limited authorities. This Product Owner mainly ensures that the wishes of the stakeholders are written out in understandable language for the Development Team. In organizations where this type of Product Owner is very common, Business Analists or Requirements Engineers are often appointed as Product Owner. In such situations, the mandate often lies with someone else, such as a steering committee or a Project Management Office (PMO). The Proxy Just like the Scribe Product Owner, we often see the Proxy Product Owner (in short: Proxy) in organizations that are in a starting phase with an Agile way-of-working and in adopting the Scrum Framework. The Proxy has some more authorities than the Scribe has. The Proxy, for example, also often gets the authority to make (limited) choices in the ordering of the Product Backlog. However, the vision, the business goals, the desired outcomes/results and the scope is still being determined by other people, such as a steering committee, project sponsor or business owner. In many organizations we encounter Proxy Product Owners who used to be in the position of project manager or teamlead. These roles or positions typically already have the responsibility of bringing a project to a successful end. Therefore, it seems logical to many organizations to change these peoples' roles to 'Product Owner'. However, these Proxy Product Owners are not the final decision-makers. They typically have to ask for approval when changes happen. They have to ask for approval to change priorities. And they have to ask for approval when they want to change the planning, roadmap and Product Backlog. The Business Representative The next type of Product Owner is the Business Representative. The Business Representative is typically a representative from the business side of the organization, who knows the business context, market, customers and users well. Therefore, this person typically knows from experience what customers and users would need and/or what they would like to have. This person is typically one of the 'seniors' or 'experts' in the organization, who has connections to customers and/or users. This type of Product Owner could also be people like process owners or system owners. Although the term Business Representative suggests that this type of Product Owner comes from 'the business', this is not necessarily the case. It could also be that someone from the IT department is in the Product Owner role, with the maturity level 'Business Representative'. Examples of IT-people in this role could be information managers, architects or security experts. These people may have gained a lot of knowledge about the (technical) product, and therefore be suitable Product Owners. To strengthen this concept of having IT Product Owners... remember that Bill Gates and Steve Jobs were excellent Product Owners too, and these guys really were 'IT-people'. So, the Business Representative has more authorities than the Proxy. The Business Representative is typically responsible for a part of the product, a system or a (set of) process(ess). Within this system or process, this Product Owner may determine for him- or herself which work will be carried out by the Development Team. The Business Representative is therefore responsible for the Product Backlog and he or she has the authority to manage the Product Backlog by themselves. This is however, only as long as the desired changes can be done within the budget that was allocated by other people, such as management or a steering committee. The Business Representative does not have an own budget to spend as desired. He or she needs to get approval for budget changes and therefore often still has to deal with a steering committee or manager. The Business Representative also typically has a list of work to be done, projects to perform or goals to achieve, which were defined by someone else. The Sponsor In contrast to the Business Representative, the Sponsor has his or her own budget. This is the biggest difference between the 'Business Representative' and the 'Sponsor'. In addition to budget responsibility, the authorities for both types of Product Owners are fairly similar. The Product Owner type 'Sponsor' is initially often filled in by business managers, IT managers and customers (in a business-to-business setting) for example. Since Sponsor Product Owners have their own budget, they typically also have more opportunities for up- and downscaling the Development Team. This doesn't mean that you should add or subtract people per Sprint! It could be however, that due to enormous success of the product, the Product Owner would like to scale up to a second or a third team. By having this flexibility and authority these 'Sponsors' can therefore accelerate and delay developments much more, and therefore they have a greater impact on the return on investment and total cost of ownership of the product. Besides the budget authority, Sponsor Product Owners also have a bigger say in 'what' needs to be done. He or she is allowed to define the work to be done, the projects to perform or business goals to achieve. The Entrepreneur The last type of Product Owner is called the 'Entrepreneur'. In practice, we also refer to this role as the 'mini-CEO'. This level of Product Ownership is what we ultimately want to achieve in organizations. This type of Product Owner can achieve the most impact for customers, users and the organization by far. The Entrepreneur Product Owner takes full responsibility for the product and also has full authority over the product. The Entrepreneur Product Owner is someone with a strong vision on the market, customers and the product. It is someone with passion for the product and is someone with strong leadership and communication skills. Entrepreneur Product Owners are ultimately responsible for the product and are therefore profit & loss responsible. Besides product development, they are also responsible for maintenance, operations, marketing, legal aspects and sales. That is why we typically refer to this level as 'mini-CEO'. It is a Product Owner who has his or her own 'mini-company' (which could be a mini-company within a large enterprise). Growing responsibilities and authorities So there are five types of Product Owners, each having their own focus, key responsibilities and authorities. With this growth model you can make an estimation for yourself which type of Product Owner you are, or which types of Product Owners you find in your organization. Remember that the (hierarchical) function within the organization only partially determines which type of Product Owner a person is. If a Product Owner used to be in a management function, he or she probably has some more authorities already. This may help Product Owners to grow faster through the maturity model, but it is not a prerequisite to be or to have been a manager! The authorities a Product Owner has are not only determined by their (previous) function. The authorities are mainly determined by the way you act. By the way the person behaves. In our experience, authorities aren't given away 'for free'. Getting more authorities needs to be earned. And the way you earn more authorities is by taking more responsibility and showing ownership. But how do you take on more responsibilities as a Product Owner? Well, actually that is quite simple... You increase your responsibilities by taking more ownership and responsibility for the success of the product, step by step. For example, develop the product vision and actively promote it amongst your team, stakeholders and management. Actively collaborate with your key stakeholders. Show how you and your team are adding value for customers and users. Make value measurable. And also have a clear view on the costs. Create transparency on these topics and show that you are taking responsibility for the product. Be proactive and do not wait until someone does it for you. So, take initiative. With this you will create more room for yourself to decide things, and thus get more authorities. Successful Product Owners that we have met take responsibility. In many cases, these Product Owners started out as Scribes or Proxy's. Many of them have developed into Sponsors or Entrepreneurs. The term 'Product Owner' isn't just made up, because the creators of Scrum 'needed a name'. The name of this role actually contains the word 'owner'. So the role is about 'owning' the product and it's about taking the responsibilities that come with owning a product. Therefore, ownership is exactly what you have to display to your stakeholders. This is not just about things like the product vision, Product Backlog and financial aspects. It's about your attitude, about your mindset and behaviors. So it may help to regularly reflect. Look yourself in the eye. Have you really done everything you could to improve the product? Are any setbacks caused by others, or could youhave done something in a different way? Take ownership! I hope this blog helps you to gain some insights into the growth path for Product Owners and some steps you could take to increase your responsibilities and authorities as a Product Owner. There is of course much more you could do, but I'm also curious about your own experiences! What type of Product Owner are you? Which steps did you take to grow? What are the next steps for you as a Product Owner? Thank you for reading!

As a Product Owner, you are responsible for Product Backlog management, stakeholder management and forecasting. Therefore, you will probably use a variety of tools and techniques to track progress, manage expectations and keep people informed. One of the tools that may come in handy for you is a product roadmap. Applying product roadmaps effectively can be challenging however. The concept of a product roadmap however, is that it is a high-level, strategic plan, that describes the likely development of the product over the next period of time. The roadmap should support the products' purpose and vision and it helps the Product Owners to keep their stakeholders aligned. The roadmap also makes it easier to coordinate the development of different products and it fosters transparency in order to manage customer expectations. In a lot of organizations, I see that Product Owners are focused mostly on developing features and therefore, a lot of roadmaps are also dominated by features and functionalities to be delivered. The disadvantage of focusing on features too much, is that there are always too much features that would add value, therefore creating a lack of focus on the vision and goals. By focusing on the features too much, the roadmap will turn into an overloaded product backlog, instead of a high-level, strategic plan for the products' future development. In my everyday practice, I've seen a variety of product roadmaps that were used. Although these three different roadmaps all have different pros and cons, I've seen all of them add value for Product Owners in their daily work. Personally, I always use a combination of these three roadmap practices. I mostly use the Storymap in the beginning of a products' development, because I want to create insight for the stakeholders in the products' features. Goal Oriented product roadmap (GO product roadmap) What I personally like a lot about the GO product roadmap is that it facilitates a lot of focus on the goals you wan't to achieve as a Product Owner, much more than the actual work to be done (the features). Although the GO product roadmap offers the possibility of adding features, I like to start with the end goals in mind, and I believe every Product Owner should do so. The GO product roadmap and focus on goals enables value steering (steering on outcome) instead of steering on work packages (steering on output). Since you are responsible for the product vision, strategy and roadmap as a Product Owner, I believe this is a valuable asset of the GO product roadmap. Another aspect of the GO product roadmap I like a lot is that it supports you in thinking about the most valuable features that enable the achievement of your goals. Since Agile is also about "Simplicity - maximizing the work not done" (Agile principle #10), I like the concept that there is only a small amount of space in the model, to force you to think about the top three most important features for a release. What I also like a lot, is that in one glance, you can get an overview of you products' development over the next upcoming releases, which comes in very handy to manage your stakeholders! Depending on the organizations' context, I sometimes leave out the dates and release name sections of the GO product roadmap. I do this since I've seen quite a lot of stakeholders in the past, who saw the dates in the roadmap (which were forecasts from my perspective) and they concluded that they would certainly receive the functionality on the date that was in the roadmap. Since we're working in complex environments which change and since people change their minds overtime, this didn't always work out very well. Therefore, depending on the context, I sometimes use and sometimes don't use the date and release sections, to stimulate interactions and to prevent the wrong interpretations of the items on the roadmap. In these cases, I often combine the GO product roadmap with the Now-Next-Later product roadmap. Now-Next-Later product roadmap The now-next-later product roadmap is a visualization I like a lot, because it's really easy to understand for everyone. All stakeholders understand the concept of this model, since it's easy to understand that you are working on the stuff in the "now" part, the "next" part is what is coming up soon and the work to be done in the "later" part is further away in time and still has to be prioritized. The negative aspect of this roadmap from my perspective, is that it is focussed more on the features, rather than the goals/objectives you would like to achieve as a Product Owner. Besides that, the model doesn't offer much room for including KPI's, releases or dates. Since dates and timelines are important information to stakeholders (in most of the situations I have been in) this may be something you need to consider when applying this type of roadmap. On the other hand, it may just as well be an advantage that the now-next-later product roadmap doesn't include dates, since this offers you the opportunity to interact with your stakeholders, instead of them reading the data from your roadmap.As mentioned earlier, I often like to combine the now-next-later product roadmap with the GO product roadmap, which adds more value for yourself and your stakeholders. Story map The story map is a really nice type of roadmap that I often use in the beginning of new projects or products. The story map is an excellent way to create a nice overview of all the features you and your stakeholders can think of, which will be important to your product. Although the idea is not to create an unlimited list of all the features and functionalities that will likely be developed somewhere in the future, it does provide a nice starting point to facilitate creative ideas for your product. What I like most about the story map is that it provides an overview of all the user activities that need to be covered by the system, which in turn enables you to create small and valuable user stories, which can be developed and delivered incrementally and iteratively. Another aspect I like a lot about the story map is that it starts with the user activities, and thus taking a users' perspective on the product. I really like this concept, since it helps you with brainstorming about the product from a users' perspective, after all, we develop our products for our users and customers right? The main downside of the story map that I've seen in practice is that it creates the illusion that all the features for the product will be developed. Since we're being Agile, it is not our goal to create a complete plan or breakdown for the product, so my advice is to use the story map at the start of your new product development project, but also make it very explicit to stakeholders that you will not neccesarily develop all of the stuff in your story map. So manage these expectations well! 11 Tips for Agile Product Roadmaps I hope these different roadmap types are useful for you, but remember: "Being Agile is not about processes and tools but about individuals and interactions". Therefore, and thanks a to Roman Pichler for offering some inspiration, I would like to share the following 11 tips with you about creating Agile product roadmaps: Start with your product vision (tip: use Roman's Product Vision board); Describe and validate your product strategy; Focus on goals and benefits, by creating a goal oriented product roadmap (or one of the other types I've explained before); Tell a coherent story about the likely growth of your product and don't oversell it; Keep it simple! Resist the temptation to add too much details to your roadmap; Actively collaborate with stakeholders to ensure buy-in; Have the courage to say no, to prevent an overload of features in your roadmap; Think twice about adding timelines, dates or deadlines to your roadmap; Make sure your roadmap is measurable, by adding measurable goals and KPI's; Create a rough estimate for each feature (#people + required skills) to determine the viability of a feature; Review and adapt your product roadmap on a regular basis. Thanks for reading, if you have any feedback to share please do, and good luck with creating your product roadmaps!

Release Planning As a Product Owner, you are responsible for managing expectations of customers, users and other stakeholders. You are also responsible for Product Backlog Management, for deciding that to built when and what not to built. Also, you'll need to decide what to deliver (release) to customers/users, in what order to deliver to customers/users and when to deliver. So, as a Product Owner, you will need to have a release strategy and release plan. In this blogpost, we'll therefore cover 10 tips about Release Planning! I hope you enjoy them! 10 Tips for Product Owners on Release Planning: 1. Focus on goals, benefits and results When planning for releases, there is a lot to take into account as a Product Owner! Is there a market opportunity that can be seized? Are the users ready for it? Can you eliminate certain risks by releasing on a certain moment? And many many more. When you're planning your Product releases, start by identifying goals, benefits and results you want to achieve. Many Product Owners out there are creating a release planning which is focussed around features. This is nice of course, since it offers insights in the development of the Product. What we've experienced to be even more valuable is to design a roadmap around the goals or targets you want to achieve and to show what features are contributing to a certain goal. A nice example of a Goal-Oriented Product Roadmap has been created by Roman Pichler, check out this link for the GO Product Roadmap template. 2. Take dependencies and uncertainty into account Besides planning for goals, it's really important to take dependencies and uncertainty into account. There are different tools and formats you can use, what I've used in the past was the Program Board or Dependency Board as shown on the Scaled Agile Framework website. This helps in identifying dependencies which are especially relevant when you're working with multiple Development Teams. Another way to make dependencies visible is by using a Story Map for example. Identifying dependencies in your release plans makes it easier to collaborate with the Development Team and your stakeholders and to reorder the Product Backlog in a meaningful way. 3. Release early and often! In this blogpost about value, we've covered the importance of releasing as well. What I always share in the Professional Scrum Product Owner Trainings when we talk about Value, there is one thing that you as a Product Owner must remember: “You have to release a Product to customers and users, in order to find out if you have delivered value for them!”. Unfortunately, I encounter a lot of Product Owners in daily practice, who think that ‘working on the Product for just a couple more Sprints’ will create a Product that customers/users will certainly love. Often, this results in a lot of disappointment… So, start validating value, by releasing to your customers and users early and often! Many Product Owner though 'rather' release a couple of times a year, doing big bang releases. This is often done in organizations 'because doing a release is difficult'. In most situations we've faced, this is true! It is often hard to release! But the problem is, if a release becomes bigger and you release less often, it stays a difficult thing that people want to avoid! So, in order to make it easier, you have to do it more often! When you start releasing more often, people will start to think about making it easier (by automation for example) but they will also gain experience, which helps them in doing it better and faster. So stop doing big bang, low frequency release and start doing smaller releases more often! 4. Only release work that is 'Done' In many organizations, a lot of teams are releasing 'undone work'. This 'undone work' is work that is released to production, but which isn't delivered conform the Definition of Done. This creates technical debt, which costs you a lot of time and a lot of money to fix. It will cost you valuable time which you can't spend on delivering value for customers and users! So respect the Definition of Done! 5. Get ownership over the release process Get ownership over the release process. Or better said: Support the Development Team in getting ownership over the release process! In many organizations, doing releases (to production) is something that is 'owned' by a department such as Release Management or Release Coordinators. When the Development Team doesn't have ownership over the release process, it is often more difficult to do a release and it often costs you as a Product Owner valuable time. What I've experienced to be very helpful in the past, is to provide the Development Team with ownership over the release process. This is something nor you, nor the Development Team can often decide by yourselves. So what you can do as a Product Owner, is to create transparency about this topic during the Sprint Review for example. When your stakeholders are asking you: "How can we become faster?" or "How can we deliver more value?". Then help yourself and the Development Team, by raising awareness about the release process. 6. Improve the release process continuously Like we explained in this blog post, there is more to Product development than delivering more features and functionalities. As a Product Owner, you should be aware that improving the release process will support you in delivering more value for your Product. So collaborate with your Development Team to automate the release process, automate tests, automate deployments, etc., but don't try to do it overnight though! Spend a little time on improving the release process every Sprint, so you can deliver both customer value and improve the team. 7. Create at least one releasable Increment per Sprint In many organizations, teams are working very hard on a lot of different things in a Sprint, this often results in the team having 100% of the work, 80% done. Bottomline, this means that a lot of work has been done, but no value for customers and users has been delivered, since it's not finished, it's not 'Done'! So help the Development Team by offering focus, with a Sprint Goal for example. Support the Development Team to deliver a Done Product Increment, as early as possible in the Sprint, which is helpful, since you will at least end up with one Increment that could be released if you'd want to. 8 & 9. Don't release for the sake of releasing + Make releasing a business decision In some organizations there is a centralized release calendar in which everyone has to participate. This release calendar is often planned for monthly or quarterly releases to production. On the other side, more and more teams are gaining ownership over the release process, making it more decentralized. In both situations I've met teams who were 'releasing because we have to release every Sprint'. This is not true! Yes, from a Scrum theory perspective you want to have a releasable/potentially shippable Product Increment every Sprint. Wether or not you will actually release this Increment to production, should be a business driven decision, not driven from a technical perspective, but from a business perspective! 10. Take the context and your audience into account When, how often, to whom you release an Increment depends on the context you are working in and on your target audience. In many organizations, I see that Continuous Delivery is becoming very popular and a lot of people want to be able to do a new deployment of software practically every minute. Of course it is very helpful to be able to release with little effort, with the push of a button. Wether or not you will actually use it, depends greatly on the context. In some contexts (like Amazon's), releasing multiple times a minute seems to have a lot of value. In other contexts, when working on HR- or payroll-systems for example, a release once a month might be enough (at least, that was back in the days when I developed such products). Also check out these other tips for Product Owners! Holy Guacamoly! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out: Agile Product Management (Product) Vision Value Stakeholder Management Scrum Framework Product Backlog Management Release Planning

Product Backlog Management As a Product Owner, you are responsible for Product Backlog Management, in order to maximize the value of the Product. The Product Backlog is the single source of truth which contains all the work to be done on the Product. As a Product Owner, you will have to make some choices about what to build first and what to build later. But also what to build and what not to build! In this post, we'll cover 10 tips about Product Backlog Management. In the blogs to follow, we'll also cover tips on the other aspects of Product Ownership. I hope you enjoy them! 10 Tips for Product Owners on Product Backlog Management: 1. Keep the Product Backlog manageable A mistake we see many Product Owners making, is that their Product Backlogs are way too exhaustive. The worst Product Backlog I've ever encountered contained about 650 Product Backlog Items. This was hell! It was unmaintainable, it was impossible to manage, it was impossible to create transparency and nobody knew where the Product was heading towards. Typically, everyone understands that a Product Backlog of 650 items is unmanageable and this may have been exceptional. But what isn't so exceptional is that I meet a lot of Product Owners, who typically have 100 to 300 items on their Product Backlogs. Out of 10 Product Owners, I would say that five to eight of them have a Product Backlog containing more than 100 items. As a Product Owner, you will have to make choices! You will have to decide what not to do. Your job is to maximize outcome, by minimizing output. You'll have to say 'no'. 2. Stick to one Product Backlog Saying 'no' to people is hard, it's difficult, because we're often afraid of disappointing people. Saying 'no' also feels permanent, definitive. But as discussed in this blog about value, value may change over time, so something you say no to today, may be something you want to do a few months from today. So, to not forget about these items, we see a lot of Product Owners adding these kinds of items to a 'separate backlog'. This 'separate backlog' operates as a container for all ideas, so that we won't forget about them. The truth however, is that if something is actually valuable, and people are waiting for it to be delivered, then it will come up again later on. So, if you say no to something today and it's really valuable, it will come up again a couple of days, weeks or months from now anyway. So, don't keep a separate list! Order, maintain and own one Product Backlog! If you don't want something on that single source of truth Product Backlog, then just say no! The side-effect of saying 'I'll put it on the other list' is that the ownership of the item is transferred from the stakeholder to you as a Product Owner. It also means that the stakeholder will be expecting you to do something with the item. What I often see happening in these situations, is that stakeholders will eventually start complaining that they never get what they asked for... That everything 'disappears' in the list, but you'll never hear about it again. And eventually, they will be disappointed. So it's much better to be clear and say no right away, rather then to let it die slowly (and trust and openness with it). 3. You don't have to do it all yourself Since the Product Owner is responsible for Product Backlog management, many Product Owners want to do all Product Backlog management activities themselves. This isn't necessarily a bad thing. However, you are allowed to let your Development Team support you in managing the Product Backlog! So let them help you! As a Product Owner, you way want to describe all the User Stories, acceptance criteria, functional designs, etc, etc. yourself... But, maybe you want to act more as an entrepreneurial Product Owner, therefore more focussing on the vision, the long(er) term roadmap, the stakeholders, market and business value. So, don't try to do it all by yourself! 4. Not everything has to be a User Story Willem, a colleague of mine, always had a nice way of putting it, which was: "All German Shepherds are dogs, but not all dogs are German Shepherds". This also illustrates how you should see 'User Stories'. A 'User Story' is a format: As a <role>, I want <functionality/what>, So that <business value/why>. A User Story is a template which can be used to describe Product Backlog Items. In Scrum, all items on the Product Backlog are called 'Product Backlog Items'. Some of these Product Backlog Items may written as 'User Stories', but others don't. For bugs or technical debt for example, it often has little or no value to describe such an item as a User Story. 5. Know what is on your Product Backlog This tip may feel a bit of an open door. What I see many Product Owners do in practice however, is that they let pretty much everyone add items to the Product Backlog, resulting in an exhaustive, unmanageable list of wishes. What I used to do as a Product Owner, which worked really well for me, was that I was fully in control over the Product Backlog. I didn't have to know all the details of every single item on the Product Backlog, but I did know what items were on it. And I also knew what items I rejected, which ones I didn't want to do. Of course it is up to you to decide how you want to manage your Product Backlog, but letting everyone add stuff to the Product Backlog often results in reduced transparency, lack of clarity, a wrong ordering and loss of manageability. 6. Reorder the Product Backlog continuously The Product Backlog is a living artifact. It's something that evolves, changes, grows and shrinks over time. Therefore, you need to reorder the Product Backlog continuously! The ordering of the Product Backlog may change from week to week, so make sure you keep the Product Backlog up-to-date. As a Product Owner, you should make the Product Backlog transparent for all the stakeholders and the Scrum Team (also see tip 9). This transparency on the Product Backlog is valuable if and when the Product Backlog is up-to-date. Besides having a transparent and ordered Product Backlog for the stakeholders, you'll want to have a transparent and ordered Product Backlog for the Development Team. Every Sprint starts with the Sprint Planning and in that meeting you'll need to have an ordered Product Backlog so that the Development Team can create an actionable plan for the Sprint. Before that Sprint Planning, you'll probably get some feedback from people during the Sprint Review and you'll get some actionable improvement actions out of the Sprint Retrospective... So as you see, you'll have to keep ordering and reordering the Product Backlog continuously! 7. The Product Backlog shouldn't be complete A pitfall that a lot of starting Product Owners step into is that they want to create a complete Product Backlog at the start of a new project, especially when they come from more traditional or project oriented environments. They're used to defining the scope of the project or the team upfront, with all the requirements needed for the project. However, Scrum and Product Ownership aren't focussed on delivering projects. They're focussed around products. Product Development is something that never ends, as long as the Product lives, and so, the list of demands, requirements, wishes and more will keep growing and shrinking over time, as long as the Product lives. So don't try to create something like a 'complete' Product Backlog. Create a Product Backlog with the most valuable ideas for the Product and start from there! It will change over time anyway, so don't try to get it perfect at the start, when you actually know the least! 8. Focus on 'what' and 'why' Another pitfall for a lot of Product Owners is that they are focussed too much on finding and describing 'solutions'. There are many Product Owners out there that are doing a lot of business analysis, technical analysis and who are creating (functional) designs and descriptions for the Development Team. Although it's not fundamentally wrong, I have always experienced that nine people have more creative and problem solving power than one person alone. So what I always recommend is that a Product Owner shouldn't be concerned with the (functional/technical) solution. A Product Owner shouldn't have to 'design' a feature. A Product Owner should be concerned with the problem he or she wants to solve, or the opportunity he or she wants to grasp. So, a Product Owner should mainly be focussed on the 'what' and 'why'. A Product Owner shouldn't be concerned so much with the 'how'. So, use the creative and problem solving power of the team to design the solution! 9. Put it on the wall As mentioned earlier, the Product Backlog should be transparent for stakeholders and the Development Team. There are many ways of creating more transparency, but one of the most powerful ones is to literally put the Product Backlog on the wall! Of course you have to take all kinds of things into account (like a distributed setting or access restrictions), but what typically works great to increase transparency, is to put stuff somewhere on the wall, close to the team, so that when people walk by, they can actually see what the team is working on now, and what they will be working on in the near future. 10. There is more than customer or business value The final tip for now is that there is more than business or customer value that you need to consider. Of course you want to deliver as much value for customers, users and the organization as possible, but should it be at all costs? I hope not! What we've seen a lot of Product Owners do, is that they are fully focussed on delivering as much features as possible. But, as a Product Owner, you are not responsible for delivering more features! You are responsible for maximizing value for customers and users! To put it otherwise: You are responsible for the success of the Product. This doesn't only included deciding on new features or functionalities in the Product. It also means that you should consider resolving bugs, technical debt, improving the Products' architecture, improving performance and security. It also means you should spend time on test-automation and the deployment/delivery process. If you spend time on automating manual testing and/or manual deployments, you will eventually be able to deliver more value, with higher quality in a shorter period of time! So, these are the 10 tips for Product Owners on the topic of Product Backlog Management! I hope you enjoyed them and that they'll help you in becoming a better Product Owner! Also check out these other tips for Product Owners! Holy Guacamoly! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out: Agile Product Management (Product) Vision Value Stakeholder Management Scrum Framework Product Backlog Management Release Planning

The Scrum Framework The Scrum Framework is a lightweight framework that defines three Roles, three Artifacts and five Events, which is used to develop and maintain complex Products in complex environments. Scrum doesn't prescribe a lot of things you must do, the Scrum Framework doesn't include extensive practices, documents or meetings that you must follow. There are a few rules however, which are described in the Scrum Guide. Don't try to change the Scrum Framework, don't leave elements out before you've applied the Scrum Framework as it is described in the Scrum Guide! In this post, we'll cover 10 tips about the Scrum Framework. In the blogs to follow, we'll also cover tips on the other aspects of Product Ownership. I hope you enjoy them! 10 Tips for Product Owners on the Scrum Framework: 1. Use a Sprint Goal As a Product Owner, your main responsibility is to maximize the value of the Product(s) you deliver to customers and users. In order to maximize the value, you will have to make some tough choices on what to build and what not to build. You're also making choices on that to build when. You're ordening the Product Backlog, to maximize value, to take opportunities, to minimize risks and also to create focus for the Scrum Team! Focus is one of the core values of Scrum and it's a very important one in my opinion. Having focus in the Scrum Team helps you to increase output and value delivery, but it also makes the team more effective, more efficient and allows for more self-organization! As a Product Owner, you can have a major impact on the success of a Sprint, by increasing focus for the Scrum Team. One way of creating more focus, is by providing the team with a guiding Sprint Goal. The Sprint Goal provides the team purpose, a common direction and clarity on then the Sprint is successful or not. Many Product Owners in daily practice don't use a Sprint Goal, that's such a shame! 2. Be part of the Scrum Team The Scrum Team consists of a Product Owner, Scrum Master and Development Team. In many Scrum Teams, we find that the Product Owner isn't acting as a real Scrum Team member. He/she isn't available during the Sprint, isn't engaged with the Scrum Team, isn't supporting the Scrum Team in continuous improvement, etc. etc. As a Product Owner, you should be part of the Scrum Team, because they're helping you in maximizing the value of the Product. If you help out the Scrum Team, they will be better in helping you out! 3. Facilitate focus for the Scrum Team As mentioned in tip 1, creating focus for the Scrum Team is very valuable. Besides creating a Sprint Goal with the team, you could also create more focus in the Sprint by selecting Product Backlog Items that are related. For example, orden the Product Backlog by grouping Product Backlog Items that require work on the same part of a system or on the same process. 4. Don't 'manage' the Daily Scrum The Daily Scrum is an Event for the Development Team to inspect the progress made and adapt their plan for the next 24 hours. It's helpful (but not required) that the Product Owner and Scrum Master are present during the Daily Scrum, to answer questions of the team and provide guidance or help if needed or asked. However, in practice we meet a lot of Product Owners and Scrum Masters who are 'managing' the Daily Scrum. They are dividing tasks among team members, they are asking what people did the last day and what they're going to do, they update the Sprint Backlog, etc. etc. From now on, don't do this anymore! The Daily Scrum is an Event from and for the Development Team, it's not a status update meeting from the Development Team to the Product Owner or Scrum Master! When you stop managing the Daily Scrum, you'll see that the Development Team becomes more self-organizing, which creates more time and space for you as a Product Owner to focus on your stakeholders and the long(er) term roadmap for example. 5. Inspect and adapt the time spend on Product Backlog Refinement Product Backlog Refinement helps you to order and reorder your Product Backlog, it also helps you in splitting Product Backlog Items, making Product Backlog Items more clear, etc. etc. The guideline for Refinement is to spend about 10% of the Development Teams' capacity on Refinement, but this is just a guideline! So you have to inspect and adapt how much time you're spending on Refinement. In our experience, it helps to implement a rhythm or cadence in doing Refinement. For example, I often implement a Refinement meeting with the Scrum Team (and stakeholders when needed) two times a week, on Tuesday and Thursday for example, for one to two hours. This rhythm reduces complexity and increases predictability for the Scrum Team and it's stakeholders. Besides implementing a rhythm, go out there and find out how much time you should spend on Refinement! For some teams it's 5%, others 10% and again others 20%, so find out how much you need! A guideline is that you'll want to have a Product Backlog with 'Ready' Items for the next two to three Sprints. 6. Deliver something 'Done' at the end of the Sprint We meet many Scrum Teams who are taking up way too much work in a Sprint, often resulting in the team not delivering anything 'Done' at the end of the Sprint. Surely they've done a lot of work, surely they started working on a lot of the Items, but at the end of the Sprint, all the work (or part of it) is moved to the next Sprint. Is this something you recognize? Then this tip is for you! An important step you should take is reduce the number of Items the team takes into the Sprint! Since you want to maximize the value for the Product, your goal is not to produce as much output as possible, but to create as much outcome as possible, right? So, the team may deliver a lot of output, for example 20 PBI's that are 80% 'Done', that sounds awesome! Errr.. No! Because this is twenty times zero value! If it isn't 'Done', then no value for customers and users was delivered! So I would rather have ten Items that are 100% Done, because this is ten Items of value, instead of zero value. 7. Respect the Definition of Done Under internal or external pressures (like deadlines, marketing events or other opportunities) many Product Owners start to push the Development Team to deliver faster. They are however not reducing the scope to be delivered, they are often pushing the team to deliver the same scope (or more) in less time. This often (if not always) results in major losses of Quality. When the Scrum Team is not conforming to the Definition of Done anymore, they're delivering bad quality. On the short term, this often seems fine, but on the long(er) term, you're creating a lot of undone work and technical debt. In many organizations, we've seen (about 4 to 6 out of 10) teams that were solely working on issue solving, bug fixing, problem management and resolving technical debt. It's always much more costly to fix quality after going live, than to build in quality upfront! So respect the Definition of Done and let the Development Team deliver quality products! 8. Don't mistake the Sprint Review for 'a demo' In many organizations, the Sprint Review is treated like a 'demo'. Although 'demoing' the Product Increment is part of the Sprint Review, it is not it's sole purpose! The goal of the Sprint Review is to collaborate with stakeholders in order to gain feedback on the Product Increment, to inspect the market, to inspect the Product Roadmap and to collaborate on the next steps to be taken in order to maximize value for the Product. This all means that the Sprint Review is a collaborative working session. It's not a status update (using Powerpoint) from the Development Team to the stakeholders, or worse, from the Development Team to the Product Owner! It's a meeting which helps the Scrum Team to inform the stakeholders, to interact with them, to exchange ideas and feedback and to decide on the next steps to be taken for the Product. 9. Work with the Scrum Master on a daily basis As a Product Owner, the Scrum Master (or Agile Coach) is your friend! He or she can help you, coach you, advise you, train and mentor you with all kinds of challenges. I meet a lot of Product Owners however, who are rarely collaborating with their Scrum Master. This is such a pity! The Scrum Master can help you in coaching stakeholders, facilitating stakeholder Events, coaching you in improving your Product Backlog management skills, stakeholder management, etc. etc. The Scrum Master isn't just there for the Development Team, the Scrum Master is also there for you and the organization! So collaborate in order to deliver more value! 10. Be involved in and committed to continuous improvement In many Scrum Teams, Product Owners are disconnected/unavailable during the Sprint or they are not involved in continuous improvement. We've encountered many Scrum Teams in which the Sprint Retrospective was an Event performed by the Scrum Master and Development Team and where the Product Owner was never there, or was there once every few Sprints. This is a big misunderstanding of the Sprint Retrospective and it's such a loss for the Scrum Team! As a Product Owner, you should definitely be participating during the Sprint Retrospective! As a member of the Scrum Team, the Product Owner should be involved in continuous improvement too. There may be things you can do better as a Product Owner, there may be improvements to be made in the collaboration between you and the Development Team, there may be some important decisions to be made, so you should be there. Besides that, you want to maximize value right? If the Scrum Team can make improvements happen in the process, collaboration, communication, etc. etc., then you should want to know! Because if the team becomes more effective, you could deliver more value for customers and users! So, these are the 10 tips for Product Owners on the topic of the Scrum Framework! I hope you enjoyed them and that they'll help you in becoming a better Product Owner! Also check out these other tips for Product Owners! Holy Guacamoly! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out: Agile Product Management (Product) Vision Value Stakeholder Management Scrum Framework Product Backlog Management Release Planning

As a Product Owner, you are responsible for stakeholder management. It's important that you know your stakeholders, their interests, what they need from you and your Product and how they may be able to help you out as well!

Value comes in many different forms, value is context dependent and the definition of value in a certain context may change over time! What? Yes, that's right! What 'value' is, or what it means, is firstly context dependent.

The Product vision describes the purpose of a Product, the intention with which the Product is being created and what it aims to achieve for customers and users. The Product vision describes a future state of the Product and what problems it tries to resolve or what ambitions it tries to fulfill.

The Product Owner role is totally different from traditional roles that are know in most organizations. Some people think that the Product Owner is a kind of 'Agile project manager' or that the Product Owner is sort of a 'business analyst'. This is not true!

In this blog, we'll cover some tips and tools for starting Product Owners, to help you in your new role. The Product Owner role is a brand new role in many organizations and it's a role which can't be compared to traditional roles, such as project managers or business analysts. A Product Owner in it's most beneficial form acts like an Entrepreneur, like a 'mini-CEO'. The Product Owner is someone who really 'owns' the product. This is something quite different from a project manager (PM) or business analyst (BA) role, where 'the business' typically 'owns' the product and where the PM or BA act more like a proxy between the (project) sponsor and the supplier (IT for example). The Product Owner as an Entrepreneur owns the Product, the Product Vision, the Product Roadmap and the Products' budget. So ideally, the Product Owner is profit-and-loss accountable for the Product. What I see in many organizations however is that the Product Owner role is implemented on a 'lower' level of the Product Owner Maturity model. So, most Product Owners I encounter are actually Scribes, Proxy's or Business Representatives. In this blog, we'll cover some tips for the starting Product Owner. In another blog (which will follow soon) we'll cover tips for more advanced Product Owners (on the Entrepreneurial level). Okay, so you just started as a Product Owner, what should be your first steps? Below I've defined some important steps you should take as a Product Owner. Important remark: Beware that these steps aren't necessarily sequential. Although I found it helpful to perform the following steps in this order, you might want to change some stuff around of course. Don't misuse these steps to prevent you from getting started! The purpose of these steps is not to perform them all, before you ever start your first Sprint. You'll want to start your first Sprint as soon as possible, deliver a done increment and work on these steps as you're learning new things. Step 1: Form the Scrum Team & collaborate with them. As a Scrum Product Owner, you only need one thing in order to get started, which is your Scrum Team! You'll need someone to help you guide the process, coach you and your team and to solve impediments, which is your Scrum Master. And of course, you'll need some people to develop and maintain the product, which are the people in your Development Team. Your first step as a Product Owner should therefore be to get yourself a Scrum Team. In all the following steps, make sure you collaborate with them to increase your chances for success, but also to get the team enthusiastic, motivated, involved and to use their knowledge and experiences. Step 2: Get clarity on the (product) vision. Many Product Owners start as scribes, proxy's or business representatives on the Product Owner maturity model. Ideally, you'd be the person who defines the vision, but what I see typically is that starting Product Owners are appointed in their role by the organization and typically do not have the mandate to decide on the (product) vision yet. So therefore, you should get clarity on the (product) vision, by talking to your stakeholders (and your Scrum Team). There are many tools/techniques that could help you in defining the product vision, take a look at some of these techniques (business model canvas, product vision board, product canvas, value proposition design) and collaborate with your stakeholders, Scrum Master and Development Team to create them. Mind yourself, it would require a perfect and non-changing world to get your first vision board right. Besides that, since the world is changing continuously, you'll probably have to pivot or change things around over time anyway. So, don't try to get it perfect! Try to create an inspiring vision, that helps people to focus. That's an important part of your job as a Product Owner, create focus. Step 3: Get clarity on your stakeholders and how to engage them. One of your responsibilities as a Product Owner, is to manage (or engage with) your stakeholders (including customers). You should make sure that the right people are sitting together with you as a Product Owner, to decide on the product vision, product roadmap, value for the product and to make choices together. As a Product Owner, you should involve the right stakeholders to maximize value delivered to your customers. A tool I've used very often is the 'stakeholder map'. It's a nice tool to gain insight in the stakeholder field and to decide how to manage them / engage with them. In the stakeholder map, you can plot your stakeholders on two axes; 1) their (formal/informal) power and 2) their interest in the product. Based on their power and interest, you can define how to engage with the different groups of stakeholders. So what I often did, was that I designed a stakeholder map and based on the mapping, I designed my communication strategy for the different groups of stakeholders. Although I may not have to mention this, you would likely spend most of your time on your most important stakeholders! So design your communication strategy based on this principle. Step 4: Get clarity on your mandate (including your team and budget). So, now that you know your most important stakeholders, involve them to define your mandate. Maybe you've been appointed by a sponsor, management or the business as a Product Owner, but what does this mean for them? What are your responsibilities? And what is the mandate that comes with these responsibilities? Something I've used often to get clarity on the Product Owners' mandate, is Jurgen Appelo's (author of Management 3.0) Delegation Poker. There are quite some examples of Delegation Boards / Delegation Poker that can be found on the internet, also see the following example. There are some aspects that I always like to get clarity on (amongst lots of others), which are: Who is needed to define, change or pivot the product vision? Who is needed to define, change, pivot or remove business goals? Who is needed to add, define, change or remove items from the Product roadmap? Who is needed to add, define, change or remove items from the Product Backlog? Who is needed to add, change or remove people from the Scrum Team? Step 5: Determine what 'value' is/means for your product. How to define and measure value is something that is context-dependent. This may be totally different depending on your product, type of product, product lifecycle phase, etc, etc. Therefore, you should define together with your (most important) stakeholders, what you consider as 'value'. What is 'valuable' for the product? What is valuable for your customers? What is valuable for the processes you're supporting? Based on how you define value for your product, you can also decide how you will measure value for the product. Please remember, what value is for your product is context dependent. However, what value is, is also time-dependent! What value is for your product and how to measure it, may change over time. Step 6: Create a (goal-oriented) (product) roadmap. Now that you've defined what value is for your product and how to measure value, it's a good time to translate this into a goal-oriented product roadmap (also see this blog for some tips about roadmaps). I like the goal-oriented roadmap a lot, since it is focussed on value (goals) first and features later. A lot of Product Owners fall into the trap of maximizing the teams' output. Your goal should however be to maximize outcome. So, start by focussing on goals first! Define a couple of goals for the shorter term (next Sprint, this month, next month) and for the longer term (this quarter, next quarter, this year). Ordering and managing your Product Backlog will become much easier if you are clear on your goals. Step 7: Create a story map for the product. The next step would be to create a story map, together with some of your stakeholders and your Development Team. The story mapping technique is an awesome way to brainstorm, gain insights and get a picture of the product you are creating. Step 8: Co-create the Sprint Goal & the Sprints' plan. Now that you've created your roadmap and story map, it's time to design a Sprint Goal. The Sprint Goal has been very helpful for me in the past, because it provides the Scrum Team with a lot more focus. Focus is not only one of the core values of the Scrum Framework, it also makes a huge difference for the performance of the Development Team, and herewith also for the amount of business and customer value you can deliver for your product. What I used to do as a Product Owner, was to create a 'concept' Sprint Goal before the Sprint Planning, with which the Scrum Master assisted me by asking lots of questions and by brainstorming together. The reason I'm calling it a 'concept' is because the Sprint Goal is being created during the Sprint Planning, together with the whole Scrum Team. Personally, I always liked to start the Sprint Planning with a goal in mind, to reshape that goal with the Development Team and then to move on to the other aspects of the Sprint Planning meeting. Step 9: Keep collaborating with your Scrum Team and stakeholders. While Sprinting, and while regularly delivering done product increments, the most important thing for you to do as a Product Owner, is to keep collaborating with your Scrum Team and your stakeholders. Support the Development Team by hosting refinement sessions, explaining the product vision, goals, roadmap and Product Backlog items. Support them by making items small, clear and valuable. Support them in gathering feedback from customers and users, etc. Also keep collaborating with your stakeholders. Make sure to spend the most amount of your time on your most important stakeholders. Update your stakeholder map once in a while. Evaluate if your communication strategy is still working. And most important, make sure you get feedback early and often, so that you can maximize the value delivered every Sprint, again and again! So that's it! 9 Tips for starting Product Owners. I hope this was useful for you!