Product Ownership Onward and Upward

Product ownership is the most demanding job in agile and gets the least attention.  I have created a series of blog posts to explain the skills necessary to become a great product owner.  Today, I want to summarize and provide some inspiration.

The first thing that a product owner should understand is the team succeeds or fails together.  The scrum master, product owner, and development team all hang together.  Rock stars, divas, or people seeking to punch their ticket to a higher position need not inquire into the role.  The agile principles plainly state that working software is the measure of progress.  The team creates working software and should receive credit because it is never about one individual.  If you are looking for glory, my recommendation is reality television. 

The next thing to remember is the social compact of agile.  The product owner must respect the estimate of the development team, and the development team must respect the priorities of the product owner.  The product owner sets the importance, and the group says how long it will take to do the work.  It is a difficult balance to master, but it will build trust in the team.  

Next, a product owner should adopt the DEEP model of backlog management from Roman Pichler.  The DEEP model is the blueprint of your backlog.  Having a backlog that is detailed, estimated, emergent, and prioritized will make everyone's life easier.  Sprint planning is easier when you have correctly detailed stories and the team estimates them.  Priorities help organize the social compact of agile, which builds trust.  

IF the DEEP model is the blueprint for the product you want to build, then to author good user stories are the individual bricks that make it possible to construct those products.  Stories that have clear descriptions of work plus acceptance criteria for getting the job done to speed up the development of the product and make it easier to test are what separate good product owners from great ones.  Thus, product owners need to practice writing better user stories.  

Finally, a product owner needs soft skills to deal with the "art" and the science of creating a product.  It requires saying not to others because priorities do not align.  Listening allows you to understand what needs doing and why.  Good listening skills also allow you to build trust with other teams.  Finally, diplomacy is necessary to deal with situations where there is a power imbalance of a stressful situation that requires navigation.  These soft skills help build professional credibility in the job.  

Most organizations do not understand the importance of quality product ownership.  The DEEP model, writing good user stories, and soft skills will set you apart from a run-of-the-mill product owner.  By embracing these areas of professional development, you will improve your career and your team's performance.  Product ownership is the most challenging role in agile but, if done right, the most rewarding.

Until next time.  

Soft Skills for an Excellent Product Owner

I want to improve the skills of Product Owners.  I introduced the topic and provided tips about backlog management and authoring user stories.  Today, I will discuss the soft skills a good Product Owner needs to cultivate.  

The Authority and Ability to Say No –

One of the tragedies of the contemporary business world is the number of people who are crushed with responsibility but have no authority over what they do.  Open offices and cubical farms contain many lonely souls who are accountable and responsible for the business's success but have no say in its operation.  Daily they are asked to sacrifice and be team players.  Bathed in toxic positivity, they stifle emotions and abilities for the business and their careers.  The unspoken rule is saying no to a request from leadership is career poison.  Business leaders need to break this cycle of abuse and mediocrity.  The first step is to give Product Owners the ability to set priorities and say no.  It means that they should be director or Vice President level in the organization and responsible for an individual portfolio of work.  

Listening Skills –

A Product Owner needs to learn how to listen.  A product owner will interact with customers, developers, and executives on any day.   Each interaction requires listening skills that account for what is said and intuiting what is left unsaid.  I continue to struggle with this skill because I feel I can continue to understand better the needs of the people I work with daily.  Not only do you have to understand stated and implied meaning in conversation but communicate it to others.  Having listening skills will separate the great product owner from the good.  It requires taking notes, being transparent, and spending plenty of time following up.  

Diplomacy –

Product Owners will find themselves in situations with a significant power imbalance.  These situations will include unhealthy levels of stress.  A key to survival is being diplomatic when everything goes sideways.  Diplomacy requires you to use "please" and "thank-you" when you want to say something else.  It is factually answering questions when being yelled at over a conference call and keeping your mouth shut.  At the same time, your manager attempts to steer a conversation into a more constructive place.  Finally, diplomacy requires you to let someone reveal they are a jerk instead of personally bestowing that title on them.  Being diplomatic does not mean you are a pushover; instead, you are advocating for your team and yourself in a manner that cultivates the respect of others. 

Product Ownership is a difficult job, but it also is an opportunity to deliver value to the organization in a conspicuous role.  The ability to say no, listen and diplomacy make it possible to be an excellent Product Owner.  

Next time we wrap up. 

Writing Good User Stories

The most important responsibility of a product owner is to write user stories.  It requires focus and skill.  The team members are responsible for completing work, but the product owner makes sure the team has work that delivers value to the business.  Today, we continue our series on healthy ownership by looking at some helpful guidelines on how to write better user stories.  

User stores are the bricks that construct your product and deliver value to your organization.  Together as an assemblage, they are the structure for all the agile team's conversations about the work they accomplish.  Good user stories have two principal characteristics: why the story needs execution and, finally, acceptance criteria that explain success.   

I wrote a blog three years ago which explains my technique of writing stories that I teach to others.  Please take a look at it here.  It features a sentence narrative that I then explain what needs to be done and why.  I do not tell the agile team how I want the work done.  It is because the team members are smart enough to develop solutions.  The team will appreciate the trust. 

Next, I encourage you to author acceptance criteria using the Gherkin syntax.  The simple use of the given, when, then narrative makes it easy for quality assurance people to confirm quality and for the developer to do the work.  Clear acceptance criteria in a given, when, then format avoid mistakes when people attempt to parse ambiguous requests.  Acceptance criteria allow the team to estimate more effectively and split stories.  

Finally, embrace the INVEST model of writing user stories.  INVEST stands for independent, negotiated, valuable, estimated, small, and testable.  These qualities make a user story a helpful nugget of information to help complete work.  

User stories are the bricks that make up the cathedral of your product.  If you create quality stories those bricks will be strong enough to make your product a success.  The architect Louis Kahn famously said, "Even a brick wants to be something."  

Next time the soft skills of a good product owner.  

Using the DEEP Model for Success

Agile has three primary roles, the development team, the scrum master, and the product owner.  Since the authoring of the agile manifesto, the reformation has done an excellent job encouraging the development of craft among software developers.  The reformation has also spent considerable time working on the professional development of scrum masters.  The weak link has been the development of product owners.  Understanding this, I have dedicated most of my career to helping product owners improve.  I call this “healthy ownership,” and today, I want to discuss a portion of what it takes to be a successful product owner; backlog management.   

When I discuss the principal role of a product owner, I say they are responsible for telling the development team what they need to work on next.  A product owner is also responsible for the business, ensuring the customer receives the value.  It is a demanding role that requires diplomacy, expert business knowledge, and a full-time commitment.  

Unfortunately, most organizations do not feel this way and often provide product owners who work part-time while doing other accounts receivable or shipping tasks.  A product owner should also have the authority to say “no” to others but often are subservient to executives.  The minimum requirements for a product owner are full-time commitment to the role, executive-level authority to set priorities and say no, and finally, the ability to work diplomatically with people inside and outside the development team.  It is not an easy job.  

The first order of business is to create a list of work that needs to be done by the development team.  It is called a product backlog.  Roman Pichler wrote a fantastic book on product ownership and scrum entitled “Agile Project Management with Scrum.”  In it, he outlines a helpful framework for organizing a product backlog.  It is called the DEEP model.  It is an acronym which stands for –

• Detailed
• Estimated
• Emergent
• Prioritized

I have discussed these backlog qualities in more detail in previous blogs.  I have included links to the original articles to review at your leisure.  

A detailed, estimated, emergent, and prioritized backlog is a recipe for success.  Estimated stories allow product owners to answer better the question of when work will get finished.  The correct level of detail in stories makes it possible to understand what needs to be done instead of doing it.  Just make sure you treat estimates like an educated guess instead of a quotation; otherwise, you are setting yourself up for unnecessary stress.  Backlogs are emergent because uncertainty around a project decreases when you get close to completion.  Prioritized because if nothing has a priority, then everything has a priority.  Lack of prioritization will transform any project into a carnival of chaos, so you must be sure you are doing things in a set order.  

Using Roman Pichler’s DEEP model is an excellent working guideline on managing work for your Agile team and giving you a leg up on other product owners.  

Next time a discussion on how to write user stories.