A Day in a Life of a Product Owner
7:30 am - 8:00 a.m. Attend the daily standup meeting for the team. Listen to the development team share progress and barriers. Share your barriers and progress. Offer to help or collaborate to remove the barriers with the team. Listen for the team’s understanding of value.
8:15 a.m. Prepare for the day by thinking about what you heard in the standup and what will provide the most value today.
8:30 a.m. Review user stories and requirements submitted by others. Analyze where they fit into the value and the roadmap. Determine if they should be added to the backlog. Initiate action to resolve team impediments, reaching out to internal departments, clients, and stakeholders to close the gap for the team.
9:00 a.m. Plan backlog refinement session for the following week. What activities will you facilitate to get the best engagement? How will you ensure the team is focused on value and the roadmap?
10:00 a.m. Catch up on the latest industry and company news. Think about how the events (internal and external) may impact the product, the roadmap, and the release plan. Do the priorities change based on news events, internal company happenings, or industry news?
11:00 a.m. Review and test mid-sprint stories and give feedback to the team. Feedback should be focused on user-centered thinking, design, and will the user value the new functionality?
12:00 pm lunch with colleague, teammates or alone at times
1:00 p.m. Prep for the next day’s story writing session. How will you set the stage and context for a productive story writing session that aligns with the product vision?
1:30 p.m. Meet with the development team to talk about the stories currently in progress. Discuss the context, acceptance criteria details, and factors that contribute to minimum viable product (MVP).
2:00 p.m. Attend the sprint planning session to provide context and minimum viable product information for story estimating.
3:00 -5p.m. Test the latest updates of user stories from the development team. Provide feedback to the team, update the acceptance criteria if needed, move the stories to done, and update comments in the Jira, Rally, Azure for the developers of tester for the next day discussion in the meeting after standup to clear any clouds.
Target group: Health fitness club members on the go
Goal: To get information quickly without making a phone call and to build a deeper relationship with the member
Needs: A mobile app that is easier than calling, emailing, or using a full website to get basic club interactions and information
Value: Faster and more convenient to the club member, and will lower costs for the club
Key features: View Club Information, View Class Schedules, Register for a Class, Schedule an Appointment with a Trainer, and Motivational Notifications for Healthy Living and Fitness Goals
Agile Product Owner: Techniques
Definition of Ready Examples
Business value is articulated and understood for the user story.
User roles and personas for the story are understood.
Enough acceptance criteria are defined for the development team to estimate and commit.
The team agrees they can commit to the user story in a sprint.
Acceptance criteria are clear and testable.
Developers and QA have had a chance to discuss details, alternatives, and design options with the product owner and or BA.
Unknown or risky aspects of the functionality are discussed, and spikes may be defined.
The team agrees the story has feasible design options.
Business rules, nonfunctional requirements, and a lo-fi mockup have been provided if needed as part of the acceptance criteria.
Any dependencies have been identified.
User experience is understood by the team.
Performance criteria and nonfunctional requirements have been discussed.
The team has an idea of how to demo the story and who to demo it for
Definition of Done Examples
The code has been peer-reviewed.
End-user training documentation and help information have been updated.
The story functionality has been demonstrated to the product owner for feedback multiple times.
The functionality has been demonstrated with a larger stakeholder group.
The code has been checked.
The team has documented what was built.
QA has tested the user story and developed regression tests.
Testing and automated test scripts have been completed and implemented into a test suite.
Updated process assets, diagrams, models, and so on have been updated with what was implemented.
Automated regression testing scenarios have been updated and added to the automation testing suite.
User Story Slicing and Splitting: Strategies and Examples
User role or persona
Break a user role into more specific users
Business rules
• Logic (e.g., split out if/then scenarios)
• Detailed definitions and filters
• Calculations and algorithm scenarios
• Decision paths
Scenarios
Various scenarios from a user perspective
Process/workflow
Steps and sub-steps a user takes, sees, or experiences using the product
Role/operations
Create-read-update-delete a part of the workflow for a user role
Data entry
Certain data, or a subset of data, that needs to be present or entered by a user role
Slicing Strategy/Strategy Used
As a member, I would like my online profile information to already be in the app when I log in with my same member ID and password so I do not have to remember more than one ID and re enter data.
Data entry:
Here we are expressing that we expect the user does not have to enter data, and it is already present. This could even be sliced further into multiple stories by splitting the data into smaller groups that need to be present and connected to the users when they log in.
As a premium member, I would like to be able to configure the notifications so I don’t receive
notifications I don’t care about.
Data entry:
This can also be split further by defining each notification configuration attribute as its own story.
For example Types of notifications, phone number or email to notify, time of day acceptable to notify, etc.
User role:
Premium vs. all members—split the user group to try to make the story smaller
As a customer service representative, I would like to be able to see members’ profiles so I can better help them better when they call.
Role/operations:
Different user role specifying if they can create, read, update, or delete information created in another user story
As a member with a spouse on my account, I want to be able to see the total club spending for each of us individually and as an overall account.
Business rule:
Calculations, automated decisions, and policies
Release Plan Release 1
Users can download the app.
Users can create a log-in.
Users can set a default club location.
Users can connect to the club location of choice.
Users can view quick contact info, phone, map, and hours of the club of choice.
Users can view a map of all locations and switch to another location’s details.
Release 2
Users can view free group fitness class schedules for default location by date and time and class and instructor.
Users can switch locations and view free classes for the selected club by date and time and class and Instructor
Release 3
Users can view paid classes for default location by date and time and class and instructor.
Users can switch locations and view paid classes for the selected club by date and time and class and instructor.
Users can click to call to register for a paid class.
Themes/Features/Epics/Stories
The View schedules on the roadmap is a feature or theme.
Example of an epic: As a fitness club member, I need to be able to view group fitness schedules at my
club, so I can decide if I want to go.
This epic aligns with the features in Release 2.
Examples of detailed user stories, breaking down this epic further:
As a fitness club member, I need to be able to view freecycle classes remaining today, so I can decide if I want to go.
As a fitness club member, I need to be able to view freecycle classes at my club tomorrow, so I can decide if I want to go.
The team may use these detailed stories in backlog refinement meetings. They discuss if the stories are a high priority, and then bring them into the sprint planning meeting to discuss more details, estimates, and whether to commit to the stories for the next sprint. They also talk about creating a plan of tasks that need to happen to get these stories completed in a sprint.
Sprint Planning Sample Agenda Items
Remind the team of the vision, goals, roadmap, and value or MVP (minimum viable product).
Describe what is a priority and why.
Discuss any new information that impacts the sprint.
Look at the team’s velocity and determine how much can be accomplished in the next sprint.
Confirm team capacity and availability.
Confirm the definition of ready with the team.
Confirm definition of done with the team.
Develop a sprint goal.
Confirm selected and prioritized stories fit the capacity of the team.
Review estimates and acceptance criteria.
Define tasks and dependencies and create a sprint backlog.
Confirm and discuss any assumptions and concerns.
Commit to the sprint.
Use these terms and definitions below to understand concepts taught in our user story writing course.
Backlog
Prioritized list of what an agile team will deliver
Sprint Backlog
Committed list of User stories by the team to be completed with a sprint
INVEST
Independent Negotiable Valuable Estimable Small Testable; model used to determine a well-articulated user story
Persona
The tool used to represent a user role characterizing the user as a specific
the person that can be empathized with; helps teams focus and discuss how user goals differ from person to person
Product vision
The framework that inspires the team to form a common goal; includes target group, goals, needs, values, and key features
Roadmap
Defines key features and characteristics needed to achieve the product vision
Story map
A visual aid to help the team organize user stories
User stories
Technique to assist teams in understanding exactly what they are building; must include a who, what, and why and the acceptance criteria to help the team size the story
