Martin Hinshelwood

One of my customers is asking me about the accountabilities of a Product Owner and how they break down. While I had seen many things around the Scrum Master for my post on Hiring a Professional Scrum Master, this was a little bit more of a discovery session, which is why I asked some of my trusted colleagues at Scrum.org to help out. Topic(s): Discovery & Ideation, People & Process Audience: Product Owners Subscribe to A Wee Dram! Get all our posts straight to your inbox by subscribing to the latest posts. Key Influencers: Fredrik Wendt | Scrum.org, Ralph Jocham | Scrum.org, Andy Hiles | Scrum.org. Maarten Dalmijn | LinkedIn, Jim Sammons | Scrum.org, Victoria Pent | LinkedIn This represents my best efforts to pull together a specification of the Product Owner accountability from the Scrum Guide, agile practitioners, and a little bit of experience. Professional Scrum Product Owner Stances Hiring a Professional Product Owner In general, I do not see companies hiring for a Product Owner but instead promoting from within. Maximizing the value in the product requires intimate knowledge of the business context, the existing state of the market, and the things that make your business distinctive. They need not only these understandings but also the ability to communicate effectively with Developers and Stakeholders. My take on the above…I am seeing the opposite. I’m seeing more companies valuing Product Ownership as a skill and going outside for it. I think this is a positive trend and will probably have the benefit of bringing an outside perspective to a company which may be exactly what a product needs. Data: LinkedIn has 12,894 jobs for “Product Owner just in the US right now and 25,520 for “Product Manager”. Didn’t look at global numbers. – Jim Sammons | Scrum.org Adding to Jim’s data: Country / Job Title | Product Owner | Product Manager USA | 12,894 | 25,520 UK | 9,256 | 23,241 EU | 25,254 | 35,626 Worldwide | 119,808 | 300,060 Data of Jobs posted on LinkedIn! If you just need short litmus tests for product ownership then Jim Sammons sent me this “Five A’s of Product Ownership” graphic. Five A’s of Product Ownership I do mention certifications, both from Scrum.org and Scrum Alliance, and please be aware that certification is not an indication of competence but may be used as a simple bar to reduce the load on interviews and assert a minimum level of knowledge, at $200 for a PSPO I assessment and $250 PSPO II assessment. With a reputation in the industry of not being totally easy, these are a no brainer for any aspiring or experienced Product Owner. There are more than 100k people with PSPO I and 2k people with PSPO II at the time of writing. The assessments can be used to inspect and adapt your own knowledge and there is even a free Product Owner Open assessment. A Scrum Product Owner Job Spec The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. Role Summary (Accountabilities) This Product Owner is a key position that sets the tone for product leadership and the definition of success in the organization. As such, modern product management practices and mindset are expected to be put into practice daily. This Product Owner is accountable for and has the authority to maximize the value of the product and the effectiveness of the Product Backlog by using, but not limited to, these 6 key stances: The Visionary Articulating the strategic vision of the product; Developing and explicitly communicating intermediate strategic goals; Propose how the product can tactically increase its value each Sprint; Understand and shape the impact of the product on our company; Each Sprint ensuring that the Scrum Team is prepared to discuss the most important Product Backlog items; The Influencer Actively manage stakeholders, their desires, expectations, and outcomes; Create an effective communication strategy; Influence the Developers during Backlog Items Sizing by helping them select and understand trade-offs; Work with Developers daily to clarify and renegotiate the Scope of the Sprint; The Collaborator Collaborating closely with the Developers & Stakeholders daily; Developing and communicating budget, investments, roadmaps, vision, & strategy; Developing controls for a change, risk, quality, & incident management to enable professional Scrum; Developing and influencing commercial contracts that align with the agile values and principles; The Customer Representative Understand the desired outcomes of customers within the bounds of the business constraints Defining our product(s) and services and how customers will interact with them The Decision Maker Ensuring that the Product Backlog is transparent, visible and understood; Ordering Product Backlog items; Choosing what and when to release; The Experimenter Using evidence-based management techniques to optimise outcomes and value delivered; Create hypothesis and craft experiments to test that hypothesis quickly; Tracking product use and impact on end-users and drive consistent approaches across all Product Verticals; The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable. Role Requirements The successful candidate must have the following attributes: First level Scrum Product Owner certification (CSPO, PSPO I); Product Owner Experience; Demonstrable experience of product ownership; Business domain knowledge; a keen understanding of the [business domain], market, and other influencers; Entrepreneurial focus; A keen understanding of evidence-based techniques to inform strategic and tactical milestones; Excellent ideation skills; with a proven track record of successful hypothesis-driven ideation and sustainable feedback loops; Excellent communication skills; Communicating Vision, Goals, and Backlog Items with both the Developers and other Stakeholders; In addition, the successful candidate will have some or all of the following attributes: Second level Scrum Product Owner certification (A-CSPO, PSPO II); Experience fulfilling the Product Owner role for at least two years; Knowledge and/or experience with complimentary Agile product management techniques: Evidence-based Management, Goal-orientated Product Roadmap, Business Model Canvas, Growth Experiment Canvas, Delegation Poker, Liberating Structures, Three Horizons Innovation, Stakeholder Mapping, Impact Mapping, Value Pyramids; I would love to get your feedback and discussion on this job specification so that we can make it better! What does this mean? When I sent the above to my customer they condensed it into this easy to digest “What does this mean?” section for communication. As you read through this it's important to note that it is as much about behaviours as it is about accountabilities. Articulating the strategic vision of the product Developing and explicitly communicating intermediate strategic goals Propose how the product can tactically increase its value each Sprint Understand and shape the impact of the product on our company Collaborating closely with the Scrum Teams & Stakeholders on a daily basis Developing and communicating budget, investments, and road-maps Developing and influencing product governance and controls to enable professional Scrum Understand the desired outcomes of stakeholders within the bounds of the business constraints Defining our product(s) and services and how stakeholders will interact with them Ensuring that the Product Backlog is transparent, visible and understood Ordering Product Backlog items Choosing what and when to release Using evidence-based management techniques to optimise outcomes and value delivered Create hypothesis and craft experiments to test that hypothesis quickly Tracking product use and impact on end-users and drive consistent approaches across all Product Verticals Actively manage stakeholders, their desires, expectations, and outcomes Create an effective communication strategy Influence the Developers during Planning and Refinement by helping them select and understand trade-offs Work with Developers daily to clarify and renegotiate the Scope of the Sprint. Each Sprint ensuring that the Scrum Team is prepared to discuss the most important Product Backlog items The key point in the above is the delegation point; we are not thinking that a single Product Owner is able to conduct all of the above on a Programme of this size – and we obviously have other members of the Hiscox team, and Cognizant Business Analysts to share the load… but accountability remains with the Product Owner. Want to learn more? While you can purchase your assessments from Scrumorg, we offer some amazing interactive live virtual training that dives into a lot more than just the assessment content. Beginner Professional Scrum Product Owner Training with Certification Professional Scrum with User Experience Training with Certification Intermediate Evidence-based Management Workshop Advanced Professional Scrum Product Owner – Advanced Training with Certification Sources: Scrum Guide | Scrum Guides

One of my customers is hiring for the Scrum Master Role and asked if I had a handy-dandy Scrum Master Job Spec that they could use....

Gathering the metrics for Evidence-based Management in software organisations can be a strenuous task and I have a number of customers that are fretting on what to collect and from where. Here I try to create an understanding of the ‘what’ that we need to collect. Updated to reflect the 2020 Scrum Guide! Evidence-based Management for Software Organisations is a framework from Scrum.org to help organisations focus their efforts on most valuable improvements and monitor their effect on the organisation. In my experience, organisations recognize agility as a means to improve their value, yet tend to lack focus and commitment to moving towards it. This is mostly because of entrenched traditional ideas and a resistance to change that comes, in the west, from an “if it ain’t broke, don’t fix it” mentality. Let’s forget for a moment that it has been proven over and over again that small experiments that fail quickly are what produce results. Let’s forget as well the 20 years of the success of agility when there is focus and courage. We need evidence… Topic(s): Measure & Learn, People & Process Audience: Product Owners, Leaders Subscribe to A Wee Dram! Get all our posts straight to your inbox by subscribing to the latest posts. Evidence-Based Management: Gathering the metrics That evidence is there. You can find study after study that shows that agile practices work, that moving to agile values works better. So why don’t people listen? Still, I hear: “That will not work here”, especially in the enterprise. In the successful enterprise its worse: “We are fantastic and we know best as we have been doing it this way for many years with success”. Unfortunately, the measure of success has traditionally been: delivered on time delivered on budget with the features that were required upfront This measure of success does not take into account how much ‘value’ is delivered to the customer or users. If you take another look, as the Standish Group in Boston has, at the above traditional measures of success (used both by PMI and Prince2) you find that this measure equates to very little value to the customers. Forrester is currently trying to encourage the organisation to start measuring the value that they are delivering rather than how they are delivering it. How we measure value up until now in software delivery has been to either rely on the Product Owner or to start introducing traditional measures from formal process… and we already know where that leads. The dark side! So what can we measure? Sure Scrum has traditionally focused on the team, and the best measure for a team is “Remaining Work”. From that, we can create Velocity and Burndown to help the Product Owner plan and the Development Team deliver. Simple… but organisations are not simple and need a way to really measure success in an agile fashion. If we can provide organisations with some standard agile metrics maybe, just maybe, we can pull them out of the dark and into the light. This is why, with all the kafuffle over “scaling Scrum”, Scrum.org has been biding its time and doing its research. Most of the scaling Scrum methodologies out there miss the boat on measurements. Not only that they have [come under much fire recently] for providing way too much rigour in the wrong places for a “one size fits all” solution. If you can’t have “one size fits all” at the team level you sure can’t do it at the organisational one… I have discussed What my father taught me about evidence-based management and metrics that matter over the years: Evidence-based Management for Software Organisations (n): A process for measuring, diagnosing and improving the value an organization derives from its software investments. It improves an organization’s ability to compete on its software capabilities by using evidence to focus investments on areas that will create the highest value for the entire organization. Its iterative, incremental approach to guided change helps organizations control the risk of disruption. You can find out more from The Evidence-Based Management Guide: Measuring Value to Enable Improvement and I want to talk a little more about the gathering of metrics for monitoring. Let’s face it, it’s not just Organisations that want to understand their return on investment for their hard-earned cash spent on improving their process and practices. There are good consultants out there that want to understand the value that they are bringing to their customers so they can inspect and adapt as well. I, for one, want to focus on delighting my customers. To bringing them the most value for what they pay me. I have traditionally done this by simply looking at how happy my customers are. While this is an important metric is only one piece of information in a web of interconnected data that I can use as evidence of that improvement. That is why I went to Boston last month to complete the training and assessment to become an Evidence-based Management Consultant with Scrum.org. I need to understand how my advice affects an organisation that I am working with. How else can I know if my advice is good? Guesswork? That sounds a little…archaic. There is a better way… There are really three groups of metrics that make sense at the organisational level. There are metrics that monitor the current value being delivered, the time to market and your organisation's ability to innovate. We need to gather these metrics at a point in time as soon as possible to provide a baseline for where the organisation currently is. We can then reassess the organisation at intervals, probably no more than quarterly, which will allow us to look at the trends over time. Current Value Metrics The current value metrics look at data that gives an indication of the company’s success in the market place. These metrics should be gathered once across the organisation with the organisation defined as consistently as possible across instances. They might include: Revenue per Employee – Gather the revenue generated by the product you are evaluating and employees contributing to its success Cost of Product Domains – Gather the IT expenses associated with the product Employee Satisfaction – what percentage of employees are engaged? Customer satisfaction – what percentage of your customers is marketing your products or services on your behalf? All of these are easy to collect and most are likely readily available. Many enterprises already do some form of employee and customer satisfaction which we may be able to use. However, the time span of the collection of the metrics should ideally match. Time-to-Market Metrics These metrics look at how quickly an organisation is able to bring new innovations to its customers. They might include: Release frequency – How often do we put new features in the hands of our customers? Release stabilisation – How much time are we spending on getting something “done” to “really done”? Cycle time – How long does it take for us to move new features from an idea into customer’s hands? Ability to Innovate Metrics These metrics look at an organisation’s ability to continue bringing innovations to its customers in the future. They might include: Installed Version Index – What percentage of your customers are able to take advantage of new features on the latest release of your product? Usage Index – What percentage of our features does not provide value to our customers? Innovation Rate – What percentage of our budget is spent on innovation? Defects – How much technical debt are we accumulating? As you have already likely surmised with these metrics it makes sense to gather them per application. We can then average the results to figure out what they are across the entire spectrum. While these figures may vary wildly between applications as long as you use the same formula you should get comparable results. Scrum.org suggests tracking many of these metrics and monitoring the trend to help inform your additions towards agility. This data becomes synonymous with the value an organization is getting from its software development capabilities. Conclusion For the first time, we can now, as consultants, monitor the improvements we are making in organisations. Even better, organisations can use these metrics to demonstrate the value that their investments in agility with training and consulting are bringing them. This is a fabulous step forward in our understanding of software delivery. An easy, simple way of measuring our progress towards process improvement. Subscribe to A Wee Dram! Get all our posts straight to your inbox by subscribing to the latest posts.

For many people, the traditional project management methodologies (see PMI / PRINCE2) are the root of the problems that birthed Waterfall. I assert that this is the tip of the iceberg.

In the The Evidence-Based Management Guide we talk about the Intermediate Strategic Goal and I likened that to the Product Goal in the 2020 Scrum Guide.

Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum.

Many organisations wrestle with the seeming incompatibility between agile and release management, and they struggle with release planning and predictable delivery.

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly.

Many teams are struggling with delivering modern software because they are not building with Test First Principles. Test First gives us the assurance that we have built the correct thing, that what we built is what the customer asked for and that when we change things we don’t break anything inadvertently.

In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).