Joshua L. Roberts

Agile / Lean Enterprise Transformation Coach

Week Seventeen – The Business Vision

By Josh Roberts | September 28, 2014 | 0 Comment

We’ll pick up where we left off in the last post… the Solution Architect sets the technical vision for an Agile Team, while the Product Owner sets the business vision. As illustrated by Agile Transformation Inc, the Product Owner is responsible for maximizing the value delivered by an Agile Team.

product owner

In an enterprise environment, where Agile Teams may support multiple products/solutions, Product Owners are commonly refereed to as Backlog Owners. This is because they partner with one, or more, Agile Teams to keep the Backlog groomed. Remember, an Agile Team’s backlog must be continuously groomed to ensure User Stories / Defects are prioritized and ready for consumption by the team.

In preparation for moving our Agile Teams to Scrum, we have started holding Backlog Grooming sessions every 2 weeks.

BacklogFeedbackLearning

The Product Owner must have a solid understanding of the end users needs and represents those needs to an Agile Team that is responsible for building the solution. They are responsible for the full feedback loop from working with a Business Analyst to define requirements in the form of User Stories to facilitating a demo of a solution’s features at the end of each 2 week Sprint.

The Product Owner is ultimately responsible for accepting User Stories as complete. At the time of writing User Stories, they define Acceptance Criteria for each User Story. From a quality assurance standpoint, the Acceptance Criteria becomes the test conditions. Remember, they are responsible for ensuring the team delivers what the user needs.

tire swing

Since we haven’t spent a lot of time on User Stories, let’s do a quick crash course. User Stories replace traditional requirements and the Business Analyst will work with the Product Owner to write them. When learning about User Stories, I like to start with Ron Jefferies 3 C’s.

  • a “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction:
  • a “Conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation;
  • the “Confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.

A key difference in Agile methodologies is the conversation. A Product Owner must be able to facilitate conversation in the form of user needs, feedback, and team questions/impediments.  It’s an ongoing conversation between all delivery stakeholders.

The main difference between User Stories and traditional requirements is that the focus is placed on the user over the system. In other words, understanding the Why before jumping into the How. The functional/system requirements are typically captured with the Acceptance Criteria. See example below.

Problem Statement
The client has requested the ability to search for health care providers by provider specialty within a doctor selection site.

Sample Requirements Statement:
The provider search screen shall provide the ability to search for providers by provider specialty.

Sample User story
Title:
Search for providers by provider specialty.

Description:
As a provider search user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance Criteria:
The provider search mechanism has the ability to enter a specialty.
The specialty search will have a list of provider specialties from which to select.
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.
If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.

So what are the qualities of a great Product Owner? I think the blog post titled 7 Key Characteristics of a Product Owner does a good job of summarizing what we have covered here. In their words, a Product Owner…

  1. Represents the business
  2. Has a vision for the product
  3. Makes responsible decisions
  4. Influences releases
  5. Provides visibility to business leadership
  6. Motivates tech teams to perform to their full potential
  7. Maximizes business value
TAGS

Josh Roberts

Agile / Lean Transformation Coach

– Passionate About Delivering Value!

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *