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.
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.
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.
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 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.
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
Search for providers by provider specialty.
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.
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…