Agile in a week - Now that's being Agile | Arshad Ahmed | Skillshare

Playback Speed


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

Agile in a week - Now that's being Agile

teacher avatar Arshad Ahmed

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

28 Lessons (1h 55m)
    • 1. Introduction

      1:34
    • 2. History of Agile

      4:05
    • 3. Agile Vs Waterfall

      6:27
    • 4. Agile Principles

      5:17
    • 5. Agile Methodologies

      5:15
    • 6. Kanban and XP

      3:35
    • 7. Agile Theory

      6:14
    • 8. 5 Values of Scrum

      3:51
    • 9. Scrum roles

      4:17
    • 10. Scrum Master

      3:26
    • 11. Product owner

      3:13
    • 12. Development Team

      4:05
    • 13. Product backlog

      4:08
    • 14. User Stories

      4:05
    • 15. Backlog refinement

      5:24
    • 16. Scrum events

      3:24
    • 17. Sprint planning

      2:54
    • 18. Daily Scrum and Sprint Review

      4:31
    • 19. Sprint Retrospective

      2:42
    • 20. Burn Down Charts and velocity

      4:28
    • 21. Kanban board

      2:42
    • 22. Value Roadmap

      4:06
    • 23. Insider Tips

      4:53
    • 24. Moving to Agile

      3:50
    • 25. Challenges

      7:13
    • 26. Coaching Challenges

      4:57
    • 27. Agile Evolution

      4:05
    • 28. Conclusion

      0:46
  • --
  • 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.

10

Students

--

Projects

About This Class

Today over 70% of companies are using Agile for their projects, not knowing the fundamental concepts, principles, and values

In one week you can become an agile pro and make yourself a more valuable member of the team by learning Agile and how to successfully implement it in your organization.

This course includes:

- Agile Values
- Agile Principles
- Benefits of Agile
- Challenges
- Roles in Agile
- User Stories
- Scrum Framework
- Sprints
- Product Backlog
- Sprint Backlog
- Estimation Techniques
- Team Velocity
- Burndown Charts
- Kanban Boards ...and more!

Learn:

  • How to apply Agile in your job and projects.

  • The difference between Agile and traditional project delivery.

  • The benefits and advantages of Agile.

  • About the history of Agile.

  • Why Agile isn't only for Developers.

  • Why Agile isn't only for IT projects.

  • How to use Agile to deliver quickly and often.

  • How to use Agile to learn from your mistakes.

What’s included in the course?

- High-Quality Video Lectures break down the complex terms and confusing Agile jargon to ensure you get a concrete understanding of the items being discussed

- Quizzes validate your learning and help to point out areas that should be reviewed for full comprehension

- Reading Material to further improve your agile knowledge

- Lifetime Access with NO Expiration so you can learn at your own pace, and come back at any time you feel unsure or are in need of a refresher

How will this help you?

  • You will be able to deliver projects, products and applications quickly and often, the Agile way!

  • You will go fully prepared to a job that requires knowledge in Agile.

  • You will feel more confident about Agile and how to apply it.

  • You will be able to add this to your CV.This will help you land more jobs!

  • What you will learn will make you effective and successful

Who is behind this course?

A triple certified agile professional (PMP, SAFe and Google) with over 8 years of experience implementing Agile globally in companies such as Mercedes- Benz and BMW.

What are the advantages of Agile Project Management?

  • In Agile Project Management you deliver projects faster.

  • Agile Project Management fosters an environment of constant collaboration, teamwork and focus on execution.

  • In Agile Project Management you have direct input from your customer throughout the whole project.

  • Agile Project Management shifts from traditional long documentation processes and long meetings to agile, lean processes, practices and rituals such as the daily standup.

  • In Agile Project Management roles blur, meaning everyone can participate on different tasks regardless of whether it's their "official" role or not.

  • Visual boards (Kanbans) and reports (burn down charts), are a key part of Agile Project Management. It allows everyone to stay on the same page and be able to understand speed of execution, areas of improvement and more.

Can I add this Agile Project Management Certification to my CV?

Yes, of course! You can add this Agile Project Management Certification to your CV or Resume.

Meet Your Teacher

Teacher Profile Image

Arshad Ahmed

Teacher

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
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.

Transcripts

1. Introduction : Hello and welcome to Agile project management. I'm going to share with you one of the most popular approaches to delivering projects agile. In my opinion, agile is also the most interesting and flexible approach to project management. Edges noted project management methodology in and of itself. But more of an overarching approach and philosophy to deliver value to customers, which is the goal of most projects. So what is Agile? Agile is defined as a way to manage a project by breaking it up in several phases. It involves constant collaboration with stakeholders and continuous improvement and every stage, despite not being as specific methodology, there are lots of frameworks and methods under the Agile umbrella. In this course, I'll help prepare you for Korea and Agile project management. I'll provide you with a history of Agile and introduce you to a specific agile delivery framework called Scrum. I'll teach you about the core roles that make up a Scrum team. I'll cover some basic practices and real-world scenarios where you can use the agile approach to lead your project to success. I'll also provide you with practice questions and material to get you ready for your Agile examination. I hope you're ready to discover agile and experienced the benefits of Agile. In the next video, we'll start learning the basics of Agile. 2. History of Agile: In this video, I'm going to give you a brief history of Agile and introduce you to the Agile values and principles. And you'll learn that Agile can be used in lots of different industries, not just Intake companies. Ready. Let's get started. Agile methodologies emerged organically during the 1990s as the software industry was booming, software startups like Microsoft were blazing a trail to get more software products both in less time. Meanwhile, the tick John's of the time, we're experimenting with foster ways to build beta software and stay competitive. They also needed to innovate the very processes they were using to develop these new products. In 2001, the thought leaders and creators of methodologies came together to find common ground between the methods and solve a problem. The problem they agreed was that companies were so focused on planning and documenting their project that they lost sight of what really mattered, pleasing their customers. To refresh your memory. Waterfall is a popular project management methodology that refers to the sequential or linear ordering of phases. You complete one phase at a time, not proceeding to the next until it is done. Then you move down the line like a waterfall starting at the top of the mountain and traveling to the bottom. The term agile refers to being able to move quickly and easily. It also refers to flexibility and the willingness and ability to change and adapt. Projects that adopt an agile project management take an iterative or progressive approach, which means the project processes are repeated often many times during the lifecycle of the project. In this case, the team operates within many shorter blocks of time called iterations. Individual iterations might get repeated depending on the feedback received. During each iteration, the team takes a subset of all the projects activities and does all the work required to complete the subset of activities. You can think of it as a lot of mini waterfalls for each activity. This iterative approach enables the project to move quickly, as well as making it much more adaptive to change. So the term agile means flexibility, repetition, and openness to change. But what do we mean by agile project management? Agile project management is an approach to project and team management based on the Agile Manifesto. The manifesto is a collection of four values and 12 principles that defined the mindset that all Agile teams should strive for. So in very basic terms, waterfall is linear and sequential and does not encourage one to change the process once it has started. Agile, on the other hand, is iterative, flexible, fast, and incorporates necessary changes throughout the process. Now, here's where agile gets even more interesting. You can still use Agile even if you're not planning to work on software projects. Agile has been so successful in the software industry that its values, principles, and frameworks have been applied to nearly every industry. You'll also find agile methods being adopted in the era nautical, health care, education, finance industries, and even more. Cool, right? Agile is every way. Now you know a little bit about the history of Agile and some of the industries that use Agile for project management. Coming up next, we'll compare more of the differences between waterfall and agile to really familiarize yourself with these project management styles. 3. Agile Vs Waterfall: Hi. Before we proceed, I would like to take a minute of your time to please ask you to review this course as it will allow future students to determine if this course is the correct one for them. Moving on in this video, let's spend some more time comparing Agile and Waterfall. I want you to really illustrate the key elements of Agile that distinguish it from waterfall. Then you'll be able to build on this knowledge when we get into the manifest or later on. So as I mentioned in the history lesson, Agile was created in response to the strict, linear, and slow process of waterfall. While waterfall aims for predictability and trust you avoid change. Agile embraces the reality that the world, markets and uses are uncertain and unpredictable. For example, your customer might say they want feature a, but when the final result is delivered, they realized that actually wanted feature. See, Agile aims to solve that problem by getting customer feedback more quickly and frequently to make sure that the team is building what the customer really wants. Part of working with an agile mindset is always seeking out ways to work more efficiently. We do this by finding ways to streamline processes without reducing product quality or value. The key to streamlining is to reduce wasted time. For example, unnecessary documentation or spinning weeks or months working on a feature that is not the customer's main objective. More collaboration means less documentation and earlier feedback about the product. Let's consider some more differences between waterfall and agile. Three important aspects of a project or requirements, documentation and deliverables. Requirements are conditions that must be made or tasks that must be finished to ensure the successful completion of the project. Think of these as the set of criteria that fall within the scope of your project or a list of specifications that must be made. In a waterfall project, you'll probably need a product's requirements document, which lists the scope and requirements of the project. You need to have several familiar proof project plans. And you might have a team of people whose job it is to write an approved these plans. You might also see a change control board, a formal and rigorous process to manage any changes to requirements. All this is designed to protect the team from Bolding something that the client or stakeholder don't want and aims to minimize any changes that could lead to scope creep. Formally approved project plans work well when the desired end product is known and understood. An example of this might be leading a project that has clear requirements and goals based on mandated regulation. But if that's not the case of waterfall team risks building out an entire deliverable only to find out later that the customer doesn't like the final result. In Agile, requirements are treated as more dynamic and expected to change as the team receives feedback and new information. There's usually an initial set of requirements or featured ideas win the project kicks off. But that list of requirements and features is continuously growing and changing throughout the project. The team works with stake holders, prioritize the requirements. Always moving the most urgent or valuable items to the top of the list. Then the team goes down the list working on the requirements in iterations. By going down the list, the team is able to get feedback on their work quickly and frequently. At the end of each iteration, the team gets feedback and can make necessary adjustments to their requirements before continuing on. The second aspect is documentation. All projects require documentation, project plans, stakeholder maps, schedules, charters, contracts, the list goes on and on. Waterfall projects use lots of documentation because they are lots of handoffs between phases and hand-offs among different teams within the project. Also, because the work is done in bigger chunks, you'll need to leave behind more pieces of documentation at each stage in the project. But in Agile, there's an emphasis on real-time person-to-person conversations. This doesn't mean that there's no documentation. It's just in a different form. Instead of big formal documents with crazy change management and approval process, there are shorter document that have just enough detail to achieve their purpose. These documents are much more focused on what the reader needs to know to get the job done and are written only as needed. Finally, let's explore deliverables. A deliverable is a tangible outcome from a project. In waterfall projects, you often don't release the deliverable until the very end. The final product release feels like a big event, major announcement, lots of excitement, and it's often super fun. Agile is just as exciting, but has smaller, more frequent releases. So each release has a less formal celebration, but it bullets up to be just as exciting when there's lots of uncertainty and a project, such as in a new emerging industry or market. The steady release of project deliverables in Abel's and Agile team to get feedback and learn as they go. So now you have a better idea of some key elements of Agile that distinguish it from waterfall. Three differences between these two requirements. Documentation, deliverables. Also. Let's keep going. Meet me in the next video to learn more about the principles of Agile. 4. Agile Principles: Hey there, I'm going to tell you about the 12 principles of Agile. These days, Nicaea benefit and studying each of these independently. The full themes of the Agile principles, I saw one, value delivery, or how do Agile teams deliver highly valuable products to the customers? To Business collaboration? Or how to agile teams collaborate with a business partners and stakeholders to create business value to the organization. And they uses three, team culture. Or how does it teem, create and maintain the right into personal and team dynamics to deliver venue for the customers and the business. Full retrospectives, or how does the project learn to continuously increased performance of an organization and business? I've grouped each of the 12 principles under these themes so they easier to learn and remember, let's dive in. The first theme is value delivery and includes five principles. This theme is about delivering the work as quickly as possible so that we can get feedback and mitigate the risk that we spent too much time building the wrong thing. Also, no one gets any value from your work, including your company until you deliver it. So the longer you take to deliver, the longer you wait to get revenue, and maybe the more time the competition has to get ahead of you. The value theme is also about simplicity. How much time do you think it takes engineers to add all the buttons and features to products that ultimately end up confusing the user. Simplicity allows a team to focus and work on the things that matter the most. An example might be reserving 10 percent of the teams time to work on bug fixing or polishing a process should help you go faster in future iterations. The next theme is business collaboration. Collaborating with your customers helps the team get critical business information immediately by allowing them to adjust and adapt to any new information instantly. No matter if it's realized early or late in the project, customers will get what they want to achieve their business goals. You can achieve collaboration by making sure that business people work near the development team, ideally in the same office or virtual space. If that's not possible, maybe co-locating a day a week, encouraging instant messaging or blocking off time on your team calendars each day or week to collaborate. The goal is to enable easy access between business people and developers. Another aspect is how you handle feedback and changes in priorities rather than trying to keep the customer away from developers due to concerns about scope creep creates a weekly huddle with customers and business people can explore feedback and new ideas with the team. This could be a great way to discover that one really valuable feature is super easy to bold. Whereas another feature that uses thought would be easy is actually a really hard. Our third theme is team dynamics and culture. This theme emphasized as creating an effective team culture that is inclusive, supportive, and empowering. Having an effective team culture is essential to our project's success. These principles really boiled down to making sure your team is motivated to do the right thing, feels trusted to do the right thing, has the resources and space to work closely on the goals and works at a sustainable pace. An example of emphasizing effective team culture would be to ask the team what kind of equipment they need to do the job and then giving them those tools. Another manifestation of this theme is native. Teams write their own processes and templates rather than forcing them to use something from head office. Teams were based when they feel like their input is valued. So you, as the project manager, should make space for your team to engage and actively contribute to the team culture. You'll build trust and empower them to approach their work in a way that suits thing based, which in turn will allow them to work more productively. Finally, the fourth theme is retrospectives and continuous learning. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Team should always be figuring out better ways to work. And it's really valuable to seek this time aside of the each iteration to focus entirely on how to improve. In these sessions, the team can step back and consider questions like, how is the team doing? Are the customers happy? 5. Agile Methodologies : Welcome back. Up. Next, I'll introduce you to some specific methodologies under the Agile umbrella. The most popular of these by far is Scrum. In this video, I'll briefly recount the origins of Scrum and discuss the basics of the Scrum methodology. So what is Scrum? Well, if any of you have ever played or watched the sport of rugby, you may recognize the term scrum refers to a formation in rugby where all the players on the team lean forward, lock their heads together and they work as one unit to try and gain precious yards towards the scoring line. The creators of the Scrum methodology saw the team as a hates Don group, working very closely together to get that ball down the field, just like a Scrum in therapy match. So how does the Scrum methodology actually work as a project management methodology? If you work in Agile project management, it's highly likely that you'll use Scrum or an approach that is based on Scrum. In the 2019 state of Agile report, 72 percent of teens using agile methods, we're using Scrum or a hybrid. When you use Scrum for project management, you form a team that will work together to quickly develop and tasted deliverable. The work is completed in short cycles, and the team meets daily to discuss current tasks and tap anything that's blocking their progress. First, let's review some terms and concepts specific to Scrum. The backlog is the central artifact in Scrum. We all possible ideas, deliverables, features, or tasks are captured for the team to work on. It's prioritized and proactively managed by the team continuously throughout the life of the project. The sprint is the name of the timebox period in Scrum we work is done. The sprints can be between 14 weeks long, but my sprints are around two beats. This is often called the iteration. And then there is a practice called The Daily Scrum, also called the stand-up. This is where the team meets for 15 minutes or less every day of the sprint to inspect the progress towards a goal. Next, other roles, the first of which is the Scrum Master. This role is responsible for ensuring that the team loves Agile values and principles, follows the processes and practices that the team agreed to, sharing information to the larger project team. And they also help the team focus on doing the best work. The other notable role in Scrum is the product owner who is responsible for maximizing the value of the product and the work of the team. The product or in a, owns the inventory of work and has the final say on how to prioritize the work. And the development team is responsible for how a team we'll deliver the product. Scrum is popular for many reasons. First, it has clear roles and responsibilities for the folks on the team, while continuously emphasizing the power of the team as a whole. Scrum has very regular and predictable meetings and delivery schedules that pre-defined agendas and outcomes for the meetings make it easy to teach new teaming because it supports and reinforces the Agile values and principles while adding some structure and foundations that help new Agile teams get started and more experienced teams gate beta. Scrum lanes itself based to the following types of projects and teams. Ideally, a Scrum team should be cross-functional with around three to 19 members. Some call this a pizza size team because it has the same amount of people who could share a large pizza. If the team is too small, you might start to have the diversity or skills to get work done. If the team is too large, it gets hard to distribute information. Lastly, Scrum works best for projects with the team and management are open-minded, adaptable, and value continuously learning how to be a better team. Trying to force a team to do scrum will almost always fail. People have adapted scribe to suit all kinds of projects, from wedding planning to house moves to building rockets. Great. You know, are some of the key characteristics of Scrum and which types of projects can really benefit from it. It's an exciting method. Next, we will discuss a few other popular agile methodologies. Learning about these approaches will help you become a well-rounded, versatile member of any project team. So what are you waiting for? Meet me in the next video. 6. Kanban and XP: Hi again. In this video, I'll touch on a few of the most popular ones beside Scrum, which we covered in the last video. Fairest, one of my personal favorites is Kanban. You may have already used a Kanban board because it's the most famous feature adopted by the majority of Agile enthusiasts. The reason Kanban is so popular is that it provides transparent visual feedback to everyone who might be interested about the status of work in progress. Kanban boards are charts display the progress of a project as to do in progress and done. The Kanban method ensures that the project team only accepts a sustainable amount of in-progress work. This means that amount of in-progress tasks are limited to what the team can actually handle during a certain amount of time. This is called the Work in Progress limit or WIP limit. The WIP limit is decided on by the team. This is a reflection of agile and that teams are both self-organizing and empowered, and they're operating at a sustainable pace. The team members add new tasks to be completed only after they finish the previous toss. Below the WIP limit. This approach means that once a Tosca is started to be worked on, it becomes a priority for the whole team to get it done. By focusing on lacework, the work gets done. Foster this goal of trying to maximize efficiency. 7. Agile Theory: Hello. In the last video, we've reviewed a few of the more popular methods for applying Agile values and principles to your projects. We explored con bond, which focuses on visualization and XP, which is concerned with taking product development based practices to an extreme degree. Agile aims to capture core principles that you eliminate waste and deliver value to customers. We've also compete Agile and Waterfall to form a better understanding of what each approach values or tries to accomplish and what kinds of projects they work based with. A waterfall project lifecycle is made up of the following phases. Initiation, planning, executing, and completing tasks, and closing out the project and all of the tasks within each of these phases, like identifying goals and scope, scheduling, budgeting, and risk management. Agile project management includes most of the same phases and tasks. They're just done in different ways. So even though these two approaches have clear differences, blending, they might make a lot of saints, depending on the type of project or project team you're working with. One reason you might want to blend Agile and Waterfall styles is your stakeholders. Customers or sponsors are more comfortable with traditional approaches and using workflows or delivering traditional work product is easier for them to understand and follow. But your project team is already established in Scrum and they wish to continue. Most Scrum teams, I know, use a Kanban board to track their progress through their sprint. Just as agile has core values that teams must adhere to, Scrum has its own set of pillars that act as a foundation for Scrum teams. Late start by looking at the theory behind Scrum so that we could learn the various methods and understand why they're effective. First, what is Scrum? Scrum is a framework for developing, delivering, and sustaining complex products. That means a team can use Scrum to create valuable products for the uses, even when they environmental industry they're in is hard to predict and they are many risks. Scrum uses an iterative and incremental approach. Iterative refers to the fact that project processes are repeated. We discussed this a bit in a previous video. But as a reminder, iterative means that the project works in time boxes or iterations. Incremental refers to the work being divided into smaller chunks that build on each other. The product is built over time through work done during each iteration. Each of these instances of the product is called an increment. Iterations. And increments allow us to keep checking in on our progress throughout the lifecycle of the project. This helps us become more predictable and manage the uncertainty in our project. Scrum is built on three pillars. Those pillars are transparency, inspection and adaption. First, there's transparency. Transparency means that we make the most significant aspects of our work visible to those responsible for the outcome. Everyone must be transparent. This includes everyone from Scrum team members to senior sponsors and even our users. It's easier to be transparent with a small team. And luckily, Scrum teams are deliberately small, ranging from 39 people. This way you avoid mixed signals, breakdowns of communication and unnecessary complications. Transparency inside as Scrum team is critical to the team's productivity and the project's completion. In terms of transparency outside of the team, being transparent with all stakeholders, including customers, sponsors, and management builds a level of trust between everyone involved. Transparency also encourages more collaboration and fear mistakes. The second pillar of Scrum is inspection. Inspection refers to conducting timely checks towards the outcome of the sprint goal to detect undesirable variances. This means that we're always checking in on our progress and deliverables so that we can detect any undesirable changes. When teams work in an agile way, a stakeholder review of their work is a necessary opportunity for growth and progress. The more inspections that take place, the more improvement team experiences in their work. There's real value to be gained from deliberate inspection While you have a chance to change and improve. Inspection also propels our next pillar, adaption. Adaption means that we are continuously searching for ways to adjust up project, product or processes to minimize any further deviation or issues. In Scrum and Agile as a whole, for that matter, we embrace changes so that we are always improving. So when we adapt, we change aspects that do not work or could be better. Transparency and inspection gives Scrum teams that information and opportunity they need to identify improvements or changes. Although adaption includes immediate fixes to problems, it may also be about implementing a change, so future projects don't repeat past mistakes. Now you know the three pillars that act as a foundation to Scrum, transparency, inspection, and adaption. In the next video, we'll visit the five values that all scrapped needs adhere to. Meet you there. 8. 5 Values of Scrum : Hello again. In the previous video, we discussed Scrum theory and explored the three pillars of Scrum. In this video, we're going to talk about the five values of Scrum and how they relate to the three pillars. Having a value system as a team is great because you'll expect each other to act in a way that is aligned with these values. So let's get into it. Scrum teams work and behave according to five core values. Commitment, courage, Focus, openness, respect. First, there's commitment. This means personally committing to achieving the goals of the scrum team. For example, may be a member of the team is struggling to overcome something that is blocking their work from getting done like a new technology that is proving difficult to learn. In this case, another team member who is familiar with that technology can put their own work aside to step in and help their team meg learn the technology. The second value is courage. Scrum team members must have the courage to do the right thing and work on tough problems. In any project, there's a body of work that needs to get done. Some of the work will be relatively simple and some will be complex with many risks. An example of courage includes taking on a hard task that you know will require you to learn a new skill. Courage could mean telling your team that you stuck and you need help. It might also mean calling out a negative behavior within the team to openly discuss and address the behavior. Demonstrating courage when responding to challenging situations can strengthen the teams resilience. Third, there's focus, everyone focusing on the necessary work within the sprint and the overall goals of the scrum team. For example, a team member is working on a solution that involves a new technology and is very difficult, allowing that team member to focus on that difficult to get necessary part of the solution is key. And they teammates help get it across the finish line. They know that focusing on the solution will speed up the team's progress in the long run, so it's worth the investment. Now, the fourth value is openness. For Scrum to work. The team and its stakeholders agreed to be open about all the work and the various challenges that come with performing the work. Openness is essential to a productive scrum team. In order to gather daughter, team members must be willing to share their observations and experiences. If a team member rent into an issue within the project that they aren't sure how to fix. They should share it with the team. Another team member may have a very quick and easy solution, or at least valuable insight into some options on how to handle the issue. The fifth and final Scrum pillar is respect. Team members should respect their opinions, skills, and independence of their teammates. When you respect the independence and contributions of others and feel respected yourself, you more likely to listen and hear any feedback. This is crucial and making the product or business as successful as possible. In order for a team to bring the three pillars of Scrum to live, they must act in accordance with the five scrum values. Meet me in the next video, we will discuss specific scrum roles on a team. 9. Scrum roles: Hello again. The next few videos we'll focus on the three scrum roles that make up the Scrum team, their respective traits and the scrum team's mission. Let's start by discussing the Teams product vision, and mission. Remember, scrum is an agile methodology, so it embodies the values and principles of agile. One of the Agile principles states, build projects around motivated individuals, give them the environment and support they need and trust them to get the job done. The best way to motivate individuals is to give them a mission and a product vision that they really care about so they can feel good about working towards it. In Agile, emission is a short statement that stays constant for your team through out the process and gives them something to work toward. In addition to the mission and Agile team will also seek a product vision, making it clear what outcomes the team is responsible for and where your team's boundaries are. This may sound a bit like management speak, but I like to think about it this way. And mission tells me why we're doing the work. A product vision helps me imagine what the work will be like when we're done. Now, let's discuss scrum team roles. Every Scrum Team consists of three defined roles. A Scrum master, product, owner, and the development team. These roles work together to achieve the team's objectives and realize the mission and vision the product owner is responsible for what a team bolts. They also must ensure everyone understands the why. For example, a company needs a product owner to capture and promote the great ideas coming from the team. The product owner's job is to build the right thing. The development team is responsible for how a team will deliver that product. The development team is building websites, integrating billing systems, and fixing issues. The development team's job is to build the thing, right? The scrum master is responsible for when a team will deliver value to its users. This role is roughly equivalent to the project manager role in traditional projects. The Scrum Masters job is to both the thing fast. Although they are clearly defined roles on a Scrum team, it's important to note that the entire team works together to achieve its goals. In other words, although they are specific expectations for each role, the development team may still contribute ideas for the what and the wing of a project. While the product owner may contribute to discussions on the how of the project. As a collective, Scrum teams must exhibit a few specific skills on your scrum team. You must have a software developer, a marketing specialist, a quality assurance and logistics expert. Scrum teams are self organizing. This may sound radically different from other organizations you've worked at before, where your manager dictates your tasks and request frequent updates. But because Scrum teams rely on those five values, commitment, courage, Focus, openness, and respect. The Scrum Team is able to work together to deliver amazing results in a more organic and flexible environment. Although teams are self-organizing, high-performing Scrum teams often have a manager who sits outside of the Scrum team and provide strategic leadership and individual career development without disrupting the self-organizing nature of Scrum. In my experience, if a manager feels compelled to start telling the team what to do and interferes with the self-organizing nature. The benefits of the Scrum will begin to collapse. Now that you have a better understanding of what constitutes Scrum team, will take you through the specifics of each roll. In the next few videos, we'll start with the traits of an effective scrum master. 10. Scrum Master: Welcome back. We've already mentioned that in Scrum, the project manager is most likely playing the role of Scrum Master. So what exactly does a Scrum master role in detail? In this video, I'll further define what a scrum master is. They now explain some of the differences and similarities between a scrum master and a project manager. The Scrum Master promotes and supports the Scrum process by helping everyone understand and implement the Scrum. This includes its practices, rules, and values. My favorite way to describe the role of a scrum master is that they are responsible for helping the team be. They vary based. They can achieve this by coaching individuals on the team to manage external forces, as well as maximizing the teams internal potential. The Scrum Masters responsibilities include coaching team members on the Agile and Scrum practices, rules and values, and helping to find ways to manage the product backlog effectively. The product backlog is the single authoritative source for things that a team works on. It contains all of the product features, product requirements, and activities associated with deliverables to achieve the goal of the project. The Scrum Master facilitates scrum events such as Sprints retrospectives, which happened at the end of every sprint. The Scrum Master helps the team remove any blockers to their progress, such as missing information or access to training or tools. The Scrum Master also prevents unhelpful interactions or interruptions coming from outside of the team. Finally, scrum masters must be great communicators, particularly when it comes to stake holders. Scrum Masters, or experience engaging with diverse stakeholders who may have competing perspectives and styles. The role of the Scrum Master differs from a traditional project manager in the following ways. As they primary responsibility, the Scrum Master acts as a facilitator and a coach to the scrum team. And they need to make sure that they have enough time in the day to do this job. First and foremost, if the company requires the management of many additional project management activities, then the team might hire project managers who owned that more traditional project management orientated work. That work may include things like budget management, risk spreadsheets or Gantt charts. But seed, it's common for traditional project managers to take on the role of a scrum master. Now you know a bit more about the pillars and the role of the Scrum Master. To recap, a scrum master must possess skills like organization leadership, the ability to facilitate, coach, and manage stakeholders. And the Scrum Master can be quite different from a project manager in terms of their responsibilities. But the role may be played by the same individual since they require a similar skill set. In the next video, we'll learn what a product owner does meet you there. 11. Product owner: Hi again. In the last video, we reviewed the role of the Scrum master. Now I'm going to give you an understanding of what the product owner dies. You'll also begin to notice how the relationship between the product or not and the development team works. A product or RNA is tasked with ensuring that the team is building the right product or service. And efficient scrum team isn't useful to anyone if they creating a product that uses don't want. The product. Rna ensures that the team is building the right thing, a product or needs responsible for continuously maximizing the value of the product delivered by the Scrum team. They key activity is acting as the voice of the customer within the team. They represent an express the voice through the ownership of the product backlog. A quick reminder, the product backlog is the single authoritative source for things that a Scrum team works on to achieve the project goal, the product, or in its responsibilities, also include helping the scrum team understand why they work matches with the overall goal and mission. They also prioritize the product backlog to optimize the delivery of goals and deliver value to customers. The product or in a ensures that the product backlog is visible and transparent to all. And finally, they are responsible for making sure that the product or service fulfills the customer's needs. That's a lot. So how do product or NAS accomplish all of that? They rely on the key character traits. A product or in his role requires them to be customer focused. They must understand a customer's needs and the industry of the business extremely well. Product or NAS also have to be decisive, great communicators, and understand both sides of the issue so they can defame the decisions to the team. They must be flexible and open to new information that can generate a profitable change for the team. And they must inspire the team to believe in the mission. Product earners also have to be available. The iterative nature of Scrum means that the team needs the product or net to help inspect, adapt, and plan the next iteration on a regular basis. And finally, they must be collaborative product or in is we'll have to work with a team to ensure that the customer's needs on mate. And that will require meeting with and working alongside several stakeholders. So as you may have noticed, the product earners are responsible for a lot of the project, just like the scrum master. So to recap, we discussed that a product or in that acts as the voice of the customer and his customer focused, decisive, flexible, optimistic, available, and collaborative. Next up, we'll discuss the role and traits of the development team. 12. Development Team : Hi there. In the previous video, we discussed the role of the product, are now on the scrum team. In this video, we'll discuss the development team. Within a Scrum team. The development team is made up of the people who do the work to both the product. The size of the team ranges from three to nine people. This ensures that the team is small enough to remain nimble, but large enough to complete significant work within each sprint. Getting the team size just right is important. Smaller teams can struggle with diversity of skills and ideas, while larger teams may run into issues, there are too many opinions and streams of communication. The development team should be cross-functional. So they're capable of building the product or service in-house. Since the team has all of the required skills. The development team also owns their own processes and structures. They have to be self-organizing and can't rely on others to tell them how to organize their continuously operate as a team rather than individuals, and they support each other in reaching the team's goals. Lastly, the development team acknowledges that the base products emerge from teams who are customer oriented and focus on the user when bolding their products. Many Scrum teams prefer to be co-located, meaning they work alongside each other in the same physical space. Many believed the team delivers high quality work and improves Foster if they're co-located. But this isn't always possible for every team. At this point. We've covered each role within the Scrum team, a product or is responsible for meeting customers needs, also known as building the right thing. A development team is responsible for creating the product, also known as bolding the thing right? The scrum master is responsible for improving efficiency. Also known as bolding the things. We know that each role is vitally important in achieving the goals of a Scrum project. Individual is more or less important than the others. They all work together as a team to create value for the users and customers. In the next set of videos, we'll review what we've learned. 13. Product backlog: Now we'll look at an important factor of the Scrum framework, the product backlog. In an earlier video, we defined the product backlog as the single authoritative source. Things that a team works on. It contains all of the features, requirements, and activities associated with deliverables to achieve the goal of the project. The traditional non-agile project management equivalent would be the state of project requirements. There are three key features of a product backlog. Thirst. The product backlog is a living artefact, meaning that items are added to the backlog at anytime. The product backlog evolves throughout the whole life cycle of the project and serves as a central DOD for the team to know what to work on. Next. Second, the product backlog is earned and adjusted by the product owner. And finally, the product backlog is always a prioritized list of features. So when these new information or new features, those are added to the backlog in order of importance. The items at the very top of the list of very specific and well-defined, leaving the bowl vague items for the bottom of the list. Because the backlog is soy seeing tool, there are a few best practices and pieces of data to capture when working with product backlogs. There's the description, the value, the Oded, and the estimate. Let's go through how to build a sample backlog with these best practices in mind. First phase, the item description. The item description is exactly what it sounds like. It describes an item. When you're writing an item description, it's a good idea to be really clear when adding product backlog items. So the details are encouraged. This ensures that the development team has enough information to meet the user's needs. Next up, we have the value field. This is the field that tells us how much business value the item delivers to the customers, to the team, or to the users. How to indicate value is a choice the Scrum team should make together. A common method is to seq valued by using dollar signs, ranging from $1 sign for low value all the way up to $4 signs for high added business value. Next, we have to add in an estimate. And estimate is how much a fit the scrum team thinks in autumn will take to complete. We'll explore how to do radiative aphid estimation coming up. But for now, it's important to note that the relative effect estimate is captured in each backlog item. This field in the backlog is owned by the development team. The next attribute of each backlog item is the order. As we mentioned, the bedrock should always be prioritized. Both the estimate and value fields we just discussed help the product owner figure out a way to place an item in the backlogs Oda of heirarchy, a project or an, I may ask themselves, how important is this backlog item compared to all the other items? Product backlogs order items from highest to lowest priority. This is cooled as stacked rank ordering items. This way allows teams to operate more efficiently. Now you know a bit more about defining the product backlog and who owns it. We also discussed how the various roles work with the product backlog. And we can identify and describe each field in the product backlog. In the next video, we'll learn how to manage the backlog which changes throughout the Scrum practices. Meet you, they 14. User Stories: In the last video, you learned about a product backlog. We discussed that in order to properly bow the backlog, the Project Manager must consider factors like descriptions, then you order and estimations. This ensures that you as the project manager, will include enough information to meet the product or in his vision for user venue. Now that you know about the various fields associated with each item in your backlog. Let's discuss a popular way to capture and manage those backlog items. Uses stories. User stories are short, simple descriptions of a feature told from the perspective of the user. This helps the team creates a solution that's always painted around the user and the user experience. User stories much stopped or for large and broad, or may be broken down to be as small or as specific as possible. In this lesson, we're going to give you some idea on how to write user stories and how to break them down. Uses stories are made up of three different elements. The user, the action they will take, and the benefit to name. These elements might have a few different formats, but the most common is as a user role, I want this action so that I can get this value. Writing effective user stories, the team must have a using mind. Imagine that the user will interact with the product in order to achieve a specific outcome. What I really like to do at this stage is create persona's or detailed descriptions of my different uses. Sometimes I even give them names. Each user story should meet six different criteria, represented by the acronym I, InVEST or invest. Eyes for independent, the story should be able to be started and finished by itself. It's not dependent on another story to finish it. The N stands for negotiable. There's room for negotiation and discussion about this item. The V is for valuable. This means that the completing the user story has to deliver value. E is for estimable, our definition of done must be clear so that the team can give each user story on a estimate. The aces for small, each user story needs to be able to fit within a plant sprint. If that user story is too big, it should be broken down into smaller stories. Stories that are a low priority on the backlog can stay big until they become a priority for an upcoming sprint. Finally, the T is testable. It tastes can be written to check and make sure that it meets the acceptance criteria. While the product owner is the main person responsible for writing user stories, the team has responsibility to give feedback on whether the user story is TEA and fits the invest criteria before they invest any time into it. In addition to user stories, you need to know the term epic, which simply represents a group or collection of user stories. Lastly, acceptance criteria, AAC, conditions that a software product must meet to be accepted by a user or a customer or at the system. They are unique for each user story and define the feature behavior from the end-user's perspective. Fantastic. Now you know how to explain user stories. The criteria for assessing user stories readiness for the team. And you can explain it, picks and user stories acceptance criteria. In the next video, we'll discuss backlog refinement and explain relative effort, estimation. T-shirt sizes, and storypoints. Me today. 15. Backlog refinement : Welcome back. We've been exploring everything there is to know about a product backlog. Although the product are no other 0s or isn't charge up the dotting the backlog. The team must work together to keep the living document up-to-date. In this video, we'll discuss how to do that through a process called backlog refinement. Backlog refinement refers to the act of keeping the backlog described, estimated, and prioritized so that the scrum team can operate effectively. Often the product or RNA has added the backlog items with a description and a venue statement. They do backlog refinement. Backlog refinement is when the product, some or all of the scrum team review the backlog to ensure it contains the appropriate items and that nothing near as needed or nothing needs to be removed, that the items are prioritized by the product R in it. This is also called sifting the order field that the items at the top of the backlog are ready for delivery with T acceptance criteria. And at the backlog, items include estimates or an informed decision about how much work a particular backlog item will be. Let's discuss estimates since they crucial and backlog refinement. We add estimates to backlog items to inform up planning practices about how much, if it, it will be to finish each item or uses story. Through estimation, we can find out how much work we have ahead of us. It can be difficult to estimate the amount of time it takes to complete a task. More often than not, we human beings tend to underestimate the time until completion. When it comes to big projects, this effect can be multiplied many times and can be the root cause of projects being late and over budget. In Scrum, we tried to overcome this problem by practicing relative estimation instead of absolute estimation. Absolute estimation is also called time and effort estimation. In traditional project management, relative estimation means that instead of trying to determine exactly how long a task will take, we compare the effect of that toss to the effect of another task and that becomes the estimate. The estimation is not done in traditional units of hours, days, or weeks. In state, we assign each backlog item a bed you, that is a relative unit for size. There are two common relative estimation methods that I found most useful when estimating uses stories. These are T-shirt sizes and story points. Let's start with the simpler of the two T-shirt sizes. To get started, the team simply picks one item on the backlog that seems to be about a medium-size workload and simply calls that a medium in the estimate field. Off to that, they take another item on the backlog and compare it to the medium item that just identified and answer the question. If that first autumn was a medium, what size, what I give this one, the team will repeat this process on each additional item or uses story on the backlog until they're all addressed and done. Story Points are a bit more advanced than T-shirt sizes, but the concept is similar. The first step is the same. The team picks an item as they ANCA item, and they'll conduct the estimations relative to that item. Instead of using T-shirt sizes, this process uses what are called Story Points. Most teams use a famous mathematical sequence of numbers called the Fibonacci sequence. The Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21, and continues onto infinity. These numbers are spatial in that they start up close to one another. But as the numbers get higher, they sprayed through that and further out. This is helpful because as the estimate gets higher than uncertainty and risk also against higher. This number combines both if it adds risk into one number. In other words, there's not much use in debating estimation values between 21 and 25 points. But choosing between 2134 is a real conversation. This concept can be tricky at first, but practice is the best way to learn it. Some teams prefer to sit up spatial meetings just to refine the backlog. I, this will simply refine the backlog continuously in conversations or e-mails. Finally, some teams will conduct backlog refinement as part of a schedule debate, like they sprint planning meeting. Now you know how to define backlog refinement and you can explain relative effect estimation, T-shirt sizes, and story points. In the next video, we're going to learn more about Sprint Planning. See you, they. 16. Scrum events: Welcome back. As you learned earlier, sprints, which we also called iterations, provide the whole of rhythm for the team and is one of the five Scrum events. They allow us to get feedback quicker, encourage team collaboration, and provide more focus for Scrum teams. Within a sprint, the amount of work is planned based on the historical capacity of the team and is made ready for the sprint planning event. It might help to think of each sprint mini-project with planning, execution, delivery, closing, and a retrospective all wrapped into these bite-size package. Sprints are so important to Scrum that the other force Scrum events revolve around the sprint. The five events are as follows. The Sprint itself, Sprint Planning, Daily Scrum, Sprint review and the sprint retrospective. And this video, I'll share with the recommended duration or time boxes for each of these evades. A sprint timebox can range anywhere from one to four weeks. How do you choose? Well, there are three considerations. First, think about what you expect the frequency of changes to be. How often do you think your requirements might change? If you expect your project, you have near Christ's popping up each week, you may want to make your sprint length one week so that you can adapt more often. If the needs are more stable, perhaps longer will be just fine. Second, think about how much focused time your solution developers might need to build a backlog item. If the baseline effect for most of you activities requires at least a week to create something valuable. They know sprint length should be at least two weeks to give the team to execute without feeling the crunch mode. Third, think about how much overhead goes into a delivery of your product. If your deliverable or solution requires a larger view with many stakeholders, goes through a rigorous testing quality assurance process that takes several days. You should factor that into your sprint length and choose a longer sprint, such as three or four weeks and stayed. Like most things in Scrum, there is no one size fits all. If you sit to sprinkling and decide it's too long or too short after few sprints, you can always change it. For example, my current team has sprints that I'll one-week long because we expect a lot of change and new requests coming into our backlog every week. But often our work takes longer than a week to complete. Great. Now you know more about defining the sprint. In the next few videos, we'll discuss the relationship between the other Scrum, the veins and the sprint. We'll start with the veins leading up to the sprint, conducting sprint planning and compiling the sprint backlog. See you, they. 17. Sprint planning : Hi again. In the last video, we discussed the parameters for a sprint. Next up is sprint planning. The first debate within the sprint that suits your team up for success for the next one to four weeks, depending on the length you choose. For Sprint Planning, the entire scrum team comes together and meets to confirm how much capacity, meaning time and people are available during the sprint. And they, they identify what items from the backlog we'll be done during the sprint. This becomes the sprint backlog and ultimately the sprint goal. This is a time for the scrum master to facilitate team communication and answer the following questions throughout the veined. Who is available during the sprint? Are they any vacations or conflicts that we should know about? What has been our average velocity. Meaning how many points will backlog items have we been able to complete in a single sprint in the past? What can and should be accomplished by the team in this upcoming sprint? What is the ultimate sprint goal? How will the work get done Throughout the sprint? Who is responsible for what tasks? We've discussed, sprint lengths and story sizes. So let's explore the meaning of definition of done. Definition of done refers to an agreed upon set of items that must be completed before I use a story or backlog item can be considered complete. Some things that may be within your definition of done. All the code or solution itself is reviewed by an independent PI group. The product or unit pauses old tasting requirements, which could include security or performance tasting. Documentation is completed. Old uses story acceptance criteria specified by the product RNA is made. And finally, the product or net X6, the user story. This list isn't comprehensive and the team should determine what should be on the list and improve it as needed. A key deliverable of the sprint planning event is the sprint backlog. The sprint backlog is a state of product backlog items that are identified for completion during the upcoming sprint. In other words, the sprint backlog is a subset of items from the product backlog that you'll aim to finish during that particular sprint. Planning will result in a well-defined and estimated sprint backlog, as well as sprint goal to keep the team motivated towards that final achievement. See you in the next video where we'll cover more sprint debates. 18. Daily Scrum and Sprint Review : As a refresher, one of the principles from the Agile Manifesto states the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In this video, we'll discuss communicating with the team through two kinds of face-to-face events that occurred during and after the sprint, the Daily Scrum and the sprint review first, the Daily Scrum, which is sometimes referred to as Stand up. Is it Tom for the scrum team to synchronize and prioritize activities for the day in 15 minutes and at the same time and place every day each team member answers the following questions. What did I do yesterday that helps the development team meet the Sprint Goal? What will I do today to help the development team meet the Sprint Goal? Do I notice any impediment that prevents me or the development team from meeting our goals. Daily stand ups should provide the scrum master with the opportunity to quickly unblock the team with little delay. Daily stand ups on an opportunity to reinforce focus on the sprint backlog and Sprint Goal. Daily stand-ups must happen every single day. How if it is up to the team to decide if they wish to need less frequently than that. At the closing of a sprint, the team will compete another event known as the sprint review. This sprint debate is crucial to the Scrum punishes of inspection and adaption and demonstrates the values of openness, carriage, and respect. Let's discuss what I mean by that. The sprint review is a meeting within the entire scrum team with a product is demonstrated in order to determine which aspects of finished and which aren't. During a sprint review, the development team and product owner will play a heavy role in this inspection and discussion. They'll also cover an exploration of which item should be considered done in the product backlog. They'll demonstrate and inspect the product. Sprint reviews should be really fun and uplifting. The sprint review is when the team gets to embrace each other with a cool things they've accomplished over the last one to four weeks. These timebox meetings should not exceed four hours. They are a good opportunity for the team to practice the Scrum values of openness and respect as they give feedback about the completed work. Often some of the greatest product ideas come out of the sprint review. Using a group inspection of a work product from the team has many benefits. First, it makes the feedback as immediate as possible, nor need to wait for people to review on their own and st in their feedback later on, feedback and adjustments must be made right? They, in the meeting. Second, everyone has a voice leading to a shade sings of ownership of every aspect of the product launch. Last but not least, the team learns more about how they marketing teammate does the job, leading to greater trust and understanding between team members? The sprint review is a time for the team to demonstrate what they've accomplished. The sprint review is also a team member's unveil what is called the Product Increment. The Product Increment is what's produced off to a given sprint and is considered releasable. A product is releasable when the team has developed a minimum viable product, which has a state of implemented features or requirements. A minimum viable product is a version of a product which with just enough features to satisfy early customers. At the end of each sprint, only atoms that have made the definition of done all considered part of the Product Increment. Anything that is not done, goes back to the product backlog. In the next video, we'll discuss another important meeting that takes place on a Scrum team, the Sprint Retrospective. Me today. 19. Sprint Retrospective : In this video, we'll cover the loss of the five events of Scrum, the Sprint Retrospective. The sprint retrospective is an essential meeting of up to three hours for the scrum team to take a step back, reflect, and identify improvements about how to work together as a team. In a Sprint Retrospective, the scrum team will reflect on what's working or not working for the team regarding the people, the processes, and the tools, what improvements are worth exploring in the next sprint? What improvements were put in place for the last sprint? Were they helpful or not? And why? In my experience, there are some key measures to take to ensure sprint retrospectives are a success. First, it's important to demonstrate scrum value of respect and always allow the team to remain blameless. If any team member is worried they may be negative consequences for providing feedback, your outcome won't be as been official. You'll need to create a safe space for Canada by acknowledging potential awkwardness and if needed, creates a space for anonymous or private feedback. Participation is key because retrospectives only work if participants feel like they input matters. If you noticed folks on volunteering their perspectives, search for ways to generate new ideas, such as asking them, what is one thing we could try the next sprint? What slowed us down? What happened that we didn't expect? Next? Balance, the negative with the positive. Don't just ask where you can improve, but also asked things like, where did we notice success? You want your team to feel like they were successful, and you also want to recreate these successful outcomes. Finally, make sure to act on IT. Teams can get discouraged from participating in future retrospectives. If it feels like they feed back Washington spy, change, search for improvements, or simply convert the things that worked based into your teams habits and norms. Facilitating conversation among the scrum team. But during retrospectives and in everyday workflows is an incredibly important aspect of being the Scrum Master and the Project Manager. In the next video, we'll discuss how to remain transparent with your workflow through the use of essential Scrum tools. These will also help facilitate good communication within the team. Meet today. 20. Burn Down Charts and velocity : In this video, we'll explore two very important concepts that allow a Scrum team to manage their work as they progress through as sprint and the entire product backlog, these two concepts are burned down charts and velocity. Let's start with what a burndown charts purposes and how a Scrum team uses it. A Burndown Chart measures time against the amount of work done and the amount of work remaining. The goal of using a burndown chart is to keep the team a way of how they doing against their overall goals. In a Scrum team, burndown charts reflect how the team is doing with completing user stories during the sprint. The scrum master will review the burndown chart, sometimes day to examine if the team will hit their goals or not. Now's a good time to mention what to do if your team is using T-shirt sizes rather than Story Points. In that case, simply met the sizes to a number and use that number for the burndown and velocity calculations. For example, maybe an extra small as 1, as small as two points. A medium is five, a lodges eight, and so on. For example, let's imagine a sprints or full weeks long, which will count as 20 business days. In the July sprint, the sprint backlog had stories that added up to a total of 200 points to be completed. If you assumed an even burn off points or the business days, you'd expect Tim Points to be burned each day. By day five, in the Sprint, 22 points had been burned or completed. It's only 25 percent of a sprint. So maybe things are on track by day, obtained 45 points at being completed. We should have been approximately halfway done by now, which would be 100 points. According to the burn down chart, we're running late according to our sprint goal. Now this isn't the time to panic and stress off the team. At this point as Scrum Mostyn, you should already be discussing with your team to find out how you can help an unblock them. In Scrum, There's a term for how many points AT team burns down in a sprint on average. That term is velocity. In other words, velocity is a measure of how many points AT team burdens DOM during a single sprint on average. When the team is conducting sprint planning, they using the average velocity over at least three sprints to determine how many items they can safely add to the sprint backlog. There are a few things with noting when it comes to calculating velocity. First, there's no such thing as a good velocity or bad velocity. Velocity is simply what the team has started keeping able to achieve predetermined time box. The next thing is that each team will have a different velocity, especially since each team decides they earn points system calibration. It's impossible to compare your team's velocity to another team's. Once you have a stable velocity and a refined backlog with prioritization and estimates. This unlocks and incredibly valuable superpower. You can now tell you a stake holders and sponsors two important things. You can tell them approximately how long it will take to complete the entire product backlog and how much of the backlog will be completed by a particular time. This ability to confidently predict when things can get done is one of the most powerful tools in Agile and Scrum. Now you know how to define velocity, velocity trends and burn down charts. You also learned a bit about how an agile team reaches a stable velocity and what that entails. Using these tools is essential to any high performing Scrum team. They are powerful means to achieve execution predictability. I'll demonstrate another useful visualization tool in the next video. Make me they. 21. Kanban board : We learned about the importance of visualizing progress using burn down charts in the last video, the two we cover in this video may be familiar to you since we briefly covered it in a previous video. It's the Kanban board. Some teams referred to this as the Scrum board, rather than the Kanban board. The board has three main features that make it a great spring tracking tool for Scrum teams. These visualization work in progress limits, also known as WIP limits, and flow of work. Visualization can be unimportant strategy for learning and tracking. This Kanban board communicates everything we need to know at a glance. We can point at specific work items on the board we want to discuss, use images with variation and colors and sizes as we check in on work items. And we can notice way the challenges are in our team. Without this visualization, it's not as easy to find out way we can make improvements. These boards make it easy to notice way the WIP limits break. We learned earlier in this course that come in WIP limits or constraints on how many work items the team actively works on at any given time. This provides focus for the team, which is one of our scrum venues. When you use a Kanban or Scrum board, each team may say to a WIP limit based on the configuration and context. This way, it's really obvious to notice when the team is going beyond the WIP limit. And finally, using a Kanban board can give you a better sense of the flow of work through the team's execution processes. Physical Post-it notes, or even virtual versions of Kanban or Scrum boards allows the team to experience the movement of work from one phase to another. Using a Kanban or Scrum board, the team will move the items through the following stages to do doing and done. This action often takes place during the day Scrum, but the team can move items at any time. To recap, Scrum boards are really useful because they help you visualize your progress, seat and maintain your team's workload and WIP limits. And give you a sense of the flow of work through out the team's execution process. Awesome. I'll see you in the next video. 22. Value Roadmap : Hello again in this video are unexplained what a value roadmap is and what you need to create one. As a project manager, parts of your job is to help team stay focused on delivering value. A great way to do this is to build a venue roadmap. It's an agile way of mapping out the timelines and requirements for the product development process and can be used in all types of businesses. This roadmap is a guide that demonstrates way to guard how to get the and what to accomplish along the way in order to maximize venue. It helps map out a product idea and the strategy for how to deliver it. As the team follows the roadmap, they gather input from customers and stakeholders and apply the findings to each iteration of the product. Creating a roadmap helps the team explain the vision of the product and can also be used to identify important milestones. A typical value roadmap has three components. A product vision, a product roadmap, and release plans. The first component of a venue roadmap is the product vision. Your product vision is a critical state to starting any new Scrum project. Your vision is based on your user interviews and market analysis and becomes your teams Northstar. In other words, it's what guides your team. The product vision defines what the product is, how it supports the customer's business strategy. And 2, you will use it. Next, there's the product roadmap, which the product earnest responsible for creating and maintaining. It provides a high level view of the expected product, its requirements, and an estimated schedule for reaching milestones. It's key to making sure your team is building the right thing. The third component of the value roadmap is a series of release plans. The product Arnett and project manager worked together to develop these plans. Product releases occur when the team has developed a basic working version of a given feature or requirement. A release plan includes the approximate date when the team is expected to release and deliver certain features to the customer or user. And Agile team may have several releases over the course of a project until the project is considered done. For this reason, only the first release date should be considered to be six in starting. The race of the release plan is based on early estimates and is subject to change as the project proceeds. A release plan contains a release goal, which is an overall business goal for the features you're planting queued in the release, the list of the backlog items such as a big user stories or features that you require for that release goal, An estimated release date, and any other relevant dates that make an impact like a convention or major holiday. It's important to add all of your release plans to your bed, your roadmap to help you stay focused on the path to your overall value goal. In summary, the venue roadmap contains three components, the product vision, product roadmap, and release plan. These three work together to help an agile team reach its goals through multiple iterations. A venue roadmap only works if the team is collaborative and all stake holders where to go there regularly. This will ensure that the project achieves results that aligned with the Agile values and principles. Awesome. Now you know how to create a value roadmap. In the next video, I'll share some tips that will help you create an effective value roadmap. 23. Insider Tips: Hi again. In the previous video, I introduced you to the concept of a value roadmap and described its three main components, product vision, product roadmap, and release plans. In this video, I'll share some tips for creating an effective value roadmap. My first tip is about creating the product roadmap. The product roadmap provides a high level view of the expected product, its requirements, and an estimated timeline for reaching milestones. Many of those milestones will be product release dates. You'll need to ensure that product release dates are only rough estimates. This is because as an agile team, you know that things can and do change. This is especially true since these dates could be any wave from several months to several years down the road. If the roadmap is too specific, it might set the team up for failure because the dates can't be guaranteed. Speaking of product release dates, this leads me to my next step, which is about the release plans. There are some important things to note about creating a release plan, which includes approximate target release dates. It's very important that the product or RNA and project manager or scrum master work together to develop each release plan. This is because the release plans need to connect the product roadmap with a team's capacity and velocity. The capacity and velocity is the measure of the team's ability to complete word at a certain pace. A release plan that isn't connected to the team's ability to complete work could be unrealistic and lead to an unsustainable pace for the team. If there are any hard dates or deadlines on your roadmap, meaning a date that cannot change, factor this into the release plans that might be affected. Communicate hard deadlines with your stakeholders. So there's a clear understanding of must-have features. This way, if the team discovers it might be at risk for not meeting the deadlines, they can quickly focus on the must-have features. Since Agile is all about embracing and anticipating change, it might seem like having a release plan goes against the agile value of responding to change over following a plan. But having a release plan does not mean you are resistant to change. An agile team treats a release plan, is a living artefact. So the plan can change based on the environment and new information that's received. Some common factors that may result in a change to the release plan could include a change in team velocity or how much work the team can do in a given iteration or sprint. This could be from adding or losing team members or even just efficiency gains from how they work. The second factor is that change to the product scope if the product or not approved a change to the product. And a third vector that could affect the release plan is improving the understanding of how much, if it is needed to build certain features. The team may discover that a user story or Epic is more or less difficult than they originally thought after doing some research or simply from beta understanding the product space. My last tip for creating an effective value roadmap is that the scrum master or project manager should always review the release plan before starting a sprint planning session. They review the release plan to check whether the team is on track. If the team is off track, the Scrum Master needs to have an open conversation with the product RNA and business people to figure out what they can adjust to get back on track. This is where the Scrum venue of transparency is key and effective value roadmap is a powerful tool for building and delivering successful products. The plants you create will help you stay focused on delivering maximum value and the ability to remain flexible and stay agile. In the next set of videos, we're going to switch gears and discuss some common challenges that you might encounter when introducing Agile and Scrum, or we joining an organization that is transitioning to Agile. I'll share some tips for how you, as the project manager, can help support and coach your team along the way. Nietzsche, they. 24. Moving to Agile: Hi there. In this video, I'm going to discuss your role as a project manager in an organization that wants to implement Agile practices. The techniques I'll share with you in this video, we'll sit you up to be prepaid to help set up and move an organization to agile. Understanding organizational culture and the change management process is crucial when introducing new ways of working. Organizational culture is based on shade, where it Paste Values and pops up in people's behaviors, activities, the way they communicate and how they work with each other. It changed, that's out of sync with the existing culture is much more difficult to complete. In fact, these research proving that companies that don't consider the cultural aspects of Agile or more likely to fail. Change management is the process of getting folks to adopt a new product process or an Agile's case in your venue system. Let's look at how to help introduce or continue the adoption of Agile or Scrum into an organization. Unless the organization has many years of age, all behaviors and experience, you may be facing a change in organizational culture. These changes take time, sometimes years to complete. As a project manager, you might only implement a few changes and that's okay. You'll still be adding value by demonstrating to your team or organization new and different ways of approaching their business. What are some ways that you can bring agile or scrub to a new team? First, you create a sense of ownership and urgency. When people feel a sense of ownership and urgency around a project, it increases interest, motivation, and engagement with the project outcome. One way to create a sense of ownership is to find an executive sponsor who also feels a sense of ownership for the change you're creating. Wherever possible. Point out connections between the changes you're making and the company's stated mission or values. Having buy-in from someone at the top increases your chances of successfully driving any change in organizational culture. Ideally, your sponsor will reinforce the benefits of agile to the organization and give you the support and resources you need. What about creating a sense of urgency? The based approach to this is to ask the team, the organization, and the stakeholders questions about what's working and what's not working right now. Then I ensure that the changes relate directly to those opportunities. Here are some questions you could try. What is preventing us from providing the best possible product to our customers? What is allowing our competitors to outperform us in this market? How can we help our teams to become more productive and supported in their work? Bringing Agile or Scrum to a new team could be challenging, but well worth the effort. By applying some of these techniques, you will increase your chances of success. I've found that with a little patient persistence, you can get past some of the initial skepticism and the benefits of an Agile approach will start to become obvious to the team. Once this happens, change will become easier to drive over time with a commitments. In the next video, we'll look at some challenges you will encounter during the change process. 25. Challenges : Hi there. In this video, we'll go through some of the challenges you might encounter during a change prices that are specific to agile teams. As the project manager or scrum master, it's your responsibility to help teams improve how they work and coach them how to effectively adopt Scrum practices. So anticipating and understanding how to work through common challenges before they happen is super important. The first set of challenges are related to venue delivery, which is about making sure the team is delivering working solutions frequently. Some signs that your team is experiencing value delivery issues could include things like the team has started missing expected delivery dates and is taking a lot longer than usual to complete tasks. Or you might notice that the team seems burned out, is working long hours and showing signs of exhaustion. Or maybe the team has too many items in progress at any given time, preventing tossed from actually getting to done. If you start to notice your team is struggling in these areas, there are few things you can do to help. You can try doing more demos of the solution with the team to ensure they delivering on the venue roadmap. When the team pauses to take in a big picture view of the working product that often notice areas where they can improve and speed up the work. You can also use retrospectives to OSC the team, if anything is slowing them down, like waiting on dependencies or communication challenges. It can also help to do a quick review with the team and make sure that everyone understands what done means. And finally, be sure to focus on only a few user stories per sprint. This ensures the team finishes and item to gather before moving on. It's better to maintain focus and deliver few backlog items in one sprint, then to deliver a lot of items in more sprints. Okay? Another set of challenges you might encounter relate to the business collaboration theme. To recap, business collaboration is about making sure that developers are collaborating with business people on how to build the right product. There are a few common signs that your team might be experiencing business collaboration issues. You might notice that the teams are overwhelmed with critical feedback or change requests from business people. Often they reviewed the working solution that could lead to people on your team avoiding asking for feedback or complaining about requested changes coming from the product or net or business team. Or you might start to detect an us versus them mentality between the team doing the work and management. Team members may say things like, Darren give a demo to the salesperson, it's not radiate and they'll just point out what's wrong. If you notice any of these signs. There are few things you can do to help rebuild trust and collaboration between the developers and the business people. To start with. Try addressing critical feedback and change requests by doing more demos. This ensures feedback comes in at a steady pace and that everyone involved has a shade and standing of what done means. Next, consider conducting a solution design sprint, which is an entire sprints sprint working certainly on the solution design. These are most effective when the working team and the business people actually sit together and collaborate on the solution. Finally, you can help your team focus by ensuring changes to the backlog are introduced only in-between sprints. This pervades your team from getting distracted by possible changes which could stress them out and lead to resentment. The third theme is team dynamics and culture. Human beings are complex creatures with lots of different motivations and styles of working. So it's likely that you'll encounter at least a few challenges in this area. Here are a few common signs of team dynamics and culture issues to watch out for. First is low team morale. If people are super grumpy, irritated or January in a bad mood, then you might have some underlying team dynamic issues to sort out. Next, chapter 4 signs the team is experiencing lots of conflict. If people are arguing a lot of issues aren't getting resolved, the team probably needs some help. Not everyone is going to get they weigh. If team members feel resentful or hold onto graduates, it will negatively impact the team's performance. And finally, and this might surprise you, but low conflict can also be assigned that the team is experiencing issues. We'd usually taught to believe that no conflict is a good thing, right? But if a team never has disagreements, it's a sign that they might be worried about starting conflict because they don't feel like it's a safe environment. Being open and courageous or two of a scrum values, but it's not always easy to put them into practice. As a project manager, part of your role is helping your team get comfortable, being honest with each other and working through conflicts together. If you notice these or any other clear signs of team districts, you awesome ideas you can try. You could run a team brainstorm session about how to work better together off the team to identify some areas to improve on. An example exercise could involve asking the team to write down stories about the worst team they've ever worked on and the bass team they've ever worked on. Then sharing them in a meeting. Then you might have the team created list of do's and don'ts for working together based on the stories, everyone shade. Another idea is to change up the workflows. Try pairing up people to work together on a hard task will change up the way you run one of your regular meetings. It can also help to take a training process to gather or watch a video about team dynamics and discuss it as a group. You can also try a retrospective technique from the Internet. There are a ton of great resources update. Now you've got some idea of some of the common challenges Agile teams might face and how to address them. Coming up, we'll explore some more issues. You might encounter it as a project manager or scrum master. 26. Coaching Challenges: In this video, we'll discuss a more common coaching challenges you might encounter while managing an agile team or project. Whether they're new team or they've been around for a while. The three challenges we'll focus on managing a stable product, roadmap, incomplete implementation of Scrum, and experiencing a lack of stability within the team. First, let's discuss the challenge of managing a stable product roadmap. Agile projects almost always experienced changes in the product roadmap. Being able to respond quickly and productively to these changes is a core Agile value. But it is possible to have too much change impacting the project, which can lead to an unstable product roadmap. There are two main causes of an unstable product roadmap, product ambition and product assumptions. Let's cover product ambition first. Product ambition poses a challenge when product leadership is overly ambitious about what the team can realistically deliver. The product owner is responsible for representing the project to customers and executives because the product owner wants to make the stakeholders happy. It can be easy for them to over-promise what the project can deliver. The second thing that can cause an unstable product roadmap is making too many product assumptions. Wendy's uncertainty and a project, you may be required to make some assumptions to move things forward. But making too many assumptions can jeopardize the team succeeds. How do you overcome this? You document the assumptions and make them transparent. This allows you to discuss the assumptions as a team and other greed that they're safe assumptions to make or decide to question and double-check them. If you do decide to double-check theme, you can use unbiased user research. Unbiased user research, get us information about what users really want. It allows you to confirm or reject assumptions and helps you move forward with competence. User research could involve conducting surveys, running focus groups, or using other methods to collect objective data about your users. The next big challenge you might encounter relates to an incomplete implementation of Scrum. This happens when Scrum practices are only partially implemented or when Scrum practices are implemented without proper support and coaching. Scrum roles, artifacts and activities are designed to work together as a saint. If you only partially implement them, you might end up reducing their benefits. Incomplete implementation of Scrum can cause a lot of issues. First, it can lead to a loss of clear roles and responsibilities. To implement Scrum completely, you should define the roles for the team and vein folders roles with specific individuals. You might also be tempted to skip some events or blame them to save time. But a lack of clear boundaries for sprint review, sprint retrospective, and sprint planning can lead to reducing transparency, inspection, and adaption. And these are all essential to experience the full benefits of Scrum. And finally, not providing the team with the Scrum coaching they need would also mean that you haven't fulfilled your role as Scrum Master. It's your job to fully explain the Scrum practices and provide coaching so your team understands the reasoning behind the practices and can embrace the benefits. The solution to all of these challenges is to implement Scrum completely. Being the Scrum Master is a critical role. You're the coach. So you should reinforce the connections between the teams activities and the Scrum and Agile values. Another issue, constant and rapid change of team members. There are few things you can do to trace instability on your team. First, have a quick onboarding process for new team members to help them get to know the rest of the team and understand the project. Second, use a pair programming style where a new team member teams up with a colleague and starts learning on the job. This also helps if people leave the team since a partner should be able to pick up with a lift off. And third, if team composition changes because maybe keep leaving, try having shorter sprints. This Way, team members can wrap up the last sprints worth of work before leaving. Coming up, we'll explore how Agile is evolving and keeping up with the times. Not that's an agile way to be. 27. Agile Evolution : Hey, welcome back. Since its creation in 2001, Agile's popularity has increased incredibly fast. One industry report showed that 85 percent of organizations have adopted a product centric model, which is associated with an agile approach. The state of Agile report describes how 50 percent of those companies, using the product centric model apply a hybrid of Methodologies. This means that being able to blink methods will be a super useful skill to have as you start your project management Korea, like we explained in an earlier video, businesses face a lot of volatility, uncertainty, complexity, and ambiguity. And they recognize that Agile and the frameworks that derive from it, or a way to overcome those challenges. In this video, we'll discuss how Agile has already started evolving and explore some emerging ideas about how it might continue to evolve in the future. The Agile Manifesto as a Monsanto philosophy, hasn't changed much. And almost 50 years, the frameworks it inspired the have continually changing and evolving to keep up with changing business environments. One emerging agile framework is cold DevOps, which combines software development and IT operations. Like all Agile frameworks, Dave opt aims to shorten the product life cycle and deliver software products continuously and with very high quantity. Devops emerged when software companies were faced with trying to figure out how to ensure software products would run reliably for billions of people across the world, 24 hours a day, seven days a week. If a business has the ability to launch products and features fossils and reliably to a global marketplace that's a significant competitive advantage. Devops is about growing and managing teams and organizations that can bold and evolved large-scale systems at a rapid pace. These systems need to be both secure and reliable, so they can beta deliver value to customers and organizations. If you decide to pursue a project manager role in the DevOps framework, you'll venture into the future of agile approaches and large-scale software systems that are literally changing the world. Pretty exciting, right? One of the next frontiers of Agile is called business agenda t, which involves incorporating agile principles into the wide SFIA of management so that the organization can thrive in high VUCA environments. Organizations that want to become agile and thus Saints often find themselves rethinking everything from financial planning processes, governance and reporting structures to hiring and HR practices and much more. They're looking for ways to make Agile values and frameworks work for larger and larger organizations. As an Agile project management and a larger organization, you might find yourself using frameworks like Scrum of Scrums and scaled Agile framework, also known as SAFe. It's also important to call out that Agile has reached a lot of industries beyond technology and software. Even the construction industry has started applying an agile approach to their projects. An article published by the Project Management Institute describes how construction projects use Agile to deal with delays and budget overruns by translating the Agile Manifesto art into construction industry terms like silos are minimized and close cooperation is encouraged. And finally, agile methodologies can also be applied to your own personal life. For example, planning kids activities can be managed using Kanban boards. 28. Conclusion : Hi again and congrats on reaching the end of this course. We covered a lot of material that I hope you'll find useful to your growth and effectiveness as a project manager. Throughout this course, we covered the history of Agile along with the core Agile values and principles. We learned all about Scrum and how Scrum teams work. Then in this last section, we explored how to introduce Agile practices to an organization and how to coach your team through the process. Finally, we checked out some of the exciting ways that Agile is evolving. Now, go out there and shine as an Agile Ambassador. I'm so excited for you.