Transcripts
1. Welcome to Scrum Power – Foundation in Scrum and Certification Preparation: Hey guys, Welcome And thanks for picking the scrum power training course Scrum is a simple method for managing and completing. Even the most complex project based on my experience has also been the number one reason why projects have delivered on time. Whether you're scrum master, turn that team member business stakeholders simply someone who wants to understand what makes frantic this is the place to stop. If you were preparing for scrum master certification or any other scrum certification, then this is definitely the close for you. Well, let's see Joo's passion Consulting Lunatic I created this class A certified from last with experience in international companies dating back to 1999. That includes experience leading projects for the BBC General Electric over Cool B Sky B races, among others. He's rose a full inflows leadership on the wealth of mobile Internet, TV and Web software. I've played the role of scrum master and in the early years of team lead and others, there were two things I didn't club. Firstly, I give you a concise, clear explanation, giving you a firm foundation in scram covering ALS, the rules, roles and event in script. Second, I critique and summarize the scrum guide Now the scrum guide is the rule book from scratch from scrum the old And if you're going for a scrum certification we're really gonna one break grounding in the scrum guy Because essentially, if you understand this from guide you understand squat. And that really is what sets this class apart from Paul the other training courses. So they haven't joined this class. Now let me prepare you with a foundation in scrum. See you on the inside.
2. Learning Objectives: The World Before Agile and Scrum:
3. The Waterfall Model: part one scrum In a nutshell. Chapter one. The World Before Agile and Scrum the Waterfall Model. Although the scrum framework can be used to deliver any type of project, it is most often used to manage software development projects. It is well known that many such projects use what is known as the waterfall model to organize and deliver. This process consists of upfront contiguous phases, the requirements or analysis phase, in which an analyst will usually gather the requirements for the product. The design phase and which the code and other artifacts are planned. Or modeled. The implementation phase where the designs are put into practice to build the product. The testing phase where testers make sure that the product meets the requirements to a high degree of quality and then finally the product is released to the public. After the product is released, there is own going support and maintenance in a live environment which can also be considered a phase, albeit a continuous one. As the diagram shows, this process flows neatly from one face to another, like a waterfall, and believe it or not, that's where the name waterfall came from. The waterfall model has been seen as an industry standard process for running software projects for decades and own first glance. It makes perfect sense, however, there's some fundamental flaws with this method. If the requirements change after the requirements phase and this has a knock on effect to the other faces, therefore the launch date becomes more difficult to hit. On top of that, the bulk of the defects and issues are not usually found until the test phase. This often delays launch, since more time is needed to fix bugs. How could you ever forecast exactly how many defects you will find? You? Cannot? Exactly. And so this situation leads toe over time, low morale and last minute scrambled towards the end of the project. It is possible that a piece of software sitting on your tablet owner computer has also been developed this way. Don't you feel sorry for the teams? Most, if not all, people who work on software projects would agree that requirements rarely, if ever, remained fixed or the long term. This means that either the process is interrupted toe add requirements, causing annoyance and delays to the team, or that the business agreed not to make any requirements changes. This is not an amiable solution, since change is often a reaction to market conditions and is often a good thing. Changing requirements can increase. The businesses return on investment, which usually has a good knock on effect for the company and employees. In practice, the former situation is usually the case, as businesses will usually aim to change requirements and worry about the problems. Later. However, neither situation is good, and in the end, everybody involved in the project wants the best possible outcome. It builds everyone self esteem to see quality work in the public domain as opposed to a software nightmare. On top of these factors, the waterfall method has to deal with other obstacles, as any development method would, such as unclear requirements, unrealistic deadlines and in accurate estimates, even the number and caliber of people working on the project can change. A common culprit is known as people pinching. Skilled team members can start off working on Project Day then, due to either new priorities or gentle pressure from other project managers. Keep people are approached by project be. This reduces the ability to deliver project a own time or to the scope agreed. In business, things can change rapidly, so change management is always key to success. After decades of projects being run using the waterfall model, it was clear that many companies were facing these issues and some changes were needed to manage change, keeping projects running smoothly in scrum. These and other issues are known as impediments or blockers. Collectively, these blockers can cause chaos on projects if allowed to and make the experience less than a pleasure, shall we say. Recognizing these blockers, Air Group of Thought leaders joined forces to create new energy, agile methods of working. One such method was scrum.
4. The Birth of Agile: the birth of agile, the term agile is one that is often used and misused in the software development industry. Given that agile is so closely related to scrum, let us nail down exactly what agile means and how it is relevant in context of scrum. By the end of the 19 nineties, there was a broad consensus of thought leaders who recognised the shortfalls of waterfall no pun intended software development. Many of them founded their own new intuitive methods of software development. Intuitive development is fundamentally different from waterfall, as opposed to upfront phases with lots of upfront requirements. Gathering iterative methods contained many faces of requirements design, implementation, testing and delivery within a number of weeks. This allows the business to release a few features early and make some return on investment . They also get to discover potential issues early and change requirements far more often. Working in generations also allows the project to react to people pinching through periodic replanning. Many of these intuitive methods were also lightweight since their founders believed in performing the simplest task possible to solve any given problem. Contrary to popular belief. Before the term Maj. R. Was coined, there was already many such methods of which scrum was one such as X p, D, S, D, M, Crystal and F D d in the year 2000. Seeing the range of narrative and lightweight methods, a group of industry thought leaders named the Object Mentor Group called a meeting at Snowbird Ski Resort in Utah. In short, each invitee agreed on a consensus of principles that were common to all of them. This consensus was named the Agile Manifesto and reads as follows manifesto for agile software development. We are uncovering better ways of developing software. We're doing it and helping others to do it. Through this work, we have come to value individuals and interactions over processes and tools. Working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan, that is, while there is value in the items on the right, we value the items on the left more. This manifesto was accompanied by set of principles agreed to by all the detail of each of these principles is beyond the scope of this class. But needless to say, through this agreement, the term agile was born in summary. Agile is not an alternative to scrum but an umbrella term for a set of methodologies and frameworks that share a manifesto and a set of principles. Scrum is one such framework.
5. Learning Objectives: Introduction to Scrum:
6. Scrum Theory and Scrum Skeleton: Chapter two, introducing scrum in Kinsch Rubber and Jeff Sutherland's two of the original founders of Scrum scrum guide. They describe Scrum as a framework for developing and sustaining complex products. Scrum consists of self organizing cross functional teams. Simply put, this means that the teams consist of a group of people who each have different areas of expertise but work together for the same outcome. A project manager does not control them since their expertise empowers them to make decisions collectively. The team's work in it orations which allows the business the flexibility to change the requirements but still gives the development team the certainty it needs to deliver a working piece of product. This is one key thing that makes scrum powerful Scrum takes its name from the analogy to rugby, where a team work together in a chaotic environment to keep control of the ball. This can be compared to a team working together in a chaotic environment to keep control of a project scrum theory. History repeats itself unless you do something about it. Scrum is based on empirical process control theory. The idea is very simple. So do not let the name were you. It consists of three principles. Transparency, inspection and adaptation. The idea is that the scrum team agreed to be transparent, honest in all that they do own the project. Being transparent means the functionality is not done until it meets the development teams . Definition of done transparency builds trust between the team members. Once a team have agreed on transparency, they agreed to consistently check up on progress inspection on make improvements based off what they have seen. Adaptation. These can be improvements in practice is sticking to values, communication or otherwise. This is powerful stuff in industry, the ability to consistently inspect and adapt. And that way they're improving time and time again before, during and after the release of a product. This is something that was not possible with the waterfall model development scrum skeleton . The scrum skeleton is a very quick and easy way to explain the process to someone, so I will use it to explain the process to you. On the left side of the skeleton, we see the product backlog, which is nothing more than a list of all the features and their acceptance criteria that the business desires for the product. A subset of that backlog, called the Sprint Backlog, is taken on by the team broken down into task and worked on in an iteration called a Sprint . A sprint is a period of time, less than 30 days in length, and in that time the team work on their task until they develop a working increment of the product. Remember those many faces of the waterfall that I described earlier? Well, this is where it all takes place. There is some requirements, gathering and specifications update before the sprint, then design, implementation and testing above the large sprint circle, you will see a smaller circle. This represents the fact that every day the team meet to inspect on progress and adapter plan for the day. In the daily scrum meeting at the end of the sprint, the potentially ship herbal increment of the product is delivered. The business can review the increment in a Sprint review on then release the new features to the world if they so wish. The team didn't discuss their progress during the Sprint and Sprint retrospective, so they can improve on things that need improvement or retain things that are going well. The cycle begins again and repeats until the product owner has nothing more to add to the product backlog. The scrum skeleton demonstrate the simplicity on the power of scrum as a mini factory turning out ship herbal features each sprint.
7. Coaching and Exam Prep: Intro to Scrum Theory: Hey guys, this is Paul from Passion Consulting and welcome to the first part of my summary on my scrum guide overview. So what I really want to do in this first part is tell you so that you know why it's important to understand and what's in the scrum guide in death. And I also want you to understand how that's going to help you when you go forward to doing exam or even if you're not doing exam, how it's really going to help you in your every day work using scrum. So the first thing I've highlighted here is in the scrum guide On is the fact that the Scrum guide, which was written by Jeff Sutherland and Ken Schwarber, is the definitive guide to scrum and the rules of the game. And you may ask, why is that important? Or the reason why that's important is because from my experience in the industry, one of the number one reasons where people go wrong with Scrum is because they don't really truly understand the foundation. What you've just seen Ted explain is an overview. What I'm going to be doing is going through the exact scrum rules excerpts from the scrum guide, which maybe things people are getting confused about in industry or in the exam, especially when you go towards a scrum certification. So the first thing I want to draw out here is that this is the rule book. Guys, this is what you need to read and understand if you want to be doing scrum correctly. If you deviate from this and don't get me wrong in life, there are always common sense reasons for doing things on. I always say If common sense tells you to do it or not to do it and it really does go against something in here and it really is common sense, then, you know, think about whether you really want to do that. But I never have. And I can't remember a situation where I have had to completely contravene one of thes rules. This is the first thing I want to say is that this is the definitive guide. So really understand this book, The Scrum Guide. The next thing I want to do is to draw your attention to something. It's the fact that when Ken and Jeff wrote this originally, there were some minor changes. Some would say Major, but I think they are subtle. But distinct. Changes on this was done in July off 2000 and 13. So this is the newest revision, I might add at the current time off me recording this off the book off the guide and it's just, you know, important to know there was a revision. So where in the video I mentioned the original scrum guide, and some of the wording is slightly different. That's because there was a revision, at least one revision before this. The next thing I want to draw your attention to is just to reiterate that the purpose of the scrum guide written here highlights that the scrum framework is for developing and sustaining complex products on the reason why I wanted to highlight that is because if you're doing something really simple, like building a Web page or something really, really quick, then it may be overkill for you to use Scrum because planning out with the team, building a webpage, having a retrospective on building a Web page, having a Sprint Review on building a Web page in some cases may well be overkill. If there were pages Simple. There are some situations in which you may want to do that. But the key thing I want to draw out here is that scrum is the most effective. If you're doing something complex, okay, that doesn't mean you can't use it for something simple, but it was built for doing something complex.
8. Coaching and Exam Prep: Empirical Process Control Theory: the next thing I am drawing your attention to here is the actual definition. Off scrum scrum is a framework so rather than it being a complete process, something that tells you every little detail about building the product scrum is actually a framework and it can be used to build these complex products and it has the structure. It has everything you need to bring your team together to make sure you're always inspecting on your progress and adapting, improving on delivering. That's the main thing delivering often. But what it isn't is the answer to every single problem. There are going to be things that you will discover while using scrum that you will need to plug the gaps. For example, when you work in a sprint. Using test driven development is something that people in the software world used often to ensure quality. Now scrum doesn't say you have to do that, but it is a well known method of making sure that you get a ship herbal increment or you get something off high quality that is tested regularly. So this is one example of how scrum is a framework as opposed to a complete process and here again it says that it's not a process for building product. Rather, it's a framework within which you can employ various processes and techniques, so I just want to draw your attention to that. Within the definition. In the scrum guide, the next part is the theory. So just drawing your attention again to the fact that using empirical process control theory on the key thing here that I draw your attention to that perhaps wasn't drawn out enough in Ted's overview was about learning from mistakes of the past on improving making new decisions, on making changes, adapting. So the whole point of using scrum is really powerful. Guys toe have proof from the past evidence from the past. Everything about scrum is about using evidence from the past to improve time and time again and some more here about the three pillars with enough detail on, incidentally, things I'm going through our really useful if you're going for a certification as well as in real life. I've drawn attention here to the fact that when a team does a recap, transparency is about being really open and honest as a team, admitting that when something is done that. It really, really is done that there is nothing else to do. And that's important because commonly on projects, there are situations where people just don't feel confident enough to say that something is not done. That leads to a problem down the road where people think a project is complete when actually it's not. There is more testing or there is more to build. That's why I've drawn attention here to the fact that the team should share a common definition of done so. Typically, that can be things like saying that a product is not done and complete at the end of a sprint, unless whatever you build is fully tested, all of the Tarsa complete. It matches the original designs things of that nature, those just a few things. And, of course, the product owner has an acceptance criteria, which is something I'll come to later next have drawn attention to inspection. So inspection was one thing I didn't draw out, or I didn't ask Ted to draw out in the video. Inspection shouldn't be so frequent that it gets in the way off the work. So in other words, if you were toe have a sprint and you were going to make that sprint daily. There probably wouldn't be enough time for a team to build up enough momentum in the direction of completing that piece of work. So it's getting in the way, getting in the way off actually doing the work. Where is what I found is a week often has been too short, you know, depending on the project, a week may be absolutely fine, but often, in my experience is it does need to be based on your experiences. After all, Ah, week has been too short a space of time to build up momentum, whereas two weeks has been perfect thistles. Just saying one of the things I want you to do is to realize that setting the sprint length is very important because that is the time at which you inspect at the end of a sprint.
9. Coaching and Exam Prep: The Importance of Scrum Events: at the end here. I've drawn your attention to a few things, so the things that I've drawn attention to here are the 44 more events within scrum. And this is important because in the exam that going toe want you to know they're going to want you to know what the events are within scrum or the time boxes, which was a previous name in the original scrum guide for events. So when people either add meetings on top of this, which is fine, you can add extra meetings and over this all they take away from this. They need to understand that you need to be doing these four you need to be having planning . You need to be having a daily scrum for coordination. You need to be having a Sprint review to make sure that stakeholders are having conversations with the team feeding back into the next bring. You need to be having a retrospective to make sure you improve. If you take away guys from any of these, you're not doing scrum and I say that again because this is often missed or people have three out of the four events. But if you take away from any of these. You are effectively not doing scrum. You can add to them as I always say. You can always do more. He shouldn't deliberately be doing more unless there is a common sense need. But things like product backlog grooming are recommended in scrum. However, these are the four formal events that need to take place. So I really want to draw out here that these formal events do need to be done. Okay, guys, that's the end of this section. Thank you very much for your time and I will speak to you in the next section.
10. Summary - Scrum Theory:
11. Learning Objectives: Scrum Team Roles:
12. Scrum Team Roles: scrum team rolls. Scrums simplifies projects down toe only three rows Remember, One of the benefits of this framework is keeping things simple. The three roles are this from Master the product Owner, the development Team. These three rows form the scrum team, the scrum master. The scrum master's purpose is to understand the scrum rules and practices, remove any impediments, are blockers to the team delivering and to help the team to understand how to self organize and work in a scrum manner. The scrum master facilitates for the scrum team wherever it makes sense to do so. The scrum master is your go to guy in terms of how this crumb frameworks and operate, and this applies to anyone and the organization. The scrum master usually understands how to aid the product owner in maximizing return on investment from the business, and he helps the team toe work together to be as productive as humanly possible and deliver a ship herbal increment of the product. The product owner, the product owner, is responsible for creating requirements on behalf of the business he prioritises based on business needs and is responsible for managing the product backlog, which is the list of all the features that the business requires in the finished product. The product owner is responsible for making decisions that maximize return on investment and for making priority calls. Our trade off To maximize the products value the development team the team are responsible for building a potentially ship herbal product increment in each sprint scrum is clear that there are only three roles in the scrum team. It does not go into the specifics of all of the different possible knowledge experts within the development team because the idea is that if push came to shove, team members would collaborate to perform tasks outside of their role to deliver the product. The development team are self organizing and collaborative as well as skilled and whatever is needed to develop the project. For example, in a typical technical project, you might have developers, graphic designers and user experience specialists working together in a sprint to create a product increments. One key difference between Scrum and many other frameworks is that the development team are explicitly experts in their field as opposed to controlled resource is they look to the scrum master for coaching guidance and the removal of impediments. They look to the product owner for clear requirements, prioritization and trade off calls Development team size. One important fact that is often overlooked is the optimum size of the team. Scrum teams are usually small because it helps them to be more cohesive and communicate efficiently. The optimum size is seven plus or minus two, in other words, between five and nine. This is not a number that just materialized over a chat or in the local bar. It is based on experience of thought leaders who have been doing team based work for years . From my experience, having tried and tested these team sizes, I can stand by them as numbers that create highly productive teams. However, as you know, there is no substitute for common sense in these cases.
13. Coaching and Exam Prep: The Scrum Team: so the 1st 1 is the scrum team itself. So what I have highlighted at the beginning here is just to make sure that you understand. But the scrum team actually consists of the product owner, the development team on the scrum master. So despite the fact that the development team is a team, it is within the scrum. Teen. The development team exists within the scrum team on. That is important because a lot of times in the video that I've put together on in the scrum guide teams are mentioned. But it is really important to remember the distinction between the scrum team on the development on. This is one of those things that comes up in the certification exam. Andi. It is also something that is often confused in industry, so it's something that I really want you to remember. The scrum team is a combination off the product owner, the development team and the scrum master and there are certain things that the scrum master needs to do to help facilitate the whole scrum teen. But then the development team are the people responsible for building the ship herbal increments off the product or for building a piece of the product. In other words, on they have their own needs. Obviously there are specific impediments that come up during the course of a project. The scrum master will work with the development team to solve them. So I'm just highlighting the two teams next, drawing attention to the fact that in this model there is a development team on their part of the scrum team. The fact is, there are explicitly three rolls. Andi, the thing that I want you to remember about this is that this is specifically designed by the creators of scrum toe optimize, flexibility, creativity and productivity. So, in other words, there is a reason why the scrum team has been designed this way. It has been designed without stakeholders designed without other members of the organization. But it has been designed with the key people necessary to deliver a working increment of a product and to collaborate really, in order to do that
14. Coaching and Exam Prep: The Increment: the next part is highlighting the fact that incremental deliveries off done product. In short, a potentially useful version off working product is always available. So what is meant here is that the very nature of SCRUM lends itself to the fact that a piece of a working product is delivered each sprint and all this is saying is the fact that piece of the product is done according to the team's definition. This is really key here, guys. It really, really is a key thing within scrum to make sure that your definition of done is sufficient , that you're satisfied that as a scrum team, the output of each sprint is going to be a useful increment off the working product. So really, really work on this really working your definition of done and you need to work on it to make sure that it incorporates essentially the rules that you are going to live by as a team. And these can be revised each sprint. But they really need to be worked on up front, and that's to make sure that whatever you come up with at the end of a sprint, as long as it adheres to your rules is considered the ship of increment. As I've said before, there are many ways to come up with a definition of done. It may be that a tester needs to ensure that the product is correctly tested and declared as a high quality product before it's done. The designers are happy that it meets all of their design standards might be another rule in a definition of done. Basically putting together this list of things that you will adhere to and what towards Andi can adapt as the list goes on is really key, so I wanted to draw your attention to that.
15. Coaching and Exam Prep: The Product Owner: the product owner. Now the product owner is responsible for maximizing the value off the product on the work off the development team. So this is one of those things that I know came up in one of the exams that I set. So I'm really drawing attention to the definition of things here. So you can see in the scrum guide the way it's defined and because a lot of the time, the questions that come up in the examine lightly to be based around what the product owner is responsible for, an isn't responsible for or accountable for. So just to get that straight, if you are responsible for something, it means that you are actually the Dua. You are actually the person that does the work, that somebody is going to come to you and say, Have you done it on? Why is that done incorrectly? Those are two things someone could ask you if you're responsible. If you're the duo, however, in terms of being accountable, it may be that someone else does the work, but that you are someone who either instructs them or has delegated that task. But you're still accountable as in someone could still come to you and ask you in that situation why something was not done. However, they'd be talking about something you've instructed someone else to do or ask someone else today. So there's something to look out for in terms of exams. Ah, product own is the sole person responsible for managing a product backlog. So they're there. Is that word responsible? Ah love times a minute in industry, I've seen situations where the product owner hasn't taken responsibility or doesn't realise that they are the only person responsible for managing the product backlog. So sometimes the scrum master has to get involved here just to coach them just so that they understand. So that's why I've highlighted that Ordering the items in the product backlog to best achieve goals and missions is one of the things that managing the backlog includes and therefore the product owner is responsible for on optimizing the value of the work done by the development team and how they perform is another one basically, on optimizing the value of the world. The development team performs is another one. So the product owners, consistently thinking about what the best things the development team could work on to get the most value out of thumb thing. This is something they consistently think about. I just thought, highlight these two because I know that they have come up in past exams and there are examples off the kind of things that come up in the examine e. I mean, potentially anything can come up in the exam, but I'm highlighting examples so that you can see the kind of questions that could be asked for the product owner to succeed, the entire organization must respect his or her decisions. I've highlighted this because a lot of times one of the key challenges and if your scrum master but ask you to pay really close attention to this one a lot of times. But difficulty we have is that in the real world, if I'm really honest in a lot of situations, the product owners, line manager or the seniors often do not respect the product owners decisions or they do respect the product owners decisions. But because of their status, they actually have a right to overrule the product owner. So it is just something to be aware off, which is that in the reality of life. Sometimes because of the nature of an organization, it is difficult on. I really sympathize with product owners, but it is difficult to fully carry out your role as a scrum, guide says. So this is something to be aware of in everyday life. And you know, there are various techniques for dealing with that. Some of them revolve around making your senior stakeholders aware of how you can actually add value for them, and you can take into account when speaking to the whole organization. You can still prioritize when necessary on bear in mind all of their opinions as opposed to one person's opinion. But you can also add value for them by doing your role and allowing them to do their own. So in some ways you take the weight off their shoulders. You can also use a lot of the information you get from the team to make the right decisions because you're a lot closer to them than the stakeholders
16. Coaching and Exam Prep: The Development Team: the development team, so a development team consists of professionals who do the work of delivering A potentially releasable increments. So what I'm drawing attention to here is really just the definition of what the development ing does and again, to the fact that, as you've seen me mentioned many times, done that done increments really, really is key. The fact that the increment is done is where the power really is in scrum, because at the end of a sprint, you have some certainty that you have accomplished something that is really off value to the users on the business. The fact that you've really delivered an increment off a product that is usable by them for scrum recognizes no titles for the development team members other than developer, regardless off the work being performed by the person. Andi, there are no exceptions to this rule. I thought I'd highlight that because first of all, I want to draw your attention toe what Ted was saying in the video, which is that there are three and only three roles in scrum on one of them is the development team. So it doesn't matter whether you've got designers, developers, testers, I mean, even though designers are called designers, they're helping to develop an increment of the product and hence they developed the product . So in that sense, they're part of the development team. Off highlighted this just to really drive home the fact that where one team as a scrum team , you know, as a scrum, master, product owner and development team, we are one team on within the development team. Everybody is one team so that designers, the testers, the developers, etcetera, whichever industry you in, it doesn't have to be software. But if people are working together to deliver a product, they need to be one team in scrum because part of the value and the power it brings is the delivery and the transparency between those team members. It's going to make that product stronger and ensure you a delivery you can be confident in and has fairly
17. Coaching and Exam Prep: The Scrum Master: the scrum master. So here I am drawing attention to some of the things that the scrum master is responsible for. The 1st 1 is just a definition which comes from the video scrum Master is responsible for ensuring scrum is understood. Andi enacted. I've seen a question on this in the open assessment. That's the scrum dot or open assessment which is a practice exam that is going to give you a lot of confidence. I've seen some questions around this some tricky little questions, really, in terms of meetings and things that the scrum master needs does or doesn't need to do or meetings that scrum master needs to attend. And so a lot of times in scrum you'll find that the scrum master's there to facilitate and to make sure that scrum is understood and enacted. But sometimes a scrum master does not need to be present with the team in order to make sure these things happen. He or she may just need to set up a meeting or he or she may need to be present a lot of times and I recommend you are prison in nearly every situation. But there are also some situations where you don't need to be prison. Scott musters do this by triggering the team to self organize. So that's why I'm going through this guide just to make sure that you really understand the rules, especially if you're a scrum master but not limited to on the scrum are esta is a servant leader. Servant leadership is a really important concept. The idea is that by serving the team, you also lead hitting. If you can think about the times you've had a manager who has really helped you to get to the next level or has really answered questions for you, I'm sure this will make a lot of sense. You know, by really helping a team to succeed, you are really helping them to get to the next level. But you're still a leader. It does not stop you being a leader. There's no weakness in the term here. As you can see, the leader part is there, on the servant part is also there, so they co exist happily together. The scrum master is leading through example through influence through making the whole team aware of the scrum framework and rules. There's a strong sense of leadership there, facilitating events as required or as needed. This is another thing that scrum master does, so I don't really need to go into too much detail about that. But the word facilitating or facilitator often comes up in scrum and that's something to be aware off, removing impediments. That is the key thing a scrum master does by removing any of the blockers, making sure the team come work effectively, leading and coaching the organization in scrum adoption. So why have highlighted that one? Because one thing that often gets missed, I think, is the fact that a scrum master actually has the authority to coach anyone in the organization and to lead. So those are two very important things within an organisation on the scrum. Master should really be respected for that and be respected enough and empowered enough to go into a new organization on be the authority on scrum Andi be able to say Listen, you need to give the team space or in some situations that I've had, I've had a really good relationship with seeing a stakeholders and had to say Listen, if you have any questions, direct them through this person sometimes that person would be may. Sometimes that person will be the product owner. Onda. We don't want to stop stakeholders collaborating with the team. But when questions become excessive, that's an example of where you sometimes need to coach people in the organization toe. Understand that after a certain point you are actually reducing the productivity off the team if you communicate with them too much. Okay, so that ends this section. I hope it has been helpful for you. Thanks for your time. I'll speak to you in the next section.
18. Summary - Scrum Team Roles:
19. Learning Objectives: Scrum Events:
20. Scrum Events (Timeboxes): time boxes, events and rules. You may not be familiar with the term time box a time boxes a period of time dedicated to a specific event in scrum and the new scrum guide. The term time box has been renamed Event, but as the term time box is prevalent at this time, I will continue to use it. Part of the scrum master's role is to carry out time management very strictly. This means beginning and ending meetings and sprints own time and helps the team to maximize their productive ity. Scrum has a number of time boxes and I will outline them briefly as there is far more detail on them and the remainder of this class. It is the scrum master's role to organize and facilitate all these events. Sprint A sprint is a period of time less than four weeks in length, during which the team bills a ship herbal increment of the product Sprint planning meeting . The team may plan the work that they will do in the upcoming sprint. The meeting last no more than four hours for a two week sprint. There are two halves to the meeting. The what and the how In the first half of the meeting, the product owner presents the list of features that he would like the team to deliver from the product backlog. He explains them and the team asks questions. Eventually they picked the features they believe they can commit to in the sprint and the second half, the meeting. The team break the stories into task and estimates them. And this way they designed their work and decide how they will build the product in committee. They may just and negotiate with stories they can commit to with the product owner, but finally they will make a commitment for the Sprint daily scrum. This is a daily meeting lasting no more than 15 minutes. One by one, each Development team member answers the following questions asked by the scrum Master, what did you do yesterday? What do you aim to do today? Do you have any impediments to delivery? The scrum master takes note of any impediments and aims to resolve them as quickly as possible. Anyone else at the daily scrum remained silent so that the meeting convenes productive. This possible for the team. Any issues can be discussed afterwards. They're sprint backlog and the sprint burned down should be visible to draw attention to the team's progress or any impediments. See definitions in this chapter. Sprint Review. This meeting is held at the end of each sprint and allows the team to demo the increment of the product to the product owner and stakeholders. The stakeholders asked the questions and make suggestions to the product owner. The product owner makes notes to a dance the backlog if necessary, based on suggestions or the output from the demo Sprint retrospective. This is a meeting held after the review and before the next Brent one by one. Each team member answers their questions what worked in this sprint and what could be improved in the next sprint? This is a chance for the team to inspect and adapt. It generates continuous improvement. Each of these events has a specific purpose and these are the only set of events that scrum defines In order to deliver a project release planning meeting. The release planning meeting is mentioned in the first revision of the scrum Guide. The purpose of this is for the product owner to present a subset of features from the backlog and the team to agree what looks feasible to deliver in terms of scope or a release date. This, however, is not a commitment. Usually, after 3 to 4 sprints, the team set a velocity pace at which they work. This can be used to calculate how many features are likely to be completed by the release date for date driven projects or when the scope is likely to be delivered for scope. Devin Projects See my section own release planning for more information.
21. Coaching and Exam Prep: About Scrum Events: scrum events. Hey guys, this is pulled from passion consulting scrum events. So let's cover this. Obviously, the scrum events are very important to make sure that we have certain time boxes, certain amounts of time dedicated to a particular task that is going to help the team to be more productive and to deliver that increment off the product. So the first thing I'm highlighting here is the definition. As usual, prescribed events are used in scrum to create regularity and to minimize the need for meetings not defined in scrum all events of time boxed events that such that every event has a maximum duration. So what this is saying is the fact that what we're trying to do is minimize the need for any other meetings if you deal with any team, particularly software development teams, but most teams, to be honest, most teams that are focused on delivering pieces off a product. If I'm really honest, the last thing most of them want to do is be in meetings. I'm probably the same may be true for you, but essentially knowing that the team are there for a specific purpose to deliver an increment, what we want to do is we want to remove anything that is taking them away from doing that. One thing that's going to take them away from doing that is being in a meeting. So what Scrum does and I think does really well is provide the minimum set of meetings necessary to make sure that the team have inspected. As in, they've looked at what progress they've made since the last spring, and they've adapted. They've planned. They thought about everything they need to do to build that increment of the product or to improve their increments and nothing else. So it provides just the events that you need to do that. So that's what this section here is talking about on a thought that was really key in industry and for the exam to draw your attention. Why we time box events? All events are time boxed events such that every event has a maximum duration. All that saying is that as you'll see in the Scrum guide, there is a maximum duration for every event on the fact that their time box is really very key. So unlike a lot of other methods, frameworks and processes scrum as a framework is really explicit about the amount of time you should spend planning. And that comes both because of the experience of the founders of Scrum, some of which were team leads and project managers, among other things. Partially because there should be a limit to doing things you shouldn't allow meetings or the amount of time you take to build a product to go on forever. Because as human beings there are limits to our attention spans on. There are limits to the amount of time you can spend before you become unproductive anyway , so that's very key.
22. Coaching and Exam Prep: Compulsory Events: the next one and this is something I've drawn attention to earlier. So I won't say again or I will say again but I won't draw too much attention to it. Is that failure to include any of these events results in reduced transparency on is a lost opportunity to inspect and adapt elsewhere. Actually says if you don't have these events, you're not. If you're not doing all of this, then you're not doing scrum. However, what this is saying is that it's really giving you the reason why you're not doing scrum if you don't do these events on, that is because you're reducing and that goes for us to say, greatly reducing the transparency and greatly reducing your chance to inspect and adapt by leaving out any one of thes. So if you're just having a stander, how are you going to plan things for the day? If you leave up planning how you're going to plan the next print of work, how are you going to keep the team coordinated from day to day without a daily stand up? These have really been meticulously thought about guys on every single one of these events , plays a valid role. So really, really think about that And take that on board. Whether you're doing the examine, whether you're in industry practicing scrum, the sprint, this one's excellent. The heart off scrum is a sprint time box of one month or less, during which but done usable and potentially releasable product increment is created. That's really interesting that Ken and Jeff have called this out as the heart of scrum and it makes a lot of sense because the whole point of what makes scrum on to be honest, agile methods in general but particularly scrum different is the emphasis on the iteration which within scram is called a sprint on. The reason it is the heart of scrum is because you've got a specific amount of time that you've agreed on as a scrum ting, after which you will be creating a usable piece off the product on That's powerful. As you've learned in the video. In previous methods such as waterfall that wasn't the way things were done, you'd wait till the very end of a project. The project was not split up into smaller pieces if he had a huge project or huge product, which would take months to build. You wouldn't get any value from that for months. A new sprint starts immediately after the conclusion of the previous sprint. So that's just something I picked up from one of the exam questions that I thought it would be good to jury attention to. A key thing here is that however you run your sprint whenever you have your meetings, a soon as you finish the sprint, you are now starting to use time from the next Brent. So if you're one of those people, as many people are that have your retrospective, you're planning your review and everything all in one day that they will actually begin the next sprint. And when you finish, you complete the increment off the product and you finish a designated day, such as two weeks later, the sprint ends. The next time when you go into planning in the next morning, you've begun the sprint already, so that's really key in terms of managing your time. And it's also really key in terms of the certification to understand when that finishes, I've definitely seen at least one question on that sprint length. Each sprint may be considered a project with no more than a one month horizon pretty much speaks for itself. Its length is limited to one calendar month. Again, I've seen questions around these, and you need to be careful thinking about the fact that how many days it is is not necessarily the focus. The focus is that it needs to be less than a calendar month. Whatever you decide, canceling a sprint, canceling a sprint, only the product owner has the authority to cancel a sprint. So that's just something I thought I draw your attention to because it's something in industry I think that, people may think, is the scrum master's role, while actually it's the product on Israel.
23. Coaching and Exam Prep: Sprint Planning: sprint planning. So what I've done here is I've highlighted the amount of time that these events can last four as a maximum. Now, obviously, you reduce those times based on the length of your sprint. So Sprint planning is a time boxed meeting to a maximum off eight hours for one month. Now, even though this doesn't take explicitly, I've found that for a two weeks, bring before our meeting usually works. That might sound like a large amount of time, and it is a large amount of time for a meeting. My advice would be to have brakes. The reason the meeting is that long is because they literally is that much to talk about. And this is something you may have found already or will find. They literally is that much to talk about when you are planning in terms off, reducing it down? I found that you can reduce it roughly toe half the time, and you can get it quicker. But I found that in the beginning stages, at least for to experience, it is four hours for one week sprint. It is about two hours. It may be a bit more than that are a bit less, but I thought I'd highlight that point because this is the official word from the scrum guide changes to Sprint planning rules. So here we have an example of something that has changed. This is talking about within Sprint planning the way that Sprint planning actually works in the video. You would have heard Ted referring to two hearts to the meeting. The what and the how well in the July revision. As I told you, there were some changes on one of those changes was that Ken and Jeff made the change from prescribing that there are actually two hearts to the meeting. That's to say that there are now two topics that need to be covered in that meeting, and that's just to give you some more flexibility and no tie you in their toe having to explicit harms in the meeting, I found that's really worked well for me, as we didn't always have exactly two halves to the meeting. But we did cover both of the topics, so the first topic is still the same. It's the what. So you're planning what needs to be done, and it focused the team around the specifics of what needs to be built. The second topic is the how how the world will get done. That's usually where the team would work out, how the work gets done by breaking the stories into tasks. So I just wanted toe draw your attention to those two changes. I've mentioned two hearts to the meeting because that's still usually how it's done. However, the key thing here from the scrum guide is that there are two topics in the meeting development team capacity. The input to this meeting is the product backlog. The latest product increment projected capacity off the development team during the sprint . So this is a technique are usually employees which is toe work out how much time the development team have. There are various methods for this. The method I employ is to go around the team of experts on without dividing the team, get all the experts toe, work out how much time they need, how much capacity they have and bear in mind all the meetings they have. Some of these meetings might be outside of the usual sprint events, but definitely include planning, Sprint Review and all of those sorts of things. They also anything include how much time they need for other things. Normal things like lunch time. That might sound really strange, but do factor that in factor Anything in that you do in your working day, guys, because if you don't, it will usually come back to bite you as something you haven't planned. After all, it is the reality of how we work. So once they've worked out how much time they take, whatever is left over is there capacity? And what that does is it builds buffer into the plan. So I've highlighted this on this is covered on my blogged on other places for which I'll leave you a link at the end of the course. But what this does is it build buffer into your plan so that if you work out, actually, even though you have five working days, one whole day is used for planning. I don't know, let's say a number of plucked out of the areas seven hours off that working week is used for meetings and other things that just come up. So you work out that you actually had less time than you thought you had, because in a working week of five days. You've actually got four days or if you're doing two weeks springs, which adds up to 10 working days. If you've taken a full day out of that for meetings and other things, you've actually got nine days. So that's something to take into account for planning. So that's just a important point, I thought. I draw from the point of view both of the certification and of everyday life for Sprint goal. The spring goal is an objective that will be met within the sprint through the implementation off the product backlog. So I just thought I'd draw attention to this because of spring goals, something that gets often overlooked.
24. Coaching and Exam Prep: The Daily Scrum: the daily scrum, so the daily scrum is a 15 minute time blocks event. Andi, that time box is so important because, as I've said, this is all about the team. Right thing is all about making the development team as productive as humanly possible on being in a meeting 15 minutes is a fairly small hit on the team. If we make sure that we coach the team as a scrum master to coach the team to understand the value of keeping things short and sweet on, they will understand. It's fairly difficult at times depending on the personalities you have in the team. But if we can coach them to do this, then it's something really valuable. So it's key to driving the productivity of the team. When they really get used to keeping it under 15 minutes, they will really think thank anyone that coaches them to do it. Daily scrum location The daily scrum is held at the same place each day. I've drawn attention to that because it's an example often exam question just to drive the importance of that. The key thing that came up in one of the exams was that it was a way to reduce complexity on them. That might seem pretty strange. Hearing the word complexity. I believe that was actually said in the exam. That might sound like a strange thing to say about a gathering. But what they're saying here is that by keeping the location of the daily scrum the same, it's one less thing for the team to think about. If you think about it, having to think about where your next meeting is is a good enough reason for someone to be late. Is it good enough reason for someone to miss the meeting because they were looking for the room? And given that this is a daily event, the last thing you want is key people from the team missing the event, so reducing the complexity just means it's less for the team to think about. It makes things simpler. Daily scrum Three questions here with the three questions on another change that was made in the July revision of the scrum guide. Is that rather than what did I do yesterday? It's also what did I do yesterday that actually helped the development team meet the Sprint Girl? What will I do to help the development team meets bring goal on Do I see impediments that prevent me or the development team from meeting Sprinkle? So this is just tying all of the communication, the daily scrum to be about the sprint goal As we know there are many things we do in our days. What we don't want to do is waste any time by talking about things that aren't going to be productive towards the sprint goal who attends the daily scrum? The next point is drawing attention to the fact that one of the scrum master's roles is to ensure the development team actually have the daily scrum meeting. But the team are actually responsible for being there and actually attending the meeting. So if the scrum master's away, they really need to take the reins of this and make sure it happens. Now. The scrum master plays a key part in making sure that this meeting takes place over. The reason I'm drawing attention to this is a I've seen this particular question in exams and B because it's really interesting that although this grandmaster has authority over the process, Onda coaches on the framework were really leaving it to the development team to make sure that they do the right thing here. They know the rules of the game, They know what's in it for them and they know how it's going to help them. So it's down to them really. If the scrum monster is a way to really take the reins of this and make sure it happens, the fact that the scrum master wasn't there on occasion should not be a reason for them not to have the meeting.
25. Coaching and Exam Prep: The Sprint Review and Sprint Retrospective: the sprinter. Phew. So what I've highlighted here is the fact that during the Sprint review, the scum team and stakeholders collaborate about what was done in the Sprint, based on that on any changes to the product backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. So what this is really saying here is the Sprint views a chance not only for the stakeholders to see what was built in the previous Sprint but actually feed in tow. What goes into the next bring because the stakeholders have a stake in the outcome of the project, and therefore they've gathered with the team on the product owner as a perfect opportunity for them to feed in so what they need or to raise any questions or queries they have. And this is something to watch out for any exam as well is the role of particularly the stakeholders on how they collaborate with teams. Sprint Review length. This is a four hour time box meeting for one month sprint. So again, similar things were planning meetings. Every one of these events should have a specific amount of time in that amount, of time. The maximum amount of time is very important. It's very important that you reduce the time in proportion to the sprint as well. It says. Here again, for shorter sprints, the event is usually shorter. Sprint retrospective. So again I won't go into what the retrospective is, but just highlighting the maximum time limit. So that's it, guys, for this section, as usual, I hope you got some value from that. Remember, I'm really drawing your attention to things that are examples of the type of questions that you will get in the open assessment and thus in the final certification exams. The reason I'm drawing things out in these presentations is partially because off what I've just said and partially because these are also, incidentally, the kind of things that people will get misconstrued in industry, such as the length of meetings and really understanding this and being on top of your game on these point is going to set you apart. Trust me from my experience, they're going to set you apart from others in industry because, believe it or not, not everybody has read the scrum guide, and not everybody knows the important off these really strong points and these underlying things. So I really hope you've got value from this. Andi, I will see you in the next section.
26. Summary - Scrum Events:
27. Learning Objectives: Scrum Artifacts:
28. Scrum Artifacts: artifacts product back drug. The product backlog is a list of all the features that the product owner would like to see in the finished product. This list constantly evolves and changes over time. The product owner maintains the backlog and works with the business stakeholders to form requirements. He also works with the team to get suggestions, technical input and estimates. Since the product backlog contains features that applied to the lifetime of the whole product as opposed to the release, a number of features that the product owner would like to release is referred to as a release backlog. The release Burned Down is a common method of monitoring progress towards the release of a product. It shows the number of story points and sprints remaining till launch. Simply put, they're burned down. Makes it easy to see if a project his own track. Since the line our chart tracks progress and if all his own track the line will be own are very close to its diagonal guideline. Sprint, My clog. The Sprint backlog is the set of items that the development team will work on in a sprint to deliver an increment of functionality. It is a selection from the product backlog initially picked by the product owner but finally committed to buy the development team. It consists of features, task and their estimates. As with the release burned down, the sprint burned down helps the scrum team monitor progress within a sprint. The vertical axis usually shows hours or number of tasks and is related to the number of tasks remaining in the Sprint Bank log. The horizontal axis shows the number of days in the Sprint Ah line tracks the team's progress, the number of hours of a task done each day and ideally, this should be a constant number, resulting in zero hours of tasks left at the end of a spread. As with the release burned down the line tracking progress should as closely as possible mirror the guiding line ship herbal product increments. This is a piece of functionality delivered by the team at the end of each spread. It should be potentially ship herbal and meet the teams definition of done agreed at the start of the project. Each of these artifacts either has the purpose of helping us to build a product. How big us to track the products in the terms of progress or is the actual outcome of the team's work. We will explore them in more detail in the chapters to follow.
29. Coaching and Exam Prep: Artifacts Introduction: Hey guys, pull from passion consulting here. So before I get into scrum artifacts, just a small issue. Those of you've read my books will notice that I spell artifact but effect with an E instead of an I and I spoke organization with an s instead of has said so. It's just to let you guys know I can spell I'm just from the UK So if any of you have read my books on a wondering why spot artefacts with an E on organization with s, there's a good reason I can spell a source Bell checked. But it's all done in the UK spellcheck for trip. Please try and find it in your heart to forgive me. Okay, Artifacts for transparency All right. Scrum artefacts have highlighted here the definition they represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by scrum are specifically designed to maximize transparency off key information so that everybody has the same understanding off the artifact. So there's quite a lot in that, but essentially what they are drawing out in this version of the scrum Kydd is the fact that Ted spoke about this in the video. The key thing here is being transparent, being honest to everyone about the state of the project, the product backlog, the sprint backlog and the final increment. Our role particular objects that serve a purpose of being transparent about these is crucial because not only do they serve a purpose, but they also give a strong indicator for the team about where they are in terms of progress and in scrum. There's a real focus on this transparency because one of the failings off projects in the past or with old methods is that there were often people who may or may not have had the confidence to convey information may or may not have had the right tools to convey certain types of information. But with scrum, what we've got are three objects or artifacts that can be used to convey information about the status off the project on a zoo, long as everybody's turned transparent about the progress they've made. What this information saying is that the project on DNA stakeholders always very well informed about the status in the progress of the project, for example, using the sprint burn down or using the release burned down. These are two ways of conveying that information on being very transparent about it. But as soon as that transparency goes well, that's when that issue start to arise. That's when you really don't know how near you are to the deadline. So that's why it's very important to make sure that with all of these artifacts that were about to go through that transparency is key. And being honest about when something's been done or being honest about when something hasn't been done is very important. What's in the bat logs actually conveys a lot of information and could be used to convey the information regularly on this needs to take place for us to be doing scrum the right way.
30. Coaching and Exam Prep: Product Backlog Refinement: product backlog refinement. Okay, so the product backlog, what I've highlighted for the product backlog is that the product owner is responsible for the backlog, including content, availability and order. I think we've been through some things about the product but backlog earlier, so I'm not going to linger too long on that point. But product backlog refinement is the act of adding detailed estimates and order to the atoms in the product backlog. I think I've mentioned the product backlog grooming also earlier. Now, in this version of the Scrum Guide, the latest version the 2013 July version, Ken and Jeff have gone out of their way to get rid of the term grooming and used the word refinement. So bear that in mind. So you actually refining the backlog along the way? And this is something that takes place during the daily life of a product owner and with the team, because the product owner works closely with the team they worked together to refine the backlog, and it can be not only on a hot basis where the product owner needs to speak to the team. What I found is often the best way to ensure it gets done is to organize a meeting. This is where I say that Scrum tries really hard to give you all the meetings or the minimum set of meetings. You need to run effectively and what's pretty well. But I mean, feel free to add meetings if you really, really need to just be very cautious now. I found a few well placed key meetings, and this is just my opinion works really well for product backlog grooming because everybody can manage their time and they know that they're in the same place in the same time, and then they can get some of this refinement done. So. Product backlog refinement is essentially definitely something that can be accomplished outside of a meeting. But I find that in a meeting once a sprint where the team get together and look through the backlog, they can have the right amount of time to sit with the product owner, discuss each story, refine it and actually understand what's coming up in the back. Look conducted, usually once a sprint for an hour on the product owner goes through the top priority items in the backlog that a team hasn't seen yet which, essentially, what are known as stories or user stories features from a user's perspective. They focus on how they can benefit the user on one by one, the product owner discusses with the team what the story is. The acceptance criteria for when it's done on this acceptance criteria describes how, from his perspective or from the perspective of the user, the story will be done. The team will basically discuss that with a product owner. If it's a big feature that couldn't be done in a sprint, especially, and can often break it down into a smaller story that can be done in the upcoming sprint, they can also get early estimates, which is going to be helpful for the business to know how long it's going to take or get an idea of how long it's going to take for that particular feature. This gives everybody an understanding of what's coming up so that when you finally get to sprint planning, you are armed with all of the information. That way, it definitely doesn't come as a surprise in the Sprint planning meeting, getting items ready for planning. The key thing about refining the backlog is making sure that the items are ready for planning. As I've said before, the reason why this is key is you make sure that before you even going to planning the features that come in what's called ready now I'm repeating that again because ready has quite specific meaning within scrum. Ready means that those stories are broken down to a size that the team could actually complete in a sprint and get completely done in one sprint by their definition off done. So that's why I've highlighted that, because I think there's a lot in that and it's something that should it come up in. One of the certification exams is really key that you understand that concept in depth. You can get more information in my blog's, which I'll give you a link to at the end of this course.
31. Coaching and Exam Prep: Prioritising the Backlog: prioritizing the bat look ordered high ordered back look. Items are usually clearer and more detail than lower ordered ones. So, as we said in the training video, you would usually organize a backlog so that the higher order stuff the highest priority stuff, is the stuff that the team is about to work on. And what happens is through the process of refinement and discussing with the team what they are about to work on your actually making those items clearer. Sometimes you're breaking down a larger item into two, maybe three or four different features because they are so complex or four different stories because they're too complex a zin toe take it honors one single story. Sometimes you're just clarifying the acceptance criteria or clarifying the title of a story or clarifying some detail about it so that when they come to it the team, the development in days they will understand what what it is they're doing in more detail. But by the nature of for Feinman, we're actually making these higher priority items really clear. So I've highlighted that because again that's something that could come up in the exam and something that we encounter often in the workplace using scrum. So just to be clear that term ready is a key term. It's been brought in in the scrum Guide items product that look. Items which can be referred to a stories or features are said to be ready when they are clear enough to be done in a sprint. And they're said to be done when the team has actually built those items as features at the end of the sprint and have delivered them to a satisfactory condition that it meets their definition of done now alongside the product backlog. What usually have is some means of monitoring progress towards your goal after on attention to a release burned down, but it really doesn't have to be a release burned down in particular. What highlighted here says that the product owner compares the amount of work with the work remaining at previous sprint reviews to assess progress towards completing projected work by the desire time for the goal. This'd information is transparent to all stakeholders. So where in the video I drew attention to a release burned down, the release burned down is a means for the product owner to do this on. What's really key is the fact that the product owner is called out here, a somebody that does this and is really showing that the product owners should be taking an interest in measuring how near the scrum team are to getting to that goal on also that the product under should take an interest in knowing how near the business are to being happy to release. So the burned down is one way of doing that. I explicitly called out the release burned down, but this is just to say that it's not the only way to do it, Azzam was. It's being done. As long as you have a mechanism to do that, then you're on the right track and this is just reiterating exactly what I've said, which is that various project practices upon trending have been used to forecast progress like burn downs, burn ups or cumulated flows. So burn up is, for example, something that shows how much progress you're making instead of burned down. So your you start off with an amount of work and you steadily burn down that work by getting it done and crossing it off the list, whereas a burn up just shows that information the other way around accumulates and shows how much work you've done.
32. Coaching and Exam Prep: The Sprint Backlog: sprint back look. So the definition off the sprint backlog is the set of product backlog items selected for the Sprint, plus a plan for delivering a product increment and realizing a sprint gold. So in the video, you've just seen that the Sprint. But look is the set of all the items or features or stories, plus the tasks. The tarts are actually an example of a plan for delivering the product increment. You may have the task written on pieces of card, or maybe in a tool you'd usually right out each and every story in the backlog. Andi at the right time, sprint planning the team would break them into tasks and the tax on the items get into a formal plan, which is the Sprint backlog. But this is just reiterating that as you've seen in the video frozen sprint backlog, only the development team can change its sprint backlog during a sprint. So what that means is, once the sprint start, the development team are now in full swing, and any change to that sprint backlog could affect their progress. But once they focused on a specific set of items, it's only right that they have the say so about whether those items change. Otherwise. That makes the plan void Now. It's not that the plan should know update. It is very well known that in the spring things can change. But this is just making it clear that it's up to the development team to actually negotiate really with the product owner and work together as a team with the product. China. Actually, I should say that up to the product owner to negotiate with the development team and vice versa if there is a change that needs to be made to the items, usually the user stories. But the team have a final say in whether those items can change in a sprint. And one thing to make very clear here is that the team can noise changed tasks. This is related. You toe what usually are written as users stories, the actual requirement if the requirements change in a sprint that can actually disrupt the team. But the task can often change without any negotiation. That's something that the development team can just do monitoring sprint progress. So we really don't need to go into this in much detail. This is where I described earlier that the Sprint burned down is used as a means off monitoring the sprint progress. But the key thing here is that the sprint burned down is not the only way to do that. It's just a very well known from my experience way to do that. The increment. So I've been talking about the increment off a ship herbal product in this new scrum guide , the July 2013 version. It's called specifically just increment and it's actually a releasable product as opposed to anything else. And at the end of the sprint, the new increment must be done, which means it must be in a usual condition, meets the scrum teams definition of done on the acceptance criteria. So this is really to highlight again this concept of done that you keep seeing popping up. And I think that just shows how important it is to understand that for the examined for daily life,
33. Summary - Scrum Artifacts:
34. Coaching and Exam Prep: Artifact Transparency: artifact transparency. So this is something specifically brought in in the July 2013 scrum guide. Ken and Jeff brought this in because what they mean by artifact transparency is that the product better log, the Sprint bet log and the increment are, as we said before, really key. In terms of conveying information about the project, the product backlog is going to show the priority of work to be done, and it's going to also show how much work is left to do. It also is going to show what is in the remaining list of things to Dio that the product owner is expecting the team to be working on imminently. The sprint backlog is going to show what the plan is for the current sprint and the increment is going to show what has been done. So in terms off thes three items, they convey a lot of information about the project and transparency about the project being really open and about being really honest and making sure that what is conveyed by each of these is open to all of the stakeholders on the whole scrum team thing is really important to get all of these things right and to get the transparency on this to everyone. So this whole section off artifact transparency has been added into the July 2013 scrum guide to really draw attention to the fact that on I've highlighted part of it that says, Scrum Master, Development Team and other involved parties need to understand that the artifacts are completely transparent. But for the scrum master's role, as far as this artifact transparency section, it's to really make sure that these artifacts are transparent. That's the scrum master's role on the scrum Master must actually help everyone toe apply any practices in the absence of that. So, for example, with the teams I worked with, the burned down is always visible. The burned down is visible on the floor that we work on so that everyone can see where we are. Everyone can see in terms of the sprint that we're on track or diversity that we are not untracked, so that sends a really strong, clear message. If we not untracked that something needs to be done and no one can get around that in a scum team. Nobody wants to get around that because we really want to know the status of the project. If we are on track, it sends a boost to the team that we're doing really well. And if we know on track, sends a message to the team that we need to bring ourselves back on track. Incidentally, just to backtrack slightly, the two things that I really should have drawn attention to things that are tricky in the exam are that the development team contract their progress during the Sprint monitoring the Sprint Progress. Using a sprint burned down, especially at the daily scrum meeting, improves the likelihood for achieving a Sprinkle. The development team should be watching the Sprint progress themselves in keeping track of that, making sure that they are on track on that the day scrum This should be visible along with Sprint backlog. Another point is that the product owner compares the amount of work with that remaining, So the product owner here is more on the hook for monitoring the progress off the release. The team should be focused on their sprint and the product owner is seeing the bigger picture here, so I just wanted to make that clear
35. Coaching and Exam Prep: Definition of Done: definition of done. So this is something that I've really spoken about throughout the whole of my summary. It's how important the definition of done is. This is just saying that although it very significantly per scrum, team members must have a shared understanding. So as long as everyone in the team knows what done means, it doesn't matter if it varies from one team to another. Because every team is different. Every team has got a different purpose, so they may have completely different skill sets. You know, software teams will have different outcomes to marketing teams on within software teams. People focused on Web projects will have different outcomes to people focused on back and software development projects. So this is just to say that although it may vary from team to team, they should at least be shared a shared understanding off The definition of done is key to everything in scrum. If the definition off done for an increment is part off the conventions, standards or guidelines off the development organization, all scrum teams must follow it as a minimum. If done for an increment is not a convention off the development organization, the development team off the scrum teen must define a definition of done appropriate for the product. If there are multiple scrum teams working on the system or product release, the development teams on all of the scrum teams must mutually define the definition of done . I've called this out here and highlighted it because in industry it can sometimes be forgotten that your definition off done can often be a department or standard. So, for example, there was a time in some of the companies that I have worked in where it was a standard, that we needed to have automation test automation. It was nothing to do. It's crumb. It was one of the things we had to do. So therefore, by default, that was part of our definition of done on an industry. This is often forgotten that you don't always have to think too hard around what constitutes done because often a it is part of the set up of your organization. But if it's not a convention of your organization than the team actually have to decide it , and I would recommend whether there are conventions or not working with your team to actually decide what done constitutes anyway, because in every situation I've been in, there are things that are not part of the conventions of the organization that will actually achieve quality on the team. No, a lot, too. The team know things that why the organizations don't know. So frankly, not using that knowledge, I think, would be a huge loss.
36. Coaching and Exam Prep: Definition of Done for Multiple Teams: if I liked it quite a lot here because I've noticed that these came up a lot in the open assessment around this particular part of the scrum guide. In particular, I want to draw your attention to the part around multiple scrum teams. Let me read it out again. If there are multiple scum teams working on the system or product release, the development teams on all of the scum teams must mutually define the definition of done . So what this is saying is that if you have multiple teams working on a specific product, for example, there are times when teams collaborate on set themselves up, such as There is a back in team I say so because you can often combine back in teams into the same team. But sometimes teams choose to divide the team into two smaller teams, having a back end on the front end team, and they work together to build the exact same product. That's the kind of example we're talking about, so it makes sense at this time that they mutually agree on the definition of done, because otherwise what you end up with is disjointed teams, but this part here is something to really bury. Mind if you've got multiple teams working together on what is essentially the same product release, especially on the same system? Okay, guys. So that ends my section on Artifact. I hope you've got something out of that. Especially in terms of being able to draw on a few key things that I find often trip people up in the exam and even in real life. Okay, take care. And I will speak to you in the final section.
37. Summary - Artifacts Transparency:
38. Learning Objectives: Scaling Scrum:
39. Learning Objectives: Final Words:
40. Final Words and Summary: Congratulations. Final words on next steps, but before, I'd only further. I just want to say Congratulations for making your way through the course. There are a lot of different courses you could have gone for him picked. But you pick this one and I want to say congratulations for also taking action. I know you will get great value out of this. You've had a chance to really go through the detail not only what the events are, what the rules are within scrum, but more importantly, the scrum guide. That's the rule book, guys, that's really the rule book on what Scrum is. So I just wanted to say Congratulations on making your way along the way through the course and taking the time to have a look at the things I've highlighted within the scrum guide along with my coaching. What have you learned? So that being said, let's have a quick recap of what you've learned. You've learned all about the water four model how it was one of the original methods for software development projects on how it was a less flexible method used in the past. You've learned about the birth of agile and how agile embraces change on also how that rather than it being an alternative to scrum, it's actually an umbrella term for a number of methods and frameworks and processes that all share a manifesto on a set of principles which is really key because that's something that gets confused. Often you've learned also about the fact that Agile is something more flexible than waterfall because most agile methods are based around its orations on are based around the ability to deliver frequently. And that is really where Scrum comes in because you have learned what scrum is, how the empirical process theory is really at the center of scrum. We've learned about the importance off alterations which we call sprints on about all of the rules of scrum that helped to make it such a great framework for delivering frequently on improving time and time again, we've learned the scrum theory and the foundation, as I've said before, which is empirical process control theory, which is really crucial when it comes to inspecting and adapting. In order for that to work, there must be transparency toe only norther three legs to that transparency, inspection and adaptation you've learned about the scrum team rolls. You've learned that the scrum team consists of the product time of the scrum master and the development ing on that. Although the development team is a team in itself, it is still part of the Scranton. You've learned about the events Sprint planning retrospective, the daily scrum meeting Sprint Review, which are the only events defined in scrum. However, you also know that there is a sprint. Of course you've learned that there was released planning in the earlier versions off the scrum guide, which is not officially part of the scum Guide now, however, is still very valued to use and it's used to plan ahead for releases. You've learned about scrum artifacts, the product backlog, sprint backlog and the increment of the releasable or formally called ship herbal product, which are the part effects. And you've learned also that there are burned downs related to the project in the form of this sprint burned down in the release burned down. There's the Sprint burned down, which we can use to show progress during the course of a sprint, and the development team can also pay close attention to this toe, help keep them on track during a sprint. We've also learned about the release burned down, which anyone can use, but particularly the product owner can use to monitor progress towards a release. On top of that, you've learned about artifact transparency on the fact that this was brought into the July 2013 scrum died to really draw attention to the fact that in order to get the most value out of the artifacts on for them to be valuable for delivering projects, we really need those artifacts to be transparent to everyone in the scrum team and the organization, especially the stakeholders. You've learned a lot on top of all that. You've got my critiques, my summaries which delve into the scrum guide on answer. Some frequently asked questions on some common gouaches, especially if you're going for the scrum certification. All in all, you've got a complete overview of scrum along with some pieces from the scrum guide that are really going to help you guys when you go towards an open assessment at scrum door or or in fact, any scrum certification
41. How to get Scrum Certified?: what's the next day? So once again, I want to congratulate you. But the question you may ask is, what is the next debt? You've got all the information and there are a number of different things you can do. So are lots of what the next step is. There are a number of different steps, but the first thing to do is to use what you've learned the theories based on practice. And if you really want to master Scrum, you're not going to get it from a book or from the course is gonna help you to excel and become a master at your gain by reading a book and doing a course. But best way to become a master of your game is to start using it. When you get this kind of experience, you can really grasped the kind of problems that you're going to encounter in everyday life and have to overcome them. So that's the first thing. The second thing is to take the open assessment. If you are taking this course because you want to go forward for a certification, go forward and take the open assessment. So most people are doing this because you either truly want toe, understand scrum or you want to go forward and take the certification. As I've said on our recommend, before you sit a certification to go over to scrum the Orc and sit the open assessment, the link will also be provided in this course. What the open assessment will do is give you confidence and prepare you for a scrum Dork certification, particularly the scrum master certification the PSM one. Now there are two bodies you can go to to get an official scrum certification. That's the scram Alliance on Scrum dork. I always recommend these two bodies because the founders of Scrum Ken and Jeff on their partners are the people that build those companies. So you can guarantee that if you passed certification with those bodies, you really, truly no scrum as the founders intended it. So if you go over to scramble order and you sit the open assessment, you can brush up on your skills time and time again, using this course until you're happy that you've passed. Most of the recommendations from students that have done it has said if you can get 100% in that exam three times. Then you're vory well set up for the PSM one scrum Master certification from Scrum the Orc . My personal feeling is based on everything that you've learned. You can happily move forward for that course based on the recommendations off everybody who's taken this course.
42. Open Assessment and Certification:
Paul Ashun, Deliver Projects On Time with Agile Scrum
4.334
9 Std. 44 Min.
