Agile Scrum Product Owner Masterclass | Danny Liu | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Agile Scrum Product Owner Masterclass

teacher avatar Danny Liu, Creating digital products the agile way

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

31 Lessons (1h 29m)
    • 1. Complete Product Owner Intro

    • 2. Why Product Ownership is Hot Right Now

    • 3. Agile Responsibilities and Course Outline

    • 4. The Agile Challenge: Incremental Value

    • 5. Discovering Incremental Value

    • 6. How the PO Fits Into The Team

    • 7. Attributes of an Agile PO Video

    • 8. Waterfall vs Agile The Old Way

    • 9. Waterfall vs Agile The New Way

    • 10. Waterfall vs Agile The Agile Divide

    • 11. Waterfall vs Agile The FORCE of Scrum

    • 12. Waterfall vs Agile The Basic Agile Scrum Framework

    • 13. Waterfall vs Agile 4 Quadrants

    • 14. What is an MVP? Let's Build a Rocket Ship

    • 15. Definining the Bank Buddy 1.0 MVP

    • 16. Developing a Sound Product Vision video

    • 17. Understanding User Personas

    • 18. Identify Clear user roles

    • 19. Persona Exercise Example

    • 20. The Product Backlog at a Glance

    • 21. Epics, Features & User Stories

    • 22. I.N.V.E.S.T in Creating Great User Stories

    • 23. How to Prioritize the Product Backlog

    • 24. Assignment 2: Create an Epic and Supporting User Stories

    • 25. Exercise Explained: Creating User Stories

    • 26. Release Goals, Duration and Key Players

    • 27. User Story Mapping for Release Planning

    • 28. Release Planning and Roadmap Examples

    • 29. Tools of the Trade

    • 30. Dive Deeper into Design Thinking

    • 31. How to Get Product Owner Certified

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

How to Plan, Build & Launch your Agile Products as an Agile Product Owner or Agile Product Manager

You’ve just stumbled upon the most complete, in-depth Agile product owner course online.

Whether you want to:

  • Build the Agile skills you need to transition into an Agile product owner role

  • Understand how to develop amazing software and digital products the Agile way

  • Learn how you can stand out in your role as a developer or tech lead in an Agile company

  • ...or just learn what it takes to build valuable products using agile product owner techniques

...this complete Agile Professional Scrum Product Owner Masterclass is the course you need to do all of this, and more.

Are you aiming to get your first Agile Product Owner job but struggling to find out what skills employers want and which course will give you those skills?

This course is designed to give you the Agile product owner skills you need to get a job as an Agile Scrum Product Owner!

By the end of this course you will understand what it takes to be a successful product owner, leading high performance scrum teams to build amazing digital software products and services.

Your time is valuable... I respect that.

The course has been carefully developed to only give you the essentials you must know to become a successful product owner. No Fluff...Not just boring theory... No wasting tens of hours of time learning abstract concepts that won't help you in the real world as a product owner.

You will learn how to actually start building a real product backlog for a consumer banking application using the techniques taught in this course.

Time is money. That is why you don't need an 80+ hour course!

Why should you choose to learn becoming a product owner?

In today's global digital marketplace, software and digital products are in high demand.

And, as a result, jobs as a product owner are in high demand and learning the skills to become a product owner will give you the edge in your career, even if you aren't a product owner but want to understand what it takes to build products using an agile approach.

Will this course give me core product owner skills?

Yes it will. While this course isn't about getting a certification, understanding the concepts here will help you land your next job as a product owner and may strongly give you the skills to make getting certified much more easily.

Why should you take this course?

This course assumes no previous product ownership experience and takes you from absolute beginner core concepts, like showing you how a product owner fits into an agile scrum team, to writing your own epics and user stories to develop your product. You will learn the core product owner skills you need to become job ready in just under a couple hours, and if you choose to, can take advantage of all the additional content in the course to build upon what you've learned.

It's a one stop shop to learn how to become a complete product owner. If you want to go beyond the core content you can do so at any time.

Here’s just some of what you’ll learn

(It’s okay if you don’t understand all this yet, you will in the course)

  • All the essential agile scrum keywords that will help you understand the dynamics of an agile scrum team

  • You will learn the answers to questions like "What is a product increment?", "What is a sprint?", "What is a retrospective and how does persona creation and user story mapping help me release minimum viable product releases?"

  • Which industry standard tools should I become familiar with?

  • And much, much more!

Is the course updated?

It’s no secret how technology and product development are advancing at a rapid rate. Strategies towards delivering digital products in a more streamlined way are changing and improving every day.

A lot of other courses on Udemy get released once, and never get updated. Learning older concepts on product ownership can be counter productive - you could will be learning the "old way" of doing things, rather than using current best practices.

Make sure you check the last updated date on the page of any course you plan to buy - you will be shocked to see some have not been updated for years!

That’s why I’m always adding new, up-to-date content to this course at no extra charge. Buy this course once, and you’ll have lifetime access to it and any future updates (which are on the way as we speak). I use the same strategies I teach as a product owner in my own course to help add new content based on feedback from awesome students like you.

I've done this with my other classes and expect to do the same with this one.

With this complete Product Owner Masterclass, you will always have updated, relevant content.

What if I have questions?

As if this course wasn’t complete enough, I offer full support, answering any questions you have 7 days a week (whereas many instructors answer just once per week, or not at all).

This means you’ll never find yourself stuck on one lesson for days on end. With my hand-holding guidance, you’ll progress smoothly through this course without any major roadblocks.

There’s no risk either!

This course comes with a full 30 day money-back guarantee. Meaning if you are not completely satisfied with the course or your progress, simply let me know and I’ll refund you 100%, every last penny no questions asked.

You either end up with job-ready product owner skills, go on to lead development teams to create great digital products and services and potentially make an awesome career for yourself, or you try the course and simply get all your money back if you don’t like it…

You literally can’t lose.

Ready to get started product owner?

Enroll now using the “Add to Cart” button on the right, and get started on your way to become a complete agile product owner... Or, take this course for a free spin using the preview feature, so you know you’re 100% certain this course is for you.

See you on the inside (hurry, product owner jobs are filling up!)

Who this course is for:

  • This course is perfect for absolute beginners with no previous product owner experience, to intermediates looking to sharpen their skills to become better product owners and managers to develop great digital products

  • Those looking to build creative and advanced digital products for either personal or corporate use or for high-paying clients as a self-employed digital entrepreneur.

  • Those who love collaborating with other brilliant minds to deliver great digital experiences.

Meet Your Teacher

Teacher Profile Image

Danny Liu

Creating digital products the agile way


Hello, I'm Danny.

As a busy father of 5 little ones and a full-time Agile leader, I know the importance of being productive while maintaining a healthy balanced family life.

Each course is focused on helping you spend less time consuming content and more time TAKING ACTION towards achieving your personal and professional goals.

As a seasoned 15+ year career technologist, I've led high-performance teams, ranging from technology infrastructure engineering design & support to modern day cloud computing and web development. 

As an Agile Certified Product Owner, Scrum Master, AWS Developer Associate  and Lean Six Sigma practitioner, I'm passionate about all things tech with a focus on productivi... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Complete Product Owner Intro: Hello and welcome to the complete Product Owner course where you're going to learn how to plan, build and launch your digital products using product ownership. The agile way My name is Daniel you. And over the last 15 years I spent working in a variety of technology industries, focusing on creating digital products and high performance teams at scale. I'm also a father of three boys and a new baby girl, and I'm a huge tennis fan. So when I'm not working, you can find me watching the 80 p tour or hitting walls on the test courts. But let's get back to why you're here. In this course, we're gonna cover why product ownership is such an amazing opportunity for folks looking to get involved in digital product creation in today's global marketplace. Let it dive in on some of the core concepts that make a successful product and how you can leverage those tips, tools and strategies to become a complete product owner. Well, then top it off by tackling some hands on exercises where you'll create the product backlog for an application called Bank Buddy App. We'll go through the ideation, persona identification and use the story mapping exercises to create epics and stories will also cover some of the best in class industry standard tools for building your products and services. And they will cover a bonus lesson where if you're stuck with me so far, you get exclusive content to help you further your journey into becoming a complete product owner. 2. Why Product Ownership is Hot Right Now: So why product ownership? What is a product owner and why should you become one? In today's global digital economy, software is at the heart of practically everything we dio from mobile devices toe home automation in e commerce, jobs in the technology error here to stay, ensuring product owners have a spot in the winner's circle. So if you're passionate about leading the charge to create great products and being the bridge between technology problem solving and human centered design, you're in the right place. According to the U. S Bureau of Labor Statistics, they've reported a 12% growth for computer and information systems managers during the period of 2016 to 2026. This job growth is faster than average for all occupations. In November, 27 teeth payscale dot com reported average annual salary of over $81,000 for certified scrum product owners, And many of these today break the six figure mark on average. Additionally, Google trends show searches for product owners are on the rise for over the last five years 3. Agile Responsibilities and Course Outline: So what are you looking to launch the next hot social media APP software. As a service or physical products? It's your job to bring the vision toe life in the form of amazing new and improved existing products. And soon you'll quickly discover that this is a very cyclical process. As a product owner, you are responsible for prioritising the development of features for your customers to deliver consistent, incremental value in the form of a working product. And you'll execute this by doing three key responsibilities. First is inspiring the team with the overall vision off the product. Next, continuously refined, prioritized and maintain the product backlog and obtained feedback on product and alignment with customer expectations on future generations. Just remember, it's all about your product. It is all about your customers here, the core topics covered and what you're going to learn. So the first section we're going to talk about the product ownership challenge and some of the things that keep in mind when you're tasked to build a new product or improving existing one. In Section two, we'll talk about the scrum basics of agile and how you, as the product owner, will fit into the team Well, then go in to discuss waterfall versus agile and how we've come from a traditional project management approach and into the modern era of product management. And some of the key benefits that agile brings to the table will also dive into what makes a successful product owner and how you can leverage those attributes to apply in your situation. Well, then, talk about developing a sound product vision. One of the key components of ensuring that you have a successful product is ensuring that you can align that vision with the expectations of your customers. And then in Section six, we'll talk about some of the industry standard tools to help you track your projects and deliver continuous value. And unlike many courses out there, what we're going to also cover are some hands on learning activities so that you can actually build a prior times backlog and get some product ownership experience. Once you complete this course 4. The Agile Challenge: Incremental Value: the product ownership challenge. Delivering products is no easy task, regardless of whether you're building brand new products or improving upon existing ones, Being able to embrace agility is an integrative, intuitive and continuous journey. And it's going to really come down to both your company and team culture on how well you're able to deliver working products in the most efficient and effective way. And this happens through a cyclical process called the build measure and Learn process. The first phase is building, and when we build value incrementally, this allows us to see how every change impacts are key performance indicators. And it's those key performance indicators that become so crucial to our measurement process . By comparing the empirical data that we get from our product, we can make decisions faster to get back on course. So that data, maybe the feedback from your user community do they like your product? Do they not look your product? What are some things that are missing? This will enable you to learn much more effectively and leverage continuous improvement on an ongoing basis based off the feedback and data that you get for your product. One of the big challenges is maximizing this learning while minimizing the risk and cost. Being agile enables us to do this in a much more intuitive and incremental fashion. But there are several inputs, tools and outputs that really help in driving your efficiencies through building, measuring and learning. And so some of those in pits might be in the form of key product objectives. They also may be user experience persona research, and it's these things that will help you identify what your hypothesis is. Identify your risks and challenges and some of the data that comes out of going through this process to feed back into the next iteration. And so the tools that we use to help us through this is we can use hackathons innovation tournaments where we can get our scrum teams together. Our developers together or product builders together toe help, collaborate and identify different ways to build new features or improve existing ones. We also have designed sprints that designers can come to the table in taking some of the data and feedback they've obtained through user experience and persona research to help identify usable designs to build and get feedback on also reasonable assets. So maybe We're trying to build an application that integrates with a payment gateway and instead of coding from scratch, maybe there are AP eyes that we can leverage and integrating with our application, as well as shopping carts and other reusable assets that will help us increase our speed to market and outputs in the form of validated feedback, prototypes, user stories. I knew information that we've obtained through our inputs on our tools to help further refine our vision based on feedback and taking that work into future sprints so you can see there's a lot going on and the challenge to create incremental value on a consistent basis remains high. So how do we find a way to create incremental value as early and often? It's possible. Well, first we have to understand what an increment is versus an iteration. Sometimes these terms get a little mixed up, so let's set the story straight. An increment is the sum of all product backlog. Items delivered is done from an iteration also known as a sprint, and in your sprint. The goal is to add value to the previous product increment. Creating a potentially releasable new increment or version building on to existing features or removing them as part of the increment. So we can see here. According to my cone scrum and agile are both incremental and iterative iterative and that they plan for the work off one sprint to be improved upon in subsequent sprints. They're incremental because be completed. Work is delivered throughout the project, and it's up to you as a product owner to determine whether the increment is potentially ship herbal to your customers. 5. Discovering Incremental Value: as a product owner. Discovering incremental value is critical to the success of your product and is not only the key to delivering just in time value to delight your customers, but it also is critical to maintain an advantage over your competitors. And to make this happen, we're going to need to understand several things. So our inputs, the user stories that we have in our backlog, the wire frames and prototypes that we've built as well as existing product increments will help us as we work through our sprints to identify what the next ship herbal product increment will be. And some tools to help us with determining our direction come in the form of con bond. So how we are limiting our work of progress as well a scrum. How we're time boxing are iterations into 1 to 4 weeks prints so that we have a goal of producing a particular product increment as well as leveraging develops best practice between development and I T operations to help us get to market faster and also harnessing some of the power of extreme impair programming so that we can close any gaps in the learning process of how our product is being built across team members and by leveraging these tools will be able to effectively and efficiently identify what some of those key outputs are in the form of release herbal working and valuable products, but also enable us to fail fast and often to determine whether or not we're hitting the mark with our customers and our business stakeholders, so that we can quickly get back on track if necessary. So let's go over an example of incremental value in this demonstration for a bank buddy Mobile app called Bank Buddy version Juan Dato. On the screen, you can see there are four increments. Each increment is thes some of the work completed in a sprint. And so with increment one, we have three stories within Sprint, one that will build the register and log in functionality for our application in Sprint to we have two stories that are gonna build upon our first increment and add the functionality of being able to add a back account. Then in Sprint three, we have four stories that our goal is to create 1/3 increment that will build upon our previous to increments that will add the ability to pay my bill and then in the last increment here, we've got three stories in Sprint four that are going to add to our previous three increments so that we can download our statements. So while this is a great representation to understand how it orations and incremental value can work together, the challenges trying to really provide a working increments, every sprint. And so don't be alarmed if you're not creating any something that's, releasable every sprint, the idea and the goal is to work towards that. And through ceremonies such as retrospectives, we can look back on our sprints to be able to identify improvement opportunities to become more effective and building releasable product increments. 6. How the PO Fits Into The Team: as a product owner, it's important to understand your role and how you fit into the overall scrum team to deliver awesome products. There are three key stakeholders that need to be included and what we'll call the circle of excellence. This includes your customers. I mean, without them, we wouldn't have a reason to be creating a product. We also have the business and any other teams that may be interfacing with your customers. And then there's the scrum team, in which you'll help prioritize the product backlog to deliver products and services. In the incremental fashion that we covered in previous lesson, ensuring that you have these three key stakeholders in mind, you'll be able to bridge the gap between business and customer requirements as well as the technical requirements that need to be considered when delivering your product. So here's some of the roles of Scrum and the product owner. The product owner is essential responsible for the vision any of the work that the team works on the product owner has the power to accept or reject the work based on the acceptance criteria, whether it's been met or hasn't the rock donor also is responsible for any trade off decisions. Since business priorities can change very quickly, trade off decisions can be made by the product odor to focus on what the true priorities are at that given point in time. One of the challenges with bringing work in the middle of a sprint is being able to make trade off decisions so that we don't overload the capacity of the team. The product owner also will help to find the features along with this from team lead, the release planning and adjust along the way based on feedback from the three key stakeholders we mentioned before the scrum Master coaches and protects the team helps lead the daily stand up and the sprint retrospectives is responsible for removing any impediments that keep the team from continuous delivery as well as ensuring that the overall agile scrum process is followed and really acts as a coach to help support collaboration across the team and then the scrum team is responsible for creating the detailed plans. So here's where the strategy meets execution. The scrum team estimates the story points for each of the stories in the product backlog and attends a daily stand ups to provide status on what they've completed the day before, what they're working on, as well as any impediments that need to be called to the scrub masters attention. They're also responsible for the execution delivery of features, as well as work directly with the product owner on an ongoing basis to demonstrate the product being built, as well as being a team that self manages within sprints. 7. Attributes of an Agile PO Video: So let's talk about the attributes of a product owner Now. It's crucial to understand what the's are because one of the biggest analogies that a lot of folks use to describe what a product owner does is this idea of being a unicorn in the development space. Unicorn is essentially someone who's, ah, full stack who could do everything under the sun. They no front end development back in development. Ah, they know how to do user experience, design and just all the whole gamut of things. And so this can be a misnomer and a misrepresentation of really what it means to be an ideal product on her, because what we're looking at is not necessarily something that's mythical and can not be found or rarely be found. But really, what are the things that we need to fully understand and take ownership of in order to be a successful product owner? So some of the things that come to mind are being available to your team also being qualified in the domain that you're representing. So whatever industry represent whatever product solutions, your building for that industry, also being empowered to make decisions on feature privatisations as well as when you're going to release a to production. These were some of the key core attributes, and there's a lot of other things that kind of roll up to these three, and we'll dive into some of those other areas as well. But first, really, what you want to be instead of a unicorn is a jack of all trades. And so a jack of all trades are essentially going to be. You're going to understand ah, lot about different areas and different domains within your space to develop and deliver a working product of value. And while you don't need to be an expert at, say, back and development or at user experience design, you do need to have a solid understanding of all of these areas in order to succeed. So I like to say you're jack of all trades and a master of one, and we'll get to what that master of one is. But first, let's dive in to some of these areas so empowered. We talked about a powered being possessing the authority to make those decisions on feature privatisations and release management. As a proctor, you have to be qualified in the proctor mean you represent and the available solutions options so that you can speak to those in a coherent manner across stakeholders. And when doing this, you'll be able to instill an inspiring vision for the team. After all, you need to have a solid understanding of the playing field in order to be able to put that vision together, and you'll also be able to maximize the speed of learning and value Tillery. Then we talked about being available and dedicated to the team with ability to stay focused and to quickly get team feedback to the team from various stakeholders, users and customers so that the team can remain agile and continue. Develop incremental value based on real needs and requirements. And some of these bullet points below sort of overlap and fallen sent to these top three key categories, and some of that is the ability to speak tech. One of those things that can trip up a lot of new product owners is not really understanding the technical aspects of things and some organizations is very important because you need to be able to understand if you let's just say you're delivering products , Andy, Amazon or the Google Cloud platforms. You need to be able to understand how your teams are delivering the technology to production, at least at a high level, to be able to speak on terms such as continuous development, automated test driven development and some other areas of technical jargon that will help you process and understand what is actually being done to deliver on business and customer expectations. Now it's all about collaboration and teamwork. I know we've said this before and will continue to say that again because it is that important, great product donors work with others to irritably plan, refine and execute on those requirements. So when we talk about working with business analysts, user research and design experts, developers quality analysts, I put where applicable here because depending upon your organization and how your structured, you may have quality analysts that run test cases against code that your developers, right and based off of those results work on deporting things to production. But there's a lot of different nuances to it. We won't dive too deep into it in this lesson, but there are some development teams that right their own test cases and doom or automated quality baked into their development practices. But again, it's us a product owner that need to understand these nuances so that you understand what it takes to deliver real working product, using the technology and processes given to you and your team. So some of the things around business and out analysts is being able to elicit user needs and have conversations with the business analysts to take those user needs and be able to relate them to your user experience research and designers. And is that data from the business added lists that you want to use to help your user experience research and designers and your developers within your scram team. Teoh. Start working on wire frames to start coating solutions and deliver those incrementally so we can run the necessarily quality tests that we need to against those releases and provide working software to our customer base so that they can give us feedback toe further, enhance the overall quality of the product based on user expectations, and be able to modify our design and our code to meet those expectations. This will help you become Go back to our jacks here, a master of one and that is a master of product management by collaboration and bringing all of the various data points and communication sources together toe build a working product in the least amount of time it's possible. 8. Waterfall vs Agile The Old Way: welcome back in this lesson. We're going to discuss waterfall versus Agile and identify some of the key areas that makes agile stand out above the competition. As a product owner, it's important to understand where we've come from so that we know where we're going. In traditional project management, the waterfall process has become a staple, and there are some key things that will prevent you to build a successful product in today's fast and competitive marketplace. And so we'll identify what some of those risks are. So with wonderful process, we look at risk as being higher, using a big bang, all or nothing approach. The work also flows through specialized stages and teams, so that learning can be stifled when following this approach. Projects can also take months or sometimes even years, to deliver working software to the customer. And as a result, scope creep becomes a huge problem as a product just gets bigger and bigger and bigger with requirements before we actually build anything to deliver to customers. So let's take a look at this another way. This diagram shows us what the waterfall process looks like, and how the work flows from the various stages from requirements to designing to building and implementing the product, as well as moving into the verification, testing and feedback phase. All the way to you were maintenance. Once you've built a product and have the product out there, now it's in more of a maintenance mode, will have to take everything back to the requirements and start all over again. The challenge with this approach is that you can see as work flows down through the waterfall from stage to stage could be much more difficult to go back to previous stages and swim upstream as we've already built a large solution that may take longer to debug we may need. We may have a big large code base that we've built over a year, six months to a year or longer, and now we've got a kind of pulled apart. And meanwhile all of this is happening before any value is actually delivered to the customer. So not only does this delay our speed to market, but it also costs a lot of money and time and being able to determine what our products should look like 9. Waterfall vs Agile The New Way: so that we've seen the waterfall process. Let's take a look at the new way for product delivery using an agile approach. The risk is lower because we're building products and delivering them in smaller increments . We're also working in an intuitive fashion, so we're able tohave faster learning cycles and improve at a much more rapid pace. And because we're delivering smaller components of value at a sustainable pace, were able to reduce the delivery from months or years to as little as several weeks, Therefore, helping get the valuable feedback that we need from our user base to continually improve the product over time. And in today's marketplace, that couldn't be more crucial to ensuring that you have a successful product in successful business. 10. Waterfall vs Agile The Agile Divide: So let's take a look at the agile divide. Agile is itself describes a number of related methods within its overarching landscape. And so we're looking at Here is a chart built by the State of agile Development survey from COLLAB Net and Version one, and they've been doing this survey for quite some time. After 13 years. Crime continues to be the most popular methodology being used by organizations, out of 64% out of all other agile practices. 11. Waterfall vs Agile The FORCE of Scrum: when we take a look at the five values of Scrum were able to see the real force, an impact that scrum can make, which is no surprise why it's has such a wide adoption rate. The first is focus because we have focused only on a few things at a time were able to produce excellent work and delivered sooner. The next is openness because we're able to discuss how we're doing and what's in our way so that concerns can be rapidly addressed. We foster in open atmosphere and thirdly, respect as we worked together, sharing successes and failures would come to respect each other and help each other become worthy of respect as well and courage. Because we don't feel alone, we feel supported. This gives us the courage to undertake new challenges and, lastly, a sense of enhanced commitment. Because we have control over our own destiny, we become more committed to success 12. Waterfall vs Agile The Basic Agile Scrum Framework: When you apply these five values into the agile scrum framework, you have the ingredients for a high performance team. So let's take a look. As a product owner, it's your job to maintain the product backlog and to prioritize the most highest priorities in order for the team to take on the work. Then, once those priorities are identified, were able to slot those items into the spread backlog so that when we start the next sprint , the team is able to iterated, pull that work in and produce a working product and, through daily stand ups, talk about what they've completed since the previous stand up what they're working on currently, as well as identify any issues or impediments that are preventing them from reaching their Sprinkles. And as a result, the goal is to produce a potentially ship herbal product increment that you as a proctor can determine whether or not to release to production based on the acceptance criteria and other factors that may impact your decision to release customers 13. Waterfall vs Agile 4 Quadrants: so the summer as the key comparisons between agile development and waterfall development. Let's take a look at these four quadrants of business value. Risk, adaptability and visibility will highlight the difference regarding the value proposition of these methodologies and how agile development tends to deliver business value. Visibility and adaptability in the beginning stages of a project reduces a lot of the risks during the project delivery. In regards to business value how quick we can get our product to market, what kind of minimum viable product are we looking to produce and obtain early feedback on ? We're able to provide business value at a much faster rate because we're releasing early by R. M v P and obtained feedback in future generations to be able to increase the value our stakeholders expect, whereas in a waterfall, value is realised later on in the project. Once each of the requirements designed, building phases have been completed until we actually ship the product to our users and production. Next is risk, and the risk of our project reduces through frequent shorter development cycles in an agile sense so that we can gain important customer feedback and testing along the way. where is with a waterfall approach. Risk remains high throughout the project because of scope creep, because we don't deliver sooner rather than later to make adjustments along the way. Next up, adaptability, agile projects and teams can easily adjust to changing requirements with shorter increments , allowing us to refocus and re prioritized based on changing business needs, or is in a waterfall development process. We start off with a scope and over time, our ability to adapt to that scope. Changes do that in the nature of the structure of our process and our teams and finally, visibility. By leveraging an agile approach, we can maintain high visibility at any stage because of our narrative development and shorter feedback loops. This is dramatically different from the waterfall approach, where we start off with high visibility early on in the project. But as the project continues, visibility starts to decrease until we start getting close to delivering our product to market 14. What is an MVP? Let's Build a Rocket Ship: one of the biggest challenges as a product owner is understanding what an M V. P is for your product and how to get it launched as quickly as possible so that you can get feedback from your customers to incrementally improved over time. So what is an EVP? An M. V. P stands for minimum viable product, and it is something that is released, worthy and usable. And it is a point in your product where minimum value can be realized by your customers if you so choose to release the product so that you can get incremental feedback and improve it over future iterations. So let's look at the example of building a rocket ship. But first, it's important to identify what an M V. P is not so that we can fully understand the differences between how do we develop incremental value over iterations of time and when we determine we have a minimum viable product to release to our customer base. So in the first step here, we're taking a look at incremental value that was being delivered over a sprint or multiple sprints. You can see we may not have a fully working product just because we've added value in the form of building our rocket ship wings. This isn't necessarily something you consider an M V P. Because we can't really use it just yet. And in this example, you can see well, you know, we do have a rocket ship, but there's still no propulsion. And therefore, even though someone may be ableto hoppin, we're not going to really get anywhere. In this example. You can see that we do have one rocket. However, it looks a little imbalanced and so begin. Is this something that is usable to your customers? You as a proctor, nor have to determine that. And in the last phase here, we can see. Okay, now we do have something that is fully usable and can be released to get feedback on to see what improvements we can make over time. So let's take a look at what an M V P may look like. Using the rocket ship analogy. An M V. P could be just a small version of your rocket ship. It has a very basic engine, and it's conceit. One passenger Understanding your requirements is one of the most important determining factors on defining the scope of what your M V. P will look like we can see here. The rocket ship has a little bit more thrust, a little more power in the engine, and it's a little bit bigger so we can fit multiple passengers. In this example, we've got an additional rocket booster. So if we did our market research correctly and we determine that the goal is to reach Earth's orbit well, the 1st 2 examples may not get you there. You don't have enough rocket power, and that's something that's going to be needed in order to get the rocket ship to that level. And in the last example, you can see here, similar to our last example above. This is a fully functional rocket that could get us into outer space, where your M V P falls within this range is going to be determined by what your market research tells you. What is an acceptable minimum set of functions features that will deliver the value that your customers expect and be able to get their feedback so that you can improve the product over future iterations? 15. Definining the Bank Buddy 1.0 MVP: So let's take a look at our bank buddy version 1.0 product release in here you can see similar to our rocketship example. We do have some bits and pieces that have added functionality to the application. However, again looking at what is our market research Tell us that our customers want out of a minimum viable product that they can actually use and receive value from so increment one. We may have three stories that help us build a register and log in component to our application. However, that's not really providing any value because as a banking customer, there's nothing else that I can dio in increment to. You can see we have adding a bank account. And while we're adding it some additional functionality to the application, adding a good bank account does not allow me to do anything else. An increment three we're now building and seeing more of our application take toe life. Now we're able to pay our bill by using our bank account that's actually linked to our registered account in the application and an increment, for we're adding an additional ability to download statements so we can take a look at some transaction history so that I can better manage my finances within the application. As a product owner, it's up to you to make that call on when you're going to deliver that value to production. Maybe it's increment three so that you can get your users to start paying their bills, because that is the most important function for your application or based off of your persona research and taking a look at your competitors. Maybe you wanna wait until you have a few more smaller pieces of functionality so that you can deliver that and seek more valuable feedback. Now again, this is a fine line that you have to balance between Wendy release sooner rather than later , so you can hit that sweet spot on delivering a minimum viable product. 16. Developing a Sound Product Vision video: every successful product starts with a compelling vision. And I really like this quote from Jeff Bezos, the founder and CEO of Amazon, and his be stubborn on vision but flexible on the details. So as a product owner, your main focus is to play the visionary role in helping development teams execute on that product vision. So don't get caught up in the technicalities. That's not to say that you don't focus on the acceptance criteria and making sure that that's met. But as a proctor, you shouldn't be trying to determine if you're developing software, what language it should be written in, or what sort of Delap's tools should be used things like that. So let the teams figure out the how, and you focus more on the end result. And by doing that, you'll be able tow, stay focused on being more of a visionary and bridging the gap between technology and product and the customer experience, then getting caught in the weeds with micro management. So that said, there are two things that we want to think about when developing a sound product. Vision number one is what kind of customers will you serve? It's important to know the customer profile of who you're serving so that you can align the product with the right fit, the right market fit so that your customers will actually have this more closely aligned relationship with what you're offering. The next thing is what Proxim services will you offer. Okay, so again kind of tying into the customer profile that you're going to serve, you'll then be able to better refine and define what products and services you're going to be able to offer. And let's get one thing straight. Developing a product vision is hard, but when you have large teams and you work in a large, scaled, agile environment where a corporate or corporate culture, it's important to be able to assume that visionary role and not get stuck in the weeds. Now, when you're working in more of a startup environment, a small team environment, you may need to wear multiple hats, and in that case, depending upon the nature of your product ownership role, you may need to have a little bit more technical or understanding or a little bit bill of more tech savvy and being able to help make certain decisions around some of the tools to help you deliver faster. But that said, developing and owning the vision is going to be key for you to be successful as a product owner. 17. Understanding User Personas: in this section, we're going to talk about personas and avatars and how they enable you to model your customers and users and map out your customer journey and the most efficient and effective way. So what is an avatar? What is a persona? Well, they're essentially one in the same thing. Persona is a personal profile of your user, someone who interacts with your software. This maybe, in the case of our bank buddy app, maybe a small business owner looking for a way to manage receipts and expenses. Or it could be a single mother who is just looking for a quick way to access her online banking information. Whoever your avatars are, it's your job as a product owner to identify what their deepest needs are so that you can develop a successful product. So whether you're building the next online take out delivery app, toe help hungry eaters order quickly and get their food fast or create the next hit sensation workout app. Identifying your user personas will help you identify what your goals are in a clear way and ensure that when you deliver your software to your customer that there is a goal in mind for that persona. So let's dig deeper into personas when you were creating our personas. We want to make sure that we provide a name, a face and tell a story for each customer and user. This is really going to get into their actual psychological needs, physical needs, all of the types of things that will come out as to why they want to use the product in the first place. And sometimes lightweight percenters can can work for most situations, but it's a starting point to ask more questions. So if you feel like you've gotten enough information in your ideation phase, that may work for your particular situation. Also, empathy helps guide planning and design decisions. So it's important to keep that in mind when you were making prioritization decisions on what features will get launched before others and the last point here research by observation and interviews. This is really critical because you need to make sure that you are really paying attention to what you're getting in the form of verbal research when you whether you're interviewing someone in person or remotely, or maybe it's just the survey data that you're getting back from Surveymonkey or some other online tool to gather customer data. It's gonna be important that you observe some of the trends that your users air facing toe , identify high key problem pain points. 18. Identify Clear user roles: in this section, we're gonna talk about identifying clear user roles and creating your avatars and personas . Identifying clear user roles is going to ensure that you're able to stay aligned to what your goals are for your particular customer journey. So in this case, we have a restaurant ordering persona creation. And it's here that the context of all the information is going to really drive the way that we're able to have a successful design sprints. And so we see the context and information key responsibilities for this restaurant owner persona. As a restaurant owner, I run a busy family owned restaurant six days a week. The characteristics, behaviours, attitudes and interactions of the restaurant owner is that I rarely use the website, since it's more for customers. I'm also unaware of the time saving features a restaurant website can help with online ordering and marketing some of the goals and key objectives. I'd like to come out of this as a restaurant owner is. I'd like to complete take out orders as quickly as possible without hiring additional staff to answer phones. So there's a cost saving play here, but there's some other hidden benefits into this is well because speeding up take out orders also helps with a more satisfactory customer experience. So let's take a look at the take out customer user persona. The take out customer has a 40 to 50 hour work week and is a single mother. She always has a mobile device honor and prefers using apse with social log in as well as eating healthy options. And so her main goal is to get healthy food for the family as quickly as possible while driving home from work. As we identify our personas, we can identify some overlaps, and some key ways that features and functionalities that we might create will benefit one or multiple user personas. So here's another example of usurper sentence and of the chef and restaurant owner, I like to operate more efficiently while increasing online, take out sales so that the business can increase profits and some contextual information about Anna's that she's the founding owner and chef for a sushi bar and restaurant. She's new to online ordering and websites for restaurants, so she needs professional help that keeps her time investment to a minimum. Since she is so busy in the kitchen that we all seven. Like the waiter, I'd like to focus more on serving, dying in customers to provide them the best service possible so that they leave a good tip and return so return business and returned Good tips. Those air. Always great as being a waiter, Mike is also an A son and is the main wait staff. Taking phone orders really distracts him from providing better service to eating customers , so an online ordering system would benefit greatly. Now it's your turn. In this exercise, we're gonna go back to our bank body personas and identify who are most important personas . Avatars are for a bank buddy app, so Number one is list potential stakeholders that would represent the customers and users of your product. Number two Prioritised these stakeholders and pick two to elaborate more on and finally create at least two personas by writing brief stories that outlined their motivations and goals and feel free to download the persona creation template in the resource is section below to use for your exercise. Good luck 19. Persona Exercise Example: okay. Hey, welcome back. How did you do? Well, one thing to note is that this is a challenging exercise because you don't have the data in front of you. Maybe you didn't get a chance to have one on one interviews with your potential personas, or you didn't get a chance to pour through some survey data from an online survey that you've put out. But this is still a great way to get inside the head of your potential persona and to try to identify some of the key problem pain points and behaviors Teoh to take it to the next step. Okay, so let's take a look at the example that I that I came up with your freelance photographer . So my persona is someone who is just running a small photography studio focusing on personal professional photo shoots for entrepreneurs and executives. And some of the behaviors and attitudes and characteristics of the freelance photographer are there mostly mobile, either at a shoot location or me with clients for coffee or lunch. And they struggle with keeping track of receipts for business travel and other expenses rates. That's another. That's a key bullet point there as faras. What is that? One of the pain points that that my persona is experiencing goals and objectives in this case, or to stop collecting and losing physical receipts while completing expense reporting on the go. My personal would also like to manage credit accounts and digital receipts in one place. Okay, so while this is not a perfect persona based on research, data and interviews, it is a great starting place to start challenging some of the assumptions that you have based on your product, as well as try to identify what are some differentiators as far as what makes your product unique. And in order to determine that you're going to need to do the market research and look at your competitors, look at other applications that you might be looking to model your basic functionality off of as well as identifying. Well, what can I bring to the table that these APs do not? It's not an easy task, and this is why persona research is such a critical part in creating new products and improving existing ones. So even if you don't feel that your persona creation is perfect, well, you're in good company because this is an ongoing process and your ability to focus on the details that matter will only get better. Just was any skill with practice and time. 20. The Product Backlog at a Glance: in this section, we're going to cover backlog, mastery and learn how to build user store requirements and manage the agile backlog in the most effective way. So let's take a look at the product backlog. And just at a high level glance, you can see there are three key areas that we want to focus on here, and the first is intent. I want a list of desired functionality for a project that's prioritized by the business value by the product owner. And that's a key point there. Everything he needs to be focused on, what the business value is because if you're not surfacing what that is, then a lot of times work will get done for the sake of work. And we don't want that. Otherwise precious dollars can be lost and your product budgeting and funding could take it nosedive. And you hear time and time again about failing fast in the agile space while feeling fast is encouraged so that you don't lose money, you still want to make sure that everything you do has that business value clear and transparent across the board. Okay, the next is key characteristics, and we use this deep acronym because the key characteristics should be detailed, estimated emergent and prioritized. And so there's this. There's this deep understanding that over time as we as we refine our stories, we find our feature backlog that we are able to I identify what details there are, how much level of effort it's going to take that's determined by the scrum team. And then we're able to surface level and pull those items that need to be worked on first and move the ones that are less important down to the bottom of the backlog now managed by product owner and scrum masters. So the backlog is ah, one of the most important things product donor conduce oh and is responsible for doing is making sure the backlog is in a healthy and prioritize state. So ah, the scrum master is also held accountable for that too. And the scrum master is also an important part of maintaining the healthy backlog by ensuring the teams are focusing on the right priorities and ensuring that the conversation within the team, including the product owner, is happening on an ongoing basis. All of these items go into maintaining the product backlog, which is just one step in the whole life cycle of your feature product ideation and discovery sessions, always through release planning your daily sprints and retrospectives and toe ultimately identify production ready features that you can identify riel, release target dates and communicate them to your stakeholders. 21. Epics, Features & User Stories: Let's talk about epics, features and user stories. These air some of the most common items you'll find in your product backlog. Now, of course, there are some software bugs and things like that that could come into place once you release your product. These are the three key things that you're going to focus on when building new products and services. So the first is epics. Ethics are essentially high level features that span across multiple sprints or releases. These come out of your users story mapping sessions as you identify goals and outcomes for your user personas. So, for example, we might want to add an online ordering system for take out orders for building a restaurant, take out ordering application, and that would give us some business functionality. From a business epic perspective. We may also have an epic to improve database response times by 50% if we're noticing that our technology stack as not as responsive during some of our initial testing, and by completing this, the goal, an outcome that will get is a better user experience with faster response times. So the tactical approach in this case B. U. S. A product donor would work with the scrum team and all stakeholders to create these epics and that highlight and address the goals and outcomes to ensure that there are no gaps and that everyone is aligned to what those business goals and outcomes will be. Epics were often defined before release planning because there may be certain milestones with in your epics where you'll have multiple releases before you deliver the whole epic. So we're going to need those epics in order to break them down even further. And epics are also estimated to take several months of effort to complete. Next. We have features which fall directly under the epic structure features a real tangible components of functionality, but they're still too big to build as just one single story. So going back to our online ordering system for take out orders. As a restaurant customer, I'd like to find a location so that I can place an online order or as a frequent customer, I'd like to pay for purchases from within the app so that I can pick up my order faster. Notice that these are still being written in a story fashion as a insert. The role in this case restaurant customer, I'd like to do or perform some action so that I can have some sort of result or outcome. Okay, so that's going to be a key thing that you're going to see in your ah, your epic creation, your feature creation and your story creation. Now the tactical approach, just like with epics, the practice is going to create them with input from the team features or defined prior to release planning and refined over time to smaller stories that will slot into estimated weeks of effort and last up user stories use. The stories are smaller chunks of work ready for the team to build. These have been broken down based off of the individual features that we discussed in the previous slide. Some examples here are that as restaurant customer, I'd like to enter my zip code so that I can find the nearest location. Another could be as a frequent customer. I'd like to save my credit card information so that I can quickly pay for purchases from within the APP. The tactical approach for this is that as a product owner, you need to work with your scrum team to refine these items in the backlog grooming sessions coming out of your grooming grooming sessions. Your stories should be well to find enough prior to Sprint planning, and the team should be ableto estimate this stories to be completed within about 1 to 3 days of effort. So you can see here what stories should be able to be completed within a single sprint. 22. I.N.V.E.S.T in Creating Great User Stories: in this video, we're gonna cover the invest method and approach to creating great user stories. According to Agile Alliance, the acronym Invest helps to remember a widely accepted set of criteria or flight checklist , if you will, to assess the quality of a user story. If this story fails to meet any one of these criteria, it's up to the team to assess whether they want to reward it or even considering we writing it, which sometimes even means trashing the whole story and coming up with writing a new one. So a good user story should be first of all, independent of all others. Secondly, negotiable. Not tied to a specific contract for features valuable, estimable, based off of previous performance and the experience of the team being able to estimate effectively is going to help in determining how well an accurate you're able to deliver software on an ongoing basis the next this small so that it fits within an integration. And so that estimable step is very important because it goes hand in hand with being small enough to fit within a generation and testable said a high level this These are the key steps that a user story should be and we'll dive deeper into each one of these. So first up is independent, and we want to use your stories to be independent of one another, but also keep in mind that they should build off of one another. And so use this. Have this analogy of a house where the foundation is independent of deciding the overall would be infrastructure as well as the roofing. But without the foundation, we have nothing to build upon. And so the same thing is with your software. You need to make sure that we are estimating when we're building. Brand new software are Architectural Runway, where we're building the runway and the foundation so that our features can be built upon those. So just keep in mind that there is an element of independence meeting that our stories should be able to be completed in their entirety and provides some value at the end of spring and the next is negotiable. Our stories should not be of specific contract for features by having conversations with your business stakeholders who want to make sure that our stories are negotiable and go in and understand what the true acceptance criteria for these are going to be as a product owner is going to be your responsibility to be able to be flexible and negotiate so that you can identify what that clear acceptance criteria should be, so that you could hand it over to the scrum team to start working on flushing out the details. The next is valuable. We want to make sure that our stories again are focusing on what that value is. What is the value of the feature? What value of business goals and outcomes does the features epic satisfy? And how does this impact the overall user persona or user journey and goals that the user will take while using your product? An estimable by asking the right questions will be able to understand better how toe estimate and that includes the experience of your scrum teams. So being able to estimate effectively within the scrum team is going to help you in determining the size of your issues. And this is where we come into the small aspect of things that, like a cute kitten in a box, we want to be able to wrap our stories in a boat at the end of each sprint so that we have something deliver verbal to provide to our stakeholders, and they should fit within one sprint. So if you're noticing that you have a lot of stories overflowing into this next subsequent sprints, well, then it's a good opportunity to use your retrospective meetings toe, identify ways to further breakdown those stories or toe figure out what might be causing the team to carry work over into the next sprint. It's leveraging this idea of continuous improvement that's going to help you leverage this invest framework, but more importantly, deliver working software on an iterative basis. We want to make sure also that our stories air testable. One of the biggest challenges with building software is ensuring that it goes through all the right quality checks and that it works as intended. And so by leveraging a mindset of automated, test driven development and building your test cases into your coat base is a very popular way of ensuring that your stories meet the acceptance criteria and work as intended 23. How to Prioritize the Product Backlog: in this video want to talk about prioritization and this is a key component to ensuring that what you're working on is actually what's needed at any given moment in your product development. And one of the most challenging parts of privatisation is understanding that priorities may be made today but change tomorrow based on a variety of different inputs and factors. So we look at privatisation. A lot of this comes down to a process called progressive elaboration. Progressive elaboration is a practice of further refining requirements as the project progresses, typically within a natural project, requirements will be fully refined for the work in the current sprint, and when the sprint closes and a new one opens, the requirements for the new Sprint are then fully elaborated upon. Now, a lot of these inputs from the ideation phase, which is about 3 to 4 sprints ahead of when you're actually going to execute ah well, feed into your refinement process and being ableto flesh out the acceptance criteria and feature estimates to be able determine what's going to be the lowest hanging fruit to deliver in an upcoming sprint. There's also calculations to business value as well to take into consideration before you had to your implementation phase and where you will actually execute, build and provide product demos as you build, releasable software. 24. Assignment 2: Create an Epic and Supporting User Stories: in this exercise, we're going to create our own user stories. So let's practice by using our bank buddy app, we're gonna create one epic and just remember that these air the higher level features that will span multiple sprints or releases. Your epic should outline a proposed solution to your personas top problems. Organizing them in a high level use case. Next, you're going to create at least 3 to 5 smaller stories using the invest approach we learned in this lesson. And finally, don't forget that for each user story, remember the use of story writing format as a role. I could do something so that value of doing that are performing. That action is clear and transparent, and when you're done, check out the next video. I'll show you how I mapped an epic and it's child stories using the invest approach 25. Exercise Explained: Creating User Stories: Okay, so let's take a look at our story map here. So for a bank buddy app, you can see I'm using a plug in. This is Ajira plug in called Easy Agile. It's actually called story map by easy, agile, and you can use post it notes you can use a tool really Doesn't matter at this point. Ah, what we're doing is we're just really brainstorming how to write this epic and supporting stories. And so what you're going to need to understand is that this is not an easy task. This is, Ah, very challenging task. And this is where ah, we pull and draw from a lot of different areas of experience, but not just our own. The experience of interviewing our stakeholders. Air customers looking at survey, did looking all the empirical and user provided feedback that will help influence our decisions when it comes to building out new features. So when you can look at the top of the screen here, this sort of each of these little color coded boxes or epics and these air each of my features that experience a user journey or customer journey, And so in this case, it's see all of my bank accounts in one place, and then I want to be able to pay my bills after I can see how much money I have and then view my monthly net worth. After all is said and done now, one thing to know is that here of this concept of of domain expertise or domain experience , and so what that really means. This is in the industry that you are being a product manager or owner. Do you have another standing and experience and you need to have that? So while you may not necessarily need to be a master or expert of a particular domain, you need to have a functional working knowledge to be ableto help guide your team from a strategic perspective and help them to build features out that will be releasable to your end user into your customer. So ah, so in this case, you know, if you don't have banking experience, it could be a little bit difficult to go through this exercise. But nowadays, most people have, from a consumer perspective, experience with some sort of banking app to pull in your banking transactions and what not So this shouldn't be a to crazy. And again, don't you know if you're having a challenge with doing this again, just watch this video and go through it. And as you practice this exercise, it's only going to get easier over time. Okay, so let's take a look at this epic seal of my bank accounts in one place. Something to click on this and open it up and you can see this story breakdown is as a busy single mom. I want to see all of my financial accounts in one place so that I can make better spending decisions, pay my bills from one place and have peace of mind knowing where I stand financially so that I can provide for my Children confidently. So there's some really interesting insights into this description Now. This is definitely an epic, at least because it's a larger experience within this customer journey that we're looking to be ableto break down. So all of my bank accounts may include checking accounts, savings accounts, maybe even your credit card accounts, right? So those air some smaller pieces that we could dive deeper into. So let's do that. We've got several stories here that are lined up to this epic for checking savings and credit card accounts. So far, our checking account, the value here is we want to view the account balances so that we could see are available cash across all checking accounts. The same thing is with savings accounts we want to see are available cash across all savings accounts. And the 3rd 1 here is we want to be able to see our spending across credit card account. So as a user can stop overspending, you'll be able to make better spending decisions when you can see everything in one place and get a high level big picture view of all of your finances, Okay, so that's kind of identifying this this high level epic and then breaking these down into smaller user stories. Now, this is where invest is super powerful and is something that will help you. Because when we look at these and we follow, the invest principle will realize that we can continue to break these down even further. And this is important because you're not gonna knock this out of the park. The first go around. That's why the framework for investors there and to help you get more clarity in refining your user stories to be able to deliver that functionality in amore iterative fashion. And so let's take a look at credit card account, for example. We'll do this because the story here is one of you all of my credit card balances in one place so that I can stop overspending. So when we meet with our team, the team will determine. Okay, well, what needs to happen in order to view all of the credit card balances in one place so they may need to build a single page application that's going to render all of the connected bank accounts that would provide that total for the credit card balance for that financial institution. Okay, so that maybe one story that we need to get sort of set up before we even start connecting various bank accounts Now we may need to look at this and say, Okay, well, you know, from an investor perspective, is it independent? And it is independent from all the other types of accounts savings and checking accounts. But we know that there's multiple financial institutions out there, and maybe it's Bank of America Chase and Wells Fargo that we're only concerned about so we can break that down even further, using our invest approach to making them smaller and more testable. Because now we contest the connections between those bank accounts for those specific financial institutions and be able to deliver more clarity as faras. Which accounts from which institutions can we connect? Now we're starting to dive here. You can see we're starting to die deeper and deeper and deeper the rabbit hole as faras What we're able to surface. But this is the exercise that is needed in order to ensure that you have a well refined product backlog that fits into your features, and so that when you hit the ground running with release planning, which we'll see in another video, you'll be able to map out these features and slot them into your available releases. So that's it from a high level on this example for epic ed user story mapping. What we need to understand is when you're creating your stories again, it's just going to be a an iterative process of going through this with your teams going through your ceremonies, such as your retrospectives to be able to make better informed decisions as you move further along in your future generations 26. Release Goals, Duration and Key Players: in this section, we're gonna talk about release planning. And one of the most critical pieces of delivering new software to your customers is being able to plan your releases in ensuring that you have everything included, but also follows some guardrails when it comes to the controls that may be in place in your organization to deliver software into a production environment. Now, if you're working in a small startup, this maybe, ah, lot more smoother, a lot less friction. Ah, but when you're working in an enterprise or an enterprise that deals with sensitive information, there's a lot of compliance. And there could be a lot of governance wrapped around how you're releasing your software into a production environment. So just some things to keep in mind as we move through this section. So what is released planning and what we hope to get out of it so similar to our product backlog slide. You can see the release planning kind of sitting above here in this diagram and is coupled within the whole user story mapping process to help identify the goal, which would be what it really should include and when it should be delivered and really the goal depends on the size and scope for the release and how long. Well, here we've saying four hours to a few days, but the reason that it's theirs or variance in this is that it depends on organisational processes and governance. Ah, that I mentioned before, as well as your automation capabilities and the way that you're able to deliver your software. If you're doing things more manually, it could take a lot more time to deliver. Also, how your delivery tools and release notes are being captured. It communicated, Ah, whether using tools, Aguirre or some other project management software to structure releases. So aside from committing code, there is some other items of round actually managing those releases that could play a role in how long it actually takes to deliver to production and the key players. And really, this is everybody's responsibility within the scrum team, the product owner, the scrum master for participating in release planning. Now you as a product owner is your job to drive the release planning and ensure that the key business value is met and the scrum master will help in keeping the team focused on what the true priorities are as well as removing any roadblocks to ensure a smooth delivery . Maybe that's helping. Identify and remove issues with pipeline tools. If you're having difficulties with your production builds and you have external teams that you need to escalate to, your schoolmaster can help step in there and and and help the team out to smooth out those items so that you can continue with your release planning. But ultimately the team is responsible to ensure the acceptance criteria is met usually includes any validation or post production deployment monitoring criteria as well. 27. User Story Mapping for Release Planning: we mentioned story mapping and so release, planning and story mapping go hand in hand. A story map allows a company to visualize the journey a customer will take with their product, including all of the activities and tasks they will need to complete. This understanding enables teams to focus their development on providing the most value to customers based on their desired outcomes and goals. There are a lot of tools out there to help you with story mapping. You could use white boarding. You could use mind maps. This exercise is really to enable you to drive a better customer experience. So some of the key points or why are we building this? Who are we building? Four. And what value will it bring to the experience? We talked about how you can create story maps and really there to key ways that you can create. These one is by manually using post its or sticky notes, drawing it out on a whiteboard or posting your notes to to a white border wall. But then there's a dynamic way to do it as well, and that is by using software such as digital tools or plug ins. If you're using Ghira, you can use something like there's a snapshot here by Easy agile for their story mapping plug in benefits of the manual or that, well, you don't need an Internet connection. You don't need a computer, and you just need a handy piece of paper and marker or pen. And while this is great for really kind of brainstorming, spur of the moment ideas and jotting them down, you want to make sure that you transfer those into some digital tool of some sort. And when you're working in small teams, maybe the manual post its notes. That works fine. There's nothing about that. But as you move into a larger enterprise, dynamic digital tools maybe more favorable so that they can be stored in a central place shared by multiple teams and stakeholders so that everyone can be aligned and understand what the view is into the user's goals and outcomes and how toe further break down those epics into features and features into stories. There's no perfect choice in this matter. It will depend on your situation and the preferences for your team 28. Release Planning and Roadmap Examples: So now that you've identified what you were going to be releasing, one of the tools that really does release planning well is Jura classic, and you're able to by using the Jura software software comes in. Some companies have it installed on premise on their own servers, and then you're also offers a cloud based solution that you can you can have a license for . So this is just a snapshot of, you know, slotting some stories into a release. And by integrating some of your tools like Get Hub Orbit Bucket, you're able to look at any code issues any potential areas that need to be looked at before you can release your software to production. So there's some really cool ways to integrate your various development tools to ensure a smooth release. Another example. And this is Ajira. Next, Gen, which is a different flavor in the Jura Cloud product family. And this kind of gives you just the high level of road map of your epics and the features that support those and target dates and time frames. So this could be really beneficial when you're trying to communicate at a high level, any upcoming delivery dates that you've committed to for your stakeholders 29. Tools of the Trade: Okay, so here are some tools of the trade that you're going to need to be familiar with as a product owner. Now, there are so many tools out there that can help you from everything from ideation Teoh to use a story mapping and actual delivery. But it's gonna be up to you in your company a lot of times. If you're working in enterprise, you already have a set of tools selected or ah, you have the opportunity to research some of the tools that are out there and test them with in your team's. Now, some of the ones all highlight here are for road mapping. So we looking at something like your portfolio is a plug in for Jiro that will allow you to create dynamic roadmaps, allow you to automate a lot of your workflow as far as identifying when your target dates are going to be based on the baseline velocity that your teams have. So basically, without getting into details, that's just gonna help you deliver faster and communicate the transparent outlook to your stakeholders. To be able to make better decisions and do scenario planning based off of we add a couple developers or teams or we remove some. So it's a very, very powerful tool if used correctly. Now you may be an enterprise that's really looking to ramp up and really large enterprise, and in this case you have something like You're aligned and you're aligned, which is actually acquired. It used to be called agile craft and at last seen in the company that makes Jura rebranded into your align. And this has a much larger enterprise governing sort of approach to top level objectives and key results that connect to your business initiatives within your lines of businesses. And so it can really, really scale here. And it was designed for that. It was designed for scaled, agile teams within larger enterprises, so portfolios probably prize is much more focused to the at the large enterprise market. And then, if you're not that big, you could just use some other key software Now, regardless of what you use for, if you're using portfolio or you're a line, you're still going to need to use something like dear a software for your actual teams, because those two are just focused more on portfolio management and sort of road mapping and this is really the key in. I work with your own day to day basis, and there are some other tools that you can use out there to. Jeer just is the number one standard when it comes to development by agile teams. Now, one other external when I want to mention here, is Ah ha. So from a roadmap perspective, you can see there are product teams that that leverage ah ha as well. So just do a Google search and you'll find a bunch of different ones. You can get overwhelmed, but but doing your research is part of being a product owner and understanding what it's out there to help you deliver better products and deliver them on time and on budget. It's gonna really help you. Now let's just say you are looking for you know, your you don't have a budget for a issue Tracking software tiger dot io is an open source project that you can you can sign up for, and they do have some pricing. But there is a free tier where you can start a project and get things going on and managing your work in a tool like tiger Now, if you're not using scrum and you're using more Con Bond, you can combine in a smaller team sense. There are a couple once a out here. I absolutely love. Trillo is one of them. Trillo also was recently acquired by at last season. So you're going Teoh. See some similar functionality. This is a little bit more stripped down. It's very simple. It's just lists on boards and cards that you can move from one column to the next. But it's a great way to visualize your work. There are no story estimates, although you can probably get some plug ins to help you with adding that functionality and Trillo. But out of the box as of this video it is, is more of a stripped down visual task management application. The same thing goes with Meister task. I absolutely love meister task. I think e think it's a great software for basic task management. Again, this is another software that looks beautiful. It's very beautiful. Um, you've got Ah, a nice, beautiful interface here. And you can you can just take a look click on my website here, and you've got some columns here that you can drag and drop and and, um, move stories across the board. But again, you don't have story estimates. Here there is a paid version. This is all free. There's a paid version where you can you can actually look at our reports, and you could log hours to your cards, but there's really no forecasting involved in it. So just some options if you're into Kon Bon in basic task management for delivering your your digital products. 30. Dive Deeper into Design Thinking: in this video, I'm gonna share with you some of the online resource is you can leverage to further your product ownership and product management skill set. Now there are so many online resource is both paid and free that you can access just by doing a simple Google search. But these are the ones that you can start using today to help further the knowledge that you have and apply it in your product on a roll. So the 1st 1 here I have is called Design kit dot work and Design Kid is a website that shows you sort of the human centered design approach and provides a lot of free resource is as faras videos and even a free download so you can download this field guide to human centered design. If you visit the website, there's a hard book that you can purchase. But if you're just looking to get something real quick and start reading it, they do offer a free copy. If you click on that and download it, you'll just need the log in or sign up to download that Okay, eso that is designed kit. The next one is interaction Design that orig. And here's where you can really learn more about design thinking from a user experience perspective, and this will really help you open up your mind to the possibilities from a designer approach on not only the people that you will work with in a an agile software development shop, such as your user experience designers in your user interface Designers commonly referred to You x and you I. But those are the folks that you're going to work with to help design front and solutions that are customer facing that your users will interact with on a daily basis. So check out Interaction Design Foundation. There's some courses here. There's some free literature and one article they have here, and this kind of just gives you a good design thinking process overview. And this is really just the five stages in design thinking the first, being empathizing, defining idea, eating, prototyping and testing. So this sort of cyclical feedback loop is what's commonly referred to as designed sprinting . When you apply these concepts into your scrum, it orations and further refined them after you get feedback from your users. Okay, so these are all great tools to leverage when it comes to learning more about human centered design and user experience and interface design, and the next one here is this was website is called agile velocity, and this is just another place that you can learn more about story mapping and dive deeper into that because this is really where you turn that backlog into a more compelling product backlog that actually has human problems, human benefits and business benefits tied to your user personas that you've that you've created in the whole ideation phase and human centered design and research phases again these air just a few resource is you can get started with quickly. There's Aton of Resource is out there, and if you just start doing a Google search, you could find yourself going from website to website. All of it is very useful if you can take some of that knowledge and apply it into your own role. The number one thing to understand about all of these resource is it comes down toe one central theme, and that is your software products are really without your users. Your product wouldn't exist, and I know it may seem like a no brainer, but a lot of times when we're so focused on the technology in the implementation, sometimes putting the customer front and center and focused on what we're actually building can slip away if we're not careful. 31. How to Get Product Owner Certified: OK in this video, I want to show you some of the industrywide certifications that you can take advantage of in building your resume and building your skill sets as a product owner or product manager if you're looking to move into that role as well, and we'll cover the distinctions between the two. But let's start with scrum alliance dot org's So scram. Alliance Data work is probably one of the entry level certifications that you can take advantage of in going to the scrum certification track. And so you can take a look at certification types and tracks from the Scream Alliance data warg main menu, and that will show you the available tracks that you can take advantage of. So the 1st 1 is Crime Master Track. Then there's also a developer track here, but we're gonna focus on product owner track in the center so product donor track will give you the base level certification for being a product owner. He could then take it to the advanced and then take it to a certified scrum professional product owner. So these air just several different tiers that you can go to get certified in the product owner space. And one of the biggest things is is that you know, being CSP Oh certified is a nice thing to have on your resume to help you stand out from potential product owners out there who that don't quite necessarily have that certification and knowledge in the scrum sense of being a product owner. So take that into consideration. If you don't have any certifications yet, I highly recommend getting started with that one. Then the next one is more for scaled, agile implementation, and that's ah for the scaled, agile framework. So if you're looking to get a role in an enterprise or government, there are different levels of safe and different sizes of safe plantations for larger institutions, and you can see it by looking at the diagram here. We've got essential safe, and that's the most basic configuration of safe for getting a company started or getting an enterprise started with implementing a scaled framework. And then you have your large solution, which is sort of the next step and then the portfolio, which is a progressive step in strategy, investment funding and just normal day to day portfolio operations on lean governance and then you have the full safe, which is basically just taking advantage of all of the things that have been added on from large solution to portfolio and full safe configurations. So when we look at the safe implementation, there's a couple things I want to point out here on this road map. There's a lot of different roles. There's a lot of different processes, but the one thing to keep in mind here is this concept of agile, release trained. What's nice about this little map is you can click on little links with inside the diagram to give you more understanding what these terms are and so like. An agile, released, trained, for example, is a long lived team of agile teams. So you have multiple agile teams that come together in what they call a train to provide incremental development and solutions as a common entity. And so when you're looking at an agile release train, you may be a product owner of one team, and there may be three or four or more teams within your train that have their own product owners. But you work together in developing a larger solution. So that's Ah, one who wants to note. The other is the idea of a program increment. And so let's go back over to this diagram here. And so the program increment is essentially a time box that can be around 1/4 if you think of it in calendar terms, you know, first quarter, second quarter, third quarter and fourth quarter of the year. But the program increment is going to be a time box that is typically 8 to 12 weeks long and is going to be a ah way, too. Identify what work you're going to commit to within that program increment and what deliverables you're going to meet. These should align to sort of your strategic enterprise initiatives, any of your objectives and key results that have been set by your your executive team, your senior leadership teams and on. This gives some visibility into the high level cadence of delivery in an enterprise or government institution, and the next here is the safe product owner. So we talked about the safe scaled, agile framework at a high level, but this is one of these certifications that you can take advantage of if you're looking to become safe certified and find a product donor or product manager role in a larger institution. So the p o p m. Say four certification is what you'd want to be looking at and essentially here. This this page will cover some of the goals and topics cover in the P. O. P. M certification class. It's a currently a two day class, and you'll be able to apply a lot of the things that you would learn in the certified scrum product owner if we go back to the scrum Alliance into this sort of basic sort of occasion and take thes similar concepts that you've learned is a product owner and then build upon that and sort of the safe implementation of what a product owners role would fit in. Now. Product management. I want to touch on that just for a minute. So product managers content to sit above sort of the product team and really work on driving the higher level business goals and strategy for the product team. And it's the product owners that would be working with the individual scrum teams to help deliver and execute on that vision