Agile practices have transformed the way products are developed and managed, with the focus changing to collaboration, adaptability, and customer-centricity. In this blog post, we’ll explore key Agile practices tailored to the role of a Product Owner, providing a description and example for each concept.
1. MVP (Minimum Viable Product):
Description: MVP is the core version of a product that contains the essential features needed to solve a specific problem for early users. The value of MVP is in getting something in the hands of your customer for feedback as soon as possible. It is also built with the minimum effort and includes only essentials features.
Advantages are early feedback and learning, and faster time to market and risk reduction.
Example: your are getting married, instead of the baker making the whole cake in different flavours, they will make cupcakes of each flavour for you to try and provide your choices on.
2. User Stories:
Description: User stories are brief (2-3 sentences) , non-technical descriptions of a feature from an end user’s perspective. The generally follow the template: As a <user> I want <what> so that <why>. A User story is not complete in the sense that it is a promise to have a conversation later to work out the finer details between the user/PO and the developers.
Advantages: Stimulate discussion on the story, including reasons for requirements and features. Reduces the documentation effort.
Example: “As a mother, I want to be able to order an Uber for my kids s so that I know they will get home safe when I can’t pick them up.”
3. Epics:
Description: Epics are large pieces of work that are then broken down into smaller, manageable user stories.
Example: “Develop log on Screen” could be an epic, broken down into user stories like “As an apple user I want to sign on using my apple credentials so that I don’t have more usernames and passwords to remember. ” and “As a regular user, I want the option to request a my password be reset when I have forgotten it .”
4. User Stories vs. Tasks:
Description: User stories represent features from the user’s viewpoint, while tasks are specific actions required to complete a user story. If your tool hierarchy puts stories and tasks at the same level – User stories can be what delivers value to your customer and tasks are what is required to be done by the team in order to enable the completion of user stories (internal value to the team, no visible value to the customer) Stories are usually sliced vertically and tasks horizontally.
Example: User Story – “View Project Timeline,” Task – “Design UI for Project Timeline.”
or User story “Facilitate workshop on product ownership”, Task “create miro board for product ownership workshop”
5. Story Mapping:
Description: Story mapping visually represents user stories and their relationships, aiding in prioritisation and release planning. It create a visual of the complete user journey and how the product can be developed and built upon to achieve each step in the journey. It also helps to identify what is the minimum that can be developed in order for the user to achieve their outcome. Story mapping is done with all key stakeholders and contains two important anatomical features.
- The Backgone of the application is the list of activities the product supports. (user journey)
- The waking skeleton is the product we build that supports the least number of necessary features. (what the product will do to support the users journey at each step)
Advantages: Useful for different aspects, initial product backlog filling, road mapping, transparency. Enables to understand various users journeys using the product
Example: Mapping out features for an e-commerce app, starting with the homepage and branching into categories, product pages, and checkout.
6. Definition of Ready:
Description: Criteria that a user story must meet before it’s considered ready for development. It is an explicit agreement between team members and the Product owner about when a work can be considered to be brought in to be worked on. Definition of Ready can differ from team to team. Definition of Ready is usually completed as part of backlog refinement or analysis.
Advantages: Transparency, reduction of misunderstanding and conflict, controlled internal quality, PO accountability and increased team efficiency.
Example: Clear acceptance criteria, user personas defined, and wireframes provided, small enough to be able to be worked on in the iteration, estimated and prioritised, Item clearly understood by the team.
7. Definition of Done:
Description: Criteria that a user story must meet to be considered completed. It is an explicit agreement between team members and product owner about when a work items is completed. Can also differ from team to team.
Advantages: Transparency, Clear and common understanding of what is needed for an item to be considered done. Controlled quality.
Example: Code written, reviewed, and tested; UI/UX approved; documentation updated, outcome meets any necessary standards or conventions or laws as required.
8. Bottom-Up Release Planning:
Description: Starting with individual user stories and gradually building up to define releases. – Allows the team to create a forecast based. on their velocity and number of sprints as to when they might complete certain value drops. Best to show the minimum, average and maximum velocity lines on. the chart.
Great image and article here from Project-management.info
Example: Prioritize and select high-priority user stories for the next release based on their complexity and impact.
9. Product Vision Board:
Description: A visual representation of the product’s vision, goals, and target audience. It allows the team to capture, describe and visualise and validate the product vision and strategy.
Advantages: initiates innovation and product discovery, transparency, customer orientation and resource management.
Romain Pichler has a great canvas here
10. Business Model Canvas:
Description: A strategic tool for developing and documenting a business model. A good approach to sketch out new business ideas in an iterative approach.
Advantages: Transparency and traceability of relationships, customer orientation, documentation and competence focus.
Example: Using the canvas to outline key elements like customer segments, value propositions, revenue streams, and cost structure. – Template available here at www.strategyzer.com
11. Personas:
Description: Fictional characters representing different user types and their needs. Describes a representative of a cluster of users concerning their needs, characteristics and behaviour. Its a fictional person with name, personal background, personality, goals, skills, painpoints, challenges, and wants. Personas should be placed so they are visible to. the team and used within user stories. They help the team keep the users needs and painpoints in mind.
Advantages: improves understanding of target group. avoids feature over engineering and improves the product quality.
Example: “Tech-Savvy Sarah” – a young professional seeking advanced features in your software.
12. Backlog Management:
Description: Continuous refinement and prioritization of the product backlog. Choose a prioritisation method that ensures the team are working on the highest value items for their customer and stakeholders. The Backlog should be the ever evolving, living list of everything that is required for the product. It needs to also align with the product strategy.
Example: Reviewing and updating the backlog during regular sprint reviews, actively using during sprint planning and the backlog refinement sessions.
13. Estimation (Story Points or Planning Poker):
Description: Assigning relative sizes to user stories to estimate effort and complexity to complete the work. Key areas to consider are amount of work, complexity of work, any risks or uncertainty. Story points are relative, not absolute. Everything needed to take a story to done is estimated. Story points should not be related to hours.
Planning poker activity link here from Mountain Goat Software. Planning poker is performed in either planning or Refinement. It enables a consensus orientated estimation of work. The Dev Team estimates size of upcoming items. Each member uses a fibonacci (or Similar) numbered card set. Privately they select a card representing their estimate and once all cards are placed face down, the team turn them over. High. and low estimators explain the reason for their estimates. After discussion, next estimation round is run until there is convergence of estimates.
Advantage : agree on estimation across the team, easier and faster estimation, manages risk. Planning Poker is fun.
Example: Using planning poker, the team estimates that a user story is a 5-point task.
14. Data-Driven Metrics (Burn Up/Down Charts, Velocity):
Description: Using data to track progress and predict future performance.
Burn down / Burn up – graphical representation of current state. Used vs remaining work over time. Can provide a warning that the sprint goal will not be achieved or identify where work in being added to the team without being prioritised first.
Velocity = #of story points the team completes during a sprint. You cannot compare velocity between teams and each team is different. Velocity is best used for forecast planning and also during planning to challenge the amount of work the team is committing to for the increment.
Example: Tracking sprint burn down to visualize how much work is remaining.
15. 3 Amigos:
Description: A collaboration between the Product Owner, Developer, and Tester to ensure shared understanding of user stories.
Example: In a grooming session, the three roles discuss a user story to clarify its requirements.
16. Role Responsibilities to the Wider Organization:
Description: The product owner has a responsibility to engage in collaborative activities in the wider organisation. These broader Agile practices are focussed around creating transparency and highlighting risks and dependencies and impediments. It is a way of scaling Agile practices across teams and improving planning and alignment.
Examples: Scrum of Scrums – Regular meetings to coordinate between multiple Scrum teams; Increment Planning – Collaboratively planning increments to ensure alignment with the larger product strategy; OKRs – Defining Objectives and Key Results to measure progress toward product goals.
Conclusion:
In the dynamic world of Agile product development, these practices serve as a robust framework for Product Owners to guide their teams in building valuable products. By incorporating these concepts into your teams, you’ll empower them to work cohesively, respond to change effectively, and deliver customer-centric solutions.
