Scrum Master Certification

Transcription

1

2 Scrum Master Certification Professional Scrum

3 Master Training & PSM 1 Exam Preparation

4 Introduction Thank you and congratulations on taking this class, Professional Scrum Master Training & PSM 1 Exam Preparation. In this class, you will be given a multitude of information and proven tips to help you to pass the scrum.org Professional Scrum Master (PSM 1) Exam. I know you will get value from this class as it s information has been

5 successfully used by many students in order to pass the PSM 1 Exam. I will walk you step by step through agile scrum so that you have an excellent foundation. Following the explanation of each concept, I give you tips for passing the PSM 1 exam and even for using scrum in your team or business. Along the way, Igive you plenty of examples and finally I give you the links you can use to sit the practice open assessment. This is the official practice exam from scrum.org. In this class, you will learn: Concise overview of Scrum - The exact events, roles, rules and artifacts used to deliver a project using scrum along with

6 the history of scrum. This includes lectures on the fundamentals of Sprint Planning, The Daily Scrum, Sprint Review, Sprint Retrospective, Scrum Artifacts and more. The facts based on the Scrum Guide - The correct terminology and use of Scrum is essential to mastering it. The Scrum Guide is the rule book on Scrum and many do not use it or know it. Scrum Certification Coaching - A summary of frequently asked questions (FAQs) and frequently misunderstood points around Scrum that have

7 been in past Open Assessment exams. Scrum Certification Preparation - I tell you how to prepare for Scrum Certification and how to sit it online saving you hundreds if not thousands of dollars. So let s get started and let me help you to pass the scrum.org Professional Scrum Master (PSM 1) Exam.

8 Table of Contents Scrum Master Certification Professional Scrum Master Training & PSM 1 Exam Preparation Introduction Section 1: The World Before Agile & Scrum The Waterfall Model The Birth of Agile Section 2: Introducing Scrum Scrum Theory

9 Scrum Skeleton Coaching and Exam Prep Section 3: Scrum Team Roles The Scrum Master The Product Owner The Development Team Development Team Size Coaching and Exam Prep Section 4: Scrum Events Sprint Planning Meeting Daily Scrum Sprint Review Sprint Retrospective Coaching and Exam Prep Section 5: Scrum Artifacts

10 Product Backlog Monitoring the Progress of a Release The Release Burn down Sprint Backlog Monitoring the Progress of a Sprint - Sprint Burn down Increment Coaching and Exam Prep Section 6: Scaling Scrum How do we scale scrum? The Challenge - Scaling Scrum What is Scrum of Scrums? Section 7: Preparing for Certification CONGRATULATIONS

11 WHAT YOU HAVE LEARNED How to Get PSM 1 Certified at Scrum.org WHAT S THE NEXT STEP Conclusion Check Out My Other Books

12 Section 1: The World Before Agile & Scrum

13 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 in 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

14 to a high degree of quality and then finally the product is released to the public. After the product is released there is on-going support and maintenance in a live environment which can also be considered a phase (albeit a continuous one).

15 As the diagram shows, this process flows neatly from one phase to another like a waterfall (and believe it or not,

16 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 on first glance it makes perfect sense. However, there are some fundamental flaws with this method. If the requirements change after the requirements phase, then this has a knock on effect to the other phases. 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.

17 How could you ever forecast exactly how many defects you will find? You cannot exactly, and so this situation usually leads to overtime, low moral and a last-minute scramble towards the end of the project. It is possible that a piece of software sitting on your tablet, phone or 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) remain fixed for the long-term. This means that either the process is interrupted to add requirements (causing annoyance and delays to the team), or that the business agree not to make any requirements changes. This is not an amiable solution,

18 since change is often a reaction to market conditions and is often a good thing. Changing requirements can increase the business 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 s self-esteem to see quality work in the public domain as opposed to a software nightmare.

19 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 inaccurate estimates. Even the number and calibre 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 A, then due to either new priorities or gentle pressure from other project managers, key people are poached by Project B. This reduces the ability to deliver Project A on time or to the scope agreed. In business, things can change rapidly, so change management is always key to success.

20 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 and keep 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, a group of thought leaders joined forces to create new, iterative, agile methods of working. One such method was scrum.

21 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 the context of scrum. By the end of the 1990s there was a broad consensus of thought leaders who recognized the short falls of waterfall (no pun intended) software development. Many of them founded their own new iterative methods of software development. Iterative development is fundamentally different from waterfall. As opposed to upfront phases with lots

22 of upfront requirements gathering, iterative methods contain mini phases 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 iterations also allows the project to react to people pinching through periodic re-planning. Many of these iterative 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 agile was coined there were

23 already many such methods (of which scrum was one) such as XP, DSDM, crystal and FDD. In the year 2000, seeing the range of iterative 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

24 developing software by doing it and helping others 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; and 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 a set of principles, agreed to by all.

25 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment

26 and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential.

27 The best architectures, requirements, and designs emerge from selforganizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The detail of each of these principles is beyond the scope of this book, 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.

28 Scrum is one such framework.

29 Section 2: Introducing Scrum In Ken Schwaber 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

30 project manager does not control them, since their expertise empowers them to make decisions collectively. The teams work in iterations, which allows the business the flexibility to change their requirements but still gives the development team the certainty it needs to deliver a working piece of the 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 a ball. This can be compared to a team working together in a chaotic environment to keep control of a project.

31 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 worry you. It consists of three principles: transparency, inspection and adaptation. The idea is that the scrum team, agree to be transparent (honest) in all that they do on the project. Being transparent means that functionality is not done until it meets the development team s definition of done. Transparency builds trust between the team members. Once the team have agreed on transparency, they agree to

32 consistently check up on progress (inspection) and make improvements based on what they have seen (adaptation). These can be improvements in practices, sticking to values, communication or otherwise. This is powerful stuff in industry, the ability to consistently inspect and adapt. In that way they are 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 of development.

33 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 tasks, and worked on in an iteration called a sprint. A sprint is a period of time less than thirty days in length and in that time, the team work on their tasks

34 until they develop a working increment of the product. Remember those mini phases of the waterfall I described earlier? Well this is where it all takes place. There is some requirements gathering and specification 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 adapt their plan for the day in a daily scrum meeting. At the end of a sprint, the potentially shippable increment of the product is delivered. The business can review the increment in a sprint review and then release the new feature(s) to the world if

35 they so wish. The team then discuss (transparently) their progress during the sprint in a sprint retrospective (inspect) so they can improve (adapt) on things that need improvement or retain things that are going well. The cycle then begins again and repeats until the product owner has nothing more to add to the product backlog. The scrum skeleton demonstrates the simplicity and power of scrum as a mini factory, churning out shippable features each sprint.

36 Coaching and Exam Prep Introduction In this first section, I want to tell you what i s in the Scrum Guide and why it i s important to understand it. It will help you when you go forward to do an exam or even if you re not doing an exam, it will help you in your everyday work using scrum. This may seem strange to you, but the answer to passing the PSM 1 exam is in the in depth

37 understanding of the scrum guide. What is the DEFINITIVE GUIDE to scrum? The Scrum Guide which was written by Jeff Sutherland and Ken Schwaber, is the definitive guide to scrum and the rules of the game. You may ask whythat is important. The reason why that is important is, because from my experience in the industry, one of the main reasons why people go wrong with scrum, is because they don t really understand the foundation. What you have just read is an overview, however what I a m going to be doing in

38 these Coaching and Exam Prep sections is go through examples where people are getting confused about scrum in the industry or confused in the exam. These points of confusion really need to be cleared up if you want to be doing scrum correctly. If you deviate from the scrum rules then you are going against Scrum. Download THE SCRUM GUIDE right now to help you to PASS the exam.

39

40 It is the foundation of the PSM 1 (and CSM for that matter). ***DONT MISS OUT ON PASSING THE EXAM. DOWNLOAD IT NOW***

41 What is Scrum Used For? The next thing I want to draw your attention to is to just re-iterate that the Scrum Guide, highlights that the scrum framework is for developing and sustaining complex products and the reason I wanted to highlight that is, because if you re doing something that is 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 a team building a web page, having a retrospective on building your web page and having daily meetings about building the web page, may be overkill if the web

42 page is 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 doing something simple, but it was built for doing something complex. Is Scrum a Process, Methodology or Framework? The next thing I am drawing your

43 attention to here is the actual definition of scrum. Scrum is a framework, so rather than it being a complete process, something that tells you every little detail about building a 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 and delivering. The main thing is delivering often. But what it is not is the answer to every single problem. There are going to be things that you will discover while using scrum to plug the gaps, for example

44 when you work in a sprint, using testdriven development is something people use in the software world. Scrum doesn t say you have to do that, but it s a well-known method of making sure that you get a shippable increment, or you get something of high quality that is tested regularly. So this is one example of how scrum is a framework as opposed to a complete process. So the scrum guide is not a process for building product but rather a framework, within which you can employ various processes and techniques. So I just want to draw your attention to that.

45 What Is The Theory Behind Scrum (Empirical Process Control Theory)? Scrum is based on Empirical Process Control Theory, and the key thing here is that it is all about learning from the mistakes of the past and improving, making new decisions, making changes and adapting. So, the whole point of using scrum is that it is really powerful to have proof and evidence from the past. Everything about scrum is about using the evidence from the past to improve time and time again. This knowledge is useful if you re going for

46 certification as well as in real life, because it underpins the understanding of all the events and rules. Transparency is about being open and honest as a team, admitting that when something s done, that really means that it is complete and there is nothing else left to do. This is important, because commonly, on projects, there are situations where people do not feel confident enough to say, that something is not complete. That leads to a problem down the road where, people think that a project is complete when it actually is not. There may be more testing or something more to build. That i s why I ha ve drawn attention here to the fact

47 that the team should share a common definition of done. Typically that can consist of saying that a piece of a product is not complete unless whatever you build is fully tested, all of the tasks are complete, it matches the original designs that the designers have put forward etc. Those are just a few of the things a team may decide. On top of this, of course the product owner has acceptance criteria that needs to be met for each feature in the product backlog. In terms of inspection and adaptation. The team consistently inspect and adapt at the end of each sprint. Inspection

48 should n o t be so frequent that it gets in the way of the work. In other words, if you were to have a sprint and you were going to make that sprint one day in length, there probably would n o t be enough time for a team to build up enough momentum in the direction of completing that piece of work, so, it would be getting in the way of actually doing the work. In my experience a week often has been too short for a sprint whereas two weeks has been perfect. So based on the Empirical Process Control Theory, setting the sprint length is very important, because it decides how often you can inspect and adapt a product.

49 What are scrum EVENTS and ARE they NECESSARY? In the exam they re going to want you to know the events that make up scrum. These are The Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. When people, either add meetings on top of these, (which is fine, you can extra meetings on top of this) or they take away from these, they need to understand that, you need to be doing the scrum events. You need to be planning, you need to be having a

50 daily scrum for coordination, you need to be having a sprint review to make sure the stakeholders are having conversations with the team and feeding back into the next sprint, you need to be having a retrospective to make sure you improve. If you take away from any of these, you a re not doing scrum. This is often missed because people opt to do some of the events. However, if you take away from any of these, you are effectively not doing scrum. You can add to them and if there is a common sense need, however you should aim to minimize the meetings and events to just these.

51 Section 3: Scrum Team Roles Scrum simplifies projects down to only three roles. Remember? One of the benefits of this framework is keeping things simple. The three roles are: - The scrum master - The product owner - The development team These three roles form the scrum team.

52 The Scrum Master The scrum master s purpose is to understand the scrum rules and practices, remove any impediments or blockers to the team delivering and to help the team to understand how to selforganize 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 the scrum framework should operate, and this applies to anyone in 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 to

53 work together to be as productive as humanly possible and deliver a shippable increment of the product.

54 The Product Owner The product owner is responsible for creating requirements on behalf of the business. He prioritizes 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 or tradeoffs to maximize the product s value.

55 The Development Team The team are responsible for building a potentially shippable 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 selforganizing and collaborative, as well as skilled in whatever is needed to deliver

56 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 increment. One key difference between scrum and many other frameworks is that the development team are explicitly experts in their field as opposed to controlled resources. 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.

57 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 between three and nine. This is not a number that just materialized over a chat 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

58 substitute for common sense in these cases.

59 Coaching and Exam Prep What s the difference between the scrum team and the development team? The Scrum Team actually consists of the Product Owner, Development Team and the Scrum Master. So despite the fact that the Development Team is a team, it exists within the Scrum Team. That is important, because the teams may be mentioned many times in the exam. It is important to remember the distinction between the Scrum Team and the Development Team. This also comes up

60 in industry. There are certain things that the Scrum Master needs to do to help facilitate the whole Scrum Team. However, the Development Team (the people responsible for building the releasable increment of product) have their own needs, and obviously have specific impediments that come up during the course of a project. The Scrum Master will work with them to solve these issues, too. There are 3 roles and this is specifically designed to optimize flexibility, creativity and productivity. So in other

61 words, there is a reason why the team has been designed this way. It has been designed without stakeholders and 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 in order to do that. What is the importance of a done, releasable INCREMENT? The incremental deliveries of done product ensure that a potentially useful version of working product is always

62 available. This means that the very nature of Scrum lends itself to the fact that a piece of working product is delivered each Sprint. The Development Team decides the definition of Done. It should be sufficient that they are satisfied that the output of each Sprint is going to be a useful version of working product. So really work on this definition of Done to make sure it incorporates essentially the rules that you are going to live by as a team. It should make sure that whatever you come up with at the end of the Sprint, is potentially releasable. As mentioned earlier, the fact that the product increment is tested might be one

63 of the things in the definition of done, as well as the fact that it meets all of the design standards. Basically the development team put together this list of things that they will adhere to and then work on adapting that list as time goes on. What is the PRODUCT OWNER responsible for? The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. This is one of the things that came up in one of the exams that I sat. Some of the

64 questions are around what a Product Owner is responsible or accountable for. If you are responsible for something, it means that you are actually the person who does the work. However, in terms of being accountable, it may be that someone else does the work, but you either instruct them or delegate the task. So in the latter scenario you are accountable and someone else would have the right to come to you and ask you why the task was not done. This is something to look out for in terms of exams. A Product Owner is the sole person

65 responsible for managing a product backlog. In industry, I have seen situations where the product owner has either not taken responsibility, or does not realize that they are the person responsible for managing the product backlog. Sometimes the Scrum Master needs to get involved here, just to coach the Product Owner to understand. 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 that too. Optimizing the value of the work the Development Team performs is another one. So the Product

66 Owner is consistently thinking about what the best things are that the Development Team could work on to get the most value out of them. For the Product Owner to succeed, the entire organization must respect his or her decisions. One of the key challenges in industry is that the Product Owner s line manager or seniors, often do not respect the Product Owner s decisions. Sometimes they do respect the Product Owner s decisions, but because of their status they actually have a right to overrule the Product Owner. Because of the nature of an organization,

67 the situation is difficult and I really sympathize with the Product Owners out there. There are various techniques for dealing with this, some of them revolve around making your senior stakeholders aware of how you can actually add value for them, and how you can take into account the whole organization, still prioritizing when necessary and still bearing in mind their opinion. You can also add more value for them by doing your role, if they allowing you to. You can let them know that you can use a lot of the information from the Development Team and stakeholders to make the right decisions on their behalf, thus saving them time.

68 What is THE DEVELOPMENT TEAM responsible for? The Development Team consists of professionals who do the work of delivering a potentially releasable increment. The fact that the increment is Done, is where the power is within Scrum. At the end of a Sprint, you have some certainty that you have accomplished something that is really of value to the users and the business. Scrum recognizes no titles for Development Team members other than developer, regardless of the work being

69 performed by the person and they are no exceptions to this rule. I want to draw your attention to what I said earlier, which is that there are 3 roles in Scrum, and one of them is the Development Team, so it does n o t matter whether you ha ve designers or developers as they are still part of the same team. Designers (even though they are called designers) are helping to develop an increment of the product, and hence are part of the development of the product. As a Scrum Master, Product Owner and Development Team, each member should consider themselves part of one team. Also within the Development Team, everybody should consider themselves

70 part of one team. Whichever industry you are in, (it doesn t have to be software), 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, the delivery and the transparency between those team members is going to make that product stronger and ensure you a delivery you can be confident in. What is THE SCRUM MASTER responsible for? In Scrum, the Scrum Master is there to facilitate, and to make sure that Scrum is

71 understood and enacted. However, sometimes the 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. I recommend that Scrum Masters are present in many situations, but there are also some situations where they do not need to be present. Scrum Masters often perform their role by triggering the team to self-organize. The Scrum Master is a servant leader, present to serve the Scrum Team. Servant-leadership is a very important concept. The idea is that by serving the team, you lead the team. If you can think about the times you had a manager who

72 has really helped you to get to the next level or answered importantquestions for you, then I a m sure this will make a lot of sense. By really helping a team to succeed, you are, helping them get to the next level, but you are still a leader. It does not stop you being a leader and there is no weakness in this term. As you can see the leader part is there, as well as the servant part. The Scrum Master is leading through example, through influence and through making a whole scrum team aware of the Scrum framework rules. There is a strong sense of leadership there. Facilitating events as required or needed, is also

73 something a Scrum Master does. Removing impediments is the key thing a Scrum Master does. This is done by removing any of the blockers to delivery, making sure the team can work effectively, leading and coaching the organization in Scrum adoption. One thing that often gets missed 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 organization, and a Scrum Master should really be respected for that. He should be respected and empowered enough to

74 go into an organization and be the authority on Scrum. He should be able to say listen, you need to give the team space. I ha ve had situations where I have had a really good relationship with senior stakeholders, and had to say, listen if you have questions, direct them through this person or that person. Sometimes it would be directed through me and sometimes it would be directed through the Product Owner. We do n o t want to stop stakeholders collaborating with the team. However, when questions become excessive, that is an example of where you need to coach people in the organization to understand that after a certain point, you are actually reducing the productivity of the team. This is an

75 example of a Scrum Master removing impediments.

76 Section 4: Scrum Events You may not be familiar with the term time-box. A time-box is a period of time dedicated to a specific event in scrum. In 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 on time and helps the team to

77 maximize their productivity. Scrum has a number of time boxes and I will outline them briefly, as there is far more detail on them in the remainder of this book. It is the scrum master s role to organize and facilitate all of these events: Sprint A sprint is a period of time less than four weeks in length, during which the team build a shippable increment of the product.

78 Sprint Planning Meeting The team plan the work that they will do in the upcoming sprint. The meeting lasts no more than eight hours for a one month sprint. There are two topics to the meeting, the what and the how. In the first topic 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 ask questions. Eventually they pick the features they believe they can commit to in the sprint. In the second topic of the meeting, the team break the stories into tasks and estimate them. In this way, they design their work and

79 decide how they will build the product increment. They may adjust and negotiate which stories they can commit to with the product owner but finally they will make a commitment for the sprint.

80 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 remains silent so that the meeting can be as productive as possible for the team. Any issues can be discussed afterwards. The sprint backlog and sprint burn-down should be visible to draw attention to the

81 team's progress or any impediments (see definitions in this chapter).

82 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 ask questions and make suggestions to the product owner. The product owner makes notes to adapt the backlog if necessary based on suggestions or the output from the demo.

83 Sprint Retrospective This is a meeting held after the review and before the next sprint. One by one, each team member answers the 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.

84 Coaching and Exam Prep WHY Do WE HAVE SCRUM Events? The Scrum events are very important to ensure that we have certain amounts of time dedicated to particular tasks that will help the team to be more productive and to deliver the increment of the product. Prescribed events are used in Scrum to create regularity and to minimize the

85 need for meetings not defined in Scrum. All events are time boxed events, such that every event has a maximum duration. So what we are trying to do is minimize the need for any other meetings. If you deal with any team, particularly software development teams, but in in fact any team that is focused on delivering pieces of a product, you will find that the last thing most of them want to do is be in meetings. The same may be true for you. Essentially, the team are there for a specific purpose, delivering an increment of the product. What we want to do is remove anything that is taking them away from doing that. One

86 thing that is going to take them away from doing that is being in a meeting. So what Scrum does (and I think really does really well) is provide the minimum set of meetings necessary to make sure they have inspected, adapted and planned. This is what makes Scrum an efficient framework for product development. WHY do WE TIME-BOX EVENTS? All events are time boxed events such that every event has a maximum duration. This is called time boxing. So unlike a lot of other methods, frameworks and processes, Scrum is very explicit about the amount of time

87 you should spend on each event. For the exam it is important to remember these times: The Sprint - one month or less Sprint Planning - 8 hours or less for a one month sprint (reduce as needed for shorter sprints) Daily Scrum - 15 minutes or less Sprint Review - 4 hours or less for a one month sprint (reduce as needed for shorter sprints) Sprint Retrospective - 3 hours or less for a one month sprint (reduce as needed for shorter sprints) The time-boxes come both because of the experience of the founders of Scrum (some of which were team leads and

88 project managers) and because there should always be a limit to the things we do. We should not allow meetings or the amount of time we take to build products go on forever. As human beings, there are limits to our attention spans and there are limits to the amount of time we can spend before we become unproductive. ARE EVENTS COMPULSORY? Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt. Elsewhere in the scrum guide it actually says that if you don not have the events

89 then you are not doing Scrum. If you do not carry out each and every event, you are greatly reducing transparency and greatly reducing your opportunities to inspect and adapt. So if you are not having a daily scrum, how are you going to plan things for the day and stay coordinated? How are you going to plan the next sprint of work, if you are not having a sprint planning meeting? The key thing is that these events have really been meticulously thought about. And every single one of them plays a vital role in the framework. Why do we need a SPRINT?

90 The heart of Scrum is a sprint. A time box of one month or less during which a done usable and potentially releasable product increment is created. The whole point of what makes Scrum, and many agile methods powerful is the emphasis on the iteration (which within Scrum is called a sprint). The reason it is the heart of Scrum, is because you have got a specific amount of time that you have agreed after which, you will be creating a usable piece of the product. That is powerful because in previous methods such as waterfall you has to wait till the very end of a project to get anything useable. The project was not split up into smaller pieces, so if you had a huge product which would take months to

91 build, you would not get any value from it for months. Note also that a new sprint starts immediately after the conclusion of the previous sprint. However you run your sprint, whenever you have your meetings, as soon as you finish the sprint, you are now starting to use time from the next sprint. So if you have your retrospective, you re planning, your review and everything all in one day then that day is the begging of the new sprint. When you finish and you complete the increment of the product and you finish on a designated day such as two weeks later, the sprint ends, the next time when you go into planning on

92 the next morning, you have begun the sprint already. This is key in terms of managing your time and is also key in terms of the certification exam to understand when a sprint finishes. What is the SPRINT LENGTH? Each sprint may be considered a project with no more than a one month horizon. A sprint s length is limited to one calendar month. The number of days in the sprint is not the focus here. The focus is that how ever many days you pick, the length needs to be less than a calendar month whatever you decide. This is important to remember for the exam.

93 Who cancels a sprint? Only the product owner has the authority to cancel a sprint. I think that many people in industry believe that it is the Scrum Master s role to cancel a sprint, while it is actually the product owner s role. Why does SPRINT PLANNING last so long? Sprint planning is time-boxed to a maximum of eight hours for a one month and I found that for two weeks, a four hour meeting works pretty well as the upper limit. That may sound like a large amount of time, and it is. My advice

94 would be to have breaks. The meeting is that long because there is literally that much to talk about. This is something you may have found already if you have been in such a meeting. There is literally that much to talk about when you are planning but in terms of reducing it down, I have found that you can reduce the meeting by roughly half the time by optimizing your discussion and methods. I found that in the beginning stages, at least for a two week sprint, it did take four hours. For a one week sprint, it was about two hours. It may be a bit more or less than that for you. However, work on your methods and all will improve.

95 Why do we have Two SPRINT PLANNING topics? The first topic, is the what. Here you are planning what needs to be done and this focuses the team around the specifics of the requirement. It prevents the team from thinking about the technology or tasks too early. If they skip ahead too early, they may not fully understand what needs to be accomplished. The second topic involves how the work will get done. The how is where the team would break down stories into technical tasks. This allows them to focus on on the technical challenges and

96 build a good solution. How do DEVELOPMENT teams Decide on their CAPACITY? This is a technique I usually employ which is to work out how much time the development team has. There are various methods for this. The method I employ is to go around the team of experts and without dividing the team, get all the experts to work out how much capacity they have, bearing in mind all the meetings they usually have and some of them may be meetings outside of the sprint. Including the scrum events is

97 important too. Also it is important to include the time they need for other things like lunch. This might sound like a strange thing but factor that in, factor in anything 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 for. So once they've worked out how much time they take. Whatever is left over is your capacity. What that does is it builds buffer into the plan. So that if you work out actually, even though you have gotten 10 working days in a sprint, one whole day is used for planning. Let us say that roughly 7 hours of that working week is used for meetings and other things that just come up. You may work out, you

98 actually have less time than you thought you had because you've got nine days really after you take into account planning. If you take off the seven hours, you've actually got eight days in the sprint to do any work. So that's just an important point I thought I'd draw from the point of view from both the certification and everyday life. What is the Sprint Goal? The sprint goal is an objective that will be met within the sprint through the implementation of the sprint backlog (the requirements split into tasks). In other words, the sprint goal is not actually decided till after the team has agreed on

99 an achievable set of features to build during the sprint. The Product Owner will have his own target s in mind, but only after planning and agreement can the team call it the sprint goal. Why is the daily scrum limited to 15 minutes? The daily Scrum is a fifteen minute timeboxed event, and this time-box is very important because it helps to keep the development team as productive as possible. Being in a meeting for fifteen minutes is a fairly small hit on the team. If we make sure that we coach the team to understand the value of keeping things short and sweet we will have a more

100 productive, efficient team. This may be difficult at times depending on the personalities you have in the team. However it is really key to master timeboxing in order to drive forward the productivity of the team. When they really get used to keeping it under fifteen minutes, they will really thank anyone that coaches them to do it. Why is the DAILY SCRUM LOCATION fixed? TheDaily Scrum is held at the same place each day. I have drawn attention to that because it is an example of an exam question. Just to drive the importance of

101 that, the key thing that came up in one of the exams was that it is way to reduce complexity. That might sound like a strange thing to say about a gathering, but what we are saying here is that by keeping the location of the Daily Scrum the same, it becomes one less thing for the team to think about. Having to think about where the next meeting is, is a good enough reason for somebody to be late. It is a good enough reason for someone to miss the meeting because they were looking for the room. Given that this is a daily event, the last thing you want is for key people from the team to miss the meeting. So reducing the complexity just means that it is less for the development team to think about if

102 we keep the location the same. What is the importance of the THREE QUESTIONS at DAILY SCRUM? At the Daily Scrum, rather than what did I do yesterday, it is what did I do yesterday that helped the development team meet the sprint goal. The other questions are What will I do today to help the development team meet the sprint goal and Do I see any impediments that prevent me or the development team of meeting the sprint goal. So this is just tying all of the communication in the Daily Scrum to be about the sprint goal.

103 As we know there are many things we do in our days. What we do not want to do is waste any time talking about things that aren't going to be productive towards the sprint goal. Does the Scrum Master Need to attend DAILY SCRUM? The short answer is - No. The Scrum Master's roles is to ensure the development team actually have the meeting. However the team are actually responsible for taking the reins of this and making sure it happens. While the Scrum Master plays a key part in making

104 sure that this meeting takes place, he does not need to be present. However, the reason I am drawing attention to this, is, A) I have seen it in exams, and B) It is really interesting that although the scrum master has authority over coaching in the framework, we are really leaving it to the development team to make sure that they do the right thing. They know the rules of the game, they know what is in it for them and they know how it is going to help them. It is down to them really, if the Scrum Master is away for example, to really take the reins of this and make sure it happens. The fact that the Scrum Master was not there, on occasion, should not be a reason not to have the meeting.

105 What is the role of stakeholders at a Sprint Review? During the sprint review, the Scrum team and stakeholders actually collaborate about what was done in the sprint. Based on that and any changes to the product proposed, they collaborate on the next things that can be done to optimize value. The sprint review is a chance, not only for the stakeholders to see what was built in the previous sprint, but to actually feed in to what goes into the next sprint. The stakeholders are exactly what their name suggests. They have a stake in the outcome of the project and therefore,

106 when they are gathered with the team and the product owner is the perfect opportunity for them to feed in to what they need or to raise any questions or queries that they have. This is something to watch out for in the exam as well as in real life. Remember the role of the stakeholders and how they collaborate with teams, particularly in the sprint review.

107 Section 5: Scrum Artifacts

108 Product Backlog 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 a product backlog contains features that apply 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.

109

110 Monitoring the Progress of a Release The Release Burn down The release burn 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, the burn-down makes it easy to see if a project is on track, since a line (or chart) tracks progress and if all

111 is on track the line will be on or very close to it s diagonal guide line.

112 Sprint Backlog 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 by the development team. It consists of features, tasks and their estimates.

113 Monitoring the Progress of a Sprint - Sprint Burn down As with the release burn down, the sprint burn 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 Backlog. The horizontal axis shows the number of days in the sprint. A line track s the team s progress (number of hours of tasks done each day) and ideally this should be a constant number

114 resulting in zero hours of tasks left at the end of a sprint. As with the release burndown, the line tracking progress should as closely as possible mirror the guiding line.

115 Increment This is a piece of functionality delivered by the team at the end of each sprint. It should be releasable and meet the team s 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, helping us to track the products in terms of progress or is the actual outcome of the team's work. We will explore them in more detail on the chapters to follow.

116 Coaching and Exam Prep What is ARTIFACT TRANSPARENCY? Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact. For all of the artifacts, the key thing is being transparent, being honest to everyone about the state of the project. The product backlog, the sprint backlog

117 and the increment are all particular objects that serve a purpose. Not only do they serve a purpose, they also give a strong indicator for the team about where they are in terms of progress. The product backlog is going to show the priority and it s going to show how much of the desired feature set is left to do. The sprint backlog is going to show what the plan is for the current sprint. The increment is going to show what has been done in the previous sprint that the business can release. These items convey a lot of information about the project and transparency about

118 them is really important to ensure that all stakeholders know where the project stands. The Scrum master must actually help everyone to apply any practices in the absence of transparency. For example, with the teams I work with, the burn down is visible, on the floor that we work on so that everybody can see that in terms of the sprint we are either on track or we are not on track. That sends a really strong message if we are not on track that something needs to be done. Nobody can get around that and in Scrum nobody wants to get around that because the team really want to know that so they can improve. If we are on track then it

119 sends a boost to the team and a really good boost to everyone else around that things are going well. In scrum, one of the most important principles is concerned with being really transparent about how you are getting on, because one of the failings of projects in the past is that people did not have the confidence to convey important information about progress or delays. Sometimes they did not have the right tools to convey the information. With scrum, what we have are three objects (artifacts) that can be used to convey information about the project. As long as everybody is transparent about what that information is saying, then the

120 stakeholders are always well informed and everybody knows where they stand. As soon as transparency goes, issues start to arise and that is when you really do not know how near you are to the deadline. So that is why it is very important to make sure that with all of these artifacts, transparency is applied at all times. This means being honest about when work has not been completed, being honest about what is left in the backlog and conveying that information regularly. This will ensure that we are running our scrum projects the right way. What is PRODUCT

121 BACKLOG REFINEMENT? Product backlog refinement is the act of adding detailed estimates and order to items in the product backlog. This is something that takes place during the daily life of a product owner and team. They work together regularly to refine the backlog, and this can also be done on an ad-hoc basis, when the product owner needs to speak to the team. What I found works well is to actually organize a product backlog refinement meeting. I have found that few wellplaced meetings really works to get the job done, because this helps everybody to manage their time. They will know

122 that they will meet in the same place, at the same time to get the refinement done. It does not have to be done in this meeting alone, but I personally conduct it as often as once a sprint in a meeting of an hour s length. The product owner goes through the top priority items in the backlog that the team has not seen yet. These items are in the form of user stories (descriptions of features that will benefit the user). One by one, the product owner discusses with the team the story description and the acceptance criteria (the tests that need to pass before the story is done). The team will discuss them with the product owner and break them down if they are too big to be done in a sprint. They then give

123 estimates, which help the team and business to forecast how long the stories will take. The meeting also gives the team an understanding of what is coming up, so that when they finally get to sprint planning, they are armed with all of the information on what they are building. It does not come as a surprise to them. What does it mean if an item is READY FOR PLANNING? The key thing about refining the backlog, is making sure that the items are ready for planning. This is a very key thing - making sure that before you even go into planning, the features that come in are

124 ready. Ready means that they re broken down to a size that the team could complete and get completely done by their definition within one sprint. So that s why I ve highlighted that, because I think, there s a lot in it and it s something that, should it come up in one of the certification exams is really key that you understand in-depth. You can get more information in my blog which I will be giving the link to, at the end, at the end of this course. How do we get the ITEMS READY? Higher ordered backlog items are

125 usually clearer and more detailed than lower ordered ones. You would usually organize a backlog, so that the highest priority items are the items that the team will work on first. Through the process of refining and discussing the items with the team you are actually making the items clearer. Sometimes you are breaking down a larger item into two, three or maybe four different features, because they are too complex as a single one. Sometimes you are just clarifying the acceptance criteria or clarifying the title of the story, so that when they come to it, they will understand what they are doing. By the nature of refinement, you are actually

126 making these higher priority items clear. How Do we Monitor the Progress of a release? We must have some means, of monitoring progress towards our goal. The Scrum Guide says that at any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all

127 stakeholders. I drew attention to a release burn-down because the release burn-down is a means for the product owner to do what the scrum guide says. What is really key is the fact that the product owner is called out here, as somebody that does this and it is really showing that the product owner should be taking interest in measuring how near the scrum team are to getting to that goal of a releasable increment. The burn-down is one way of doing measuring progress. I explicitly called out the release burn-down, but this is not

128 the only way to do it. As long as it is being done and you have a mechanism to measure progress, then you are on the right track. A burn-up is another tool for measuring progress. It shows how much work is done instead of how much is left to do. How might we create a sprint backlog in the real world? The definition of 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 goal. The sprint backlog is usually

129 created as the set of all the user stories plus the tasks needed to complete them. The tasks are actually an example of a plan for delivering the product increment, usually you would have the user stories and tasks in paper (card) form or in a digital tool. The team would break an item (usually a user story) into tasks, and the tasks plus the stories would form a formal plan. What is a negotiable FROZEN SPRINT BACKLOG? Only the development team can change its sprint backlog during a sprint. So

130 what that means is, once the sprint starts, the development team are now in full swing, and any change to the sprint backlog could affect their progress. Therefore, once they have decided on a specific set of items, it is only right that they have the final say so about, whether those items change, otherwise it makes the plan void. It is very well known that, in a sprint, things can change, but it is up to the development team to actually negotiate with the product owner and work together as a team if the product owner wants to make any changes to the stories. The development team obviously can change their tasks as they see fit at any

131 time to accomplish the releasable increment. How Do we Monitor the Progress of a sprint? The sprint burn-down, is a means of monitoring sprint progress however it is not the only way to do that, it is just a very well-known way of monitoring sprint progress. The development team are the ones who should be primarily watching the sprint progress themselves and keeping track of it as well as making sure they are on track. Whatever they choose to keep

132 track of progress should be visible during the daily scrum. The team should be focused on the sprint and the product owner should be seeing the bigger picture. So I just wanted to make that that is clear. What state should the increment be in at the end of a sprint? At the end of the sprint, the new increment must be done, which means it must be in a usable condition that meets the team s the definition of done. This is to really highlight again, this concept of done, you will see popping up regularly.

133 What is the DEFINITION OF DONE? This is something that I have spoken about throughout the whole of my summary. Although it varies significantly per scrum team, members must have a shared understanding of done. So as long as everyone in the team knows what done means it does not matter if it varies from one team to the another because every team is different. Every team has got a different purpose so they may even have completely different skill sets. Software teams will have different outcomes to marketing teams and within software teams people focused on web

134 projects will have different outcomes to people focused on back end software development projects. Although it may vary from team to team there should at least be a shared understanding of definition of done within the team. It is a key to delivering the releasable increment within scrum. If the definition of "done" for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. The definition of done can often be a departmental 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

135 test automation. It was nothing to do with scrum, it was just one of the things we had to do. So therefore, by default it was part of the definition of done! In industry it is often forgotten that you do not have to think too hard around what constitutes done because it is often part of the setup of your organization. However, the team knows things the wider organization does not know, so the definition of done should be augmented with that knowledge, otherwise it can result in a huge loss of quality in the product. How do we create a DEFINITION OF DONE for

136 multiple TEAMS working on the same product? I have highlighted quite a lot here because I have noticed that these came up a lot in the open assessment. 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. You could have multiple teams working on a specific product for example by having a front end team (for the interface) and a so called back end team (for the database and code on the server). In this case it makes sense that they mutually agree on the definition of

137 done because otherwise what you could end up with is disjointed teams.

138 Section 6: Scaling Scrum

139 How do we scale scrum? The scrum framework brings structure and order to a project in a chaotic, fastpaced environment. It delivers a shippable increment of the product after each sprint and allows a business to increase return on investment through prioritization. As long as the scrum rules are carried out as its creators intended the results are phenomenal and business value is realized. However, what happens when the business requires greater output, many related projects to be synchronized to a deadline or a coordinated technical solution? This is

140 where the Scrum-of-scrums technique comes into its own. The Scrum of scrums is a method of coordinating teams and is used to grow and synchronize the scrum framework within a company to huge scale. As a scrum master I have used this technique to great effect in order to keep complex interrelated projects in sync. I have also noticed many dos and don ts that I will share with you. When you have read this section, you will fully understand: o What the scrum of scrum technique is o How it will benefit you and your organization of Learning and tips from an industry expert that you can apply to your everyday work

141 The Challenge - Scaling Scrum The challenge in scaling scrum across an organization lies within the scrum rule that a team should typically have between three and nine members. While this is a guideline and there is no substitute for common sense, teams should definitely be lean, mean productive machines. The challenge gets interesting when the business stakeholders wake up one morning and say I want to deliver quicker, let s put another thirty people on the project. Or if they say we need this delivered in three months and there are three other dependent teams you need to

142 deliver this with. Breaking the news that you want to limit the team to nine members would seem to limit the ability of the business to deliver. The scrum of scrums technique helps in these very situations, but before I explain how it works it is important to understand that scrum of scrums relies on all the original rules of scrum being carried out correctly, especially product backlog management and prioritization. For this reason, the product owner s role is key to the whole process and this should be discussed with the product owner(s) and stakeholders involved before embarking on a scrum of scrums mission in your organization. Continue

143 reading and you will see why this is so important.

144 What is Scrum of Scrums? The scrum of scrums is a meeting held to co-ordinate a set of inter-related scrum teams. The power and ability to scale is in the fact that one representative from each related team attends the scrum of scrums meeting. By doing this an organization can co-ordinate hundreds of people on different teams.

145 image credit to toolsforagile.com

146 The illustration shows four related scrum teams. From each team, a representative has been picked to attend the meeting. The representatives are shown sharing knowledge in the centre of the illustration. image credit to mountaingoatsoftware.com Once the number of members in the scrum of scrums becomes to large a representative from that meeting can join another scrum of scrums meeting and the process can continue. In this meeting, the host asks four questions (in the same vein as the daily scrum meeting). The questions are: 1. What have you accomplished since the last meeting

147 2. What do you aim to accomplish before the next meeting 3. Are there any impediments/blockers in your way 4. Are you about to do anything that could create a blocker/impediment to the project The first three questions aim to highlight progress, draw attention to targets and surface any issues that need to be addressed to keep the project on track. The last question stems from the fact that related projects can often unknowingly create problems for each other. For example, in the technology world, one team may deploy code that means vastly

148 more testing for another team. The meetings can be scheduled to be as frequent needed and are usually anywhere from daily to bi-weekly. It purely depends on the needs of the program.

149 Section 7: Preparing for Certification

150 CONGRATULATIONS Before I go any 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 and picked but you picked this one. I know you will get great value out of this as you have had a chance to really go through in detail, not only what the events are, what the rules and roles of scrum are, but also more importantly the scrum guide which is really the rule book on what scrum is.

151 WHAT YOU HAVE LEARNED So that being said let us have a quick recap of what you have learnt: So you have learnt all about the waterfall model, how it was the original method used for software development projects. How it was a less flexible method used in the past. You have learnt about the birth of agile, and that agile embraces change. How rather than it being an alternative to Scrum, it is an umbrella term for a number of methods, frameworks, and processes that all share a manifesto and a set of principles. This is really key

152 because it is something that gets confused often. You have learnt about the fact that agile is something more flexible than waterfall, because most agile methods are based around iterations and are based around the ability to deliver frequently - and that is really where scrum comes in, because you have also learnt what scrum is, how the empirical process control theory is really at the centre of scrum. We have learnt about the importance of iterations, which we call sprints, about all of the rules of scrum that help to make it such a great framework for delivering frequently and improving time and time again. We have learnt about the scrum theory

153 which is empirical process control theory. About inspection, adaptation and about the way that it plays a really crucial role but in order for that to work there must be transparency, so all in all there are 3 legs to it, transparency, inspection and adaptation. We have learnt about the scrum team roles and the scrum team which consists of the product owner, scrum master and the development team and that although the development team is a team, it is still part of the scrum team. You have learnt about the events - the sprint, sprint planning, sprint retrospective, the daily scrum and the sprint review which are the only events defined in scrum.

154 We have learnt about the scrum artifacts, the product backlog, the sprint backlog and the increment of releasable product which is delivered each sprint. have learnt also how to monitor We progress using the sprint burn down that we can use to show progress during the course of the sprint, and the release burn down that we can use to monitor progress during a release. These are not the only means of monitoring progress. You have also learnt about artifact transparency and the fact that it was brought into the scrum guide to really draw attention to the fact that in order for them to be valuable for delivering projects we really need to have those artifacts transparent to everyone in the

155 scrum team, and the stake holders. So you have learnt a lot and on top of all of that you have got my critiques, which delve into the scrum guide and ask some frequently asked questions and some common gotchas especially if you are going for a scrum certification. So all in all you have got a complete overview of scrum along with some pieces of the scrum guide that are really going to help you guys when you go towards the open assessment at scrum.org, scrum master psm 1 certification or in fact to any scrum certification.

156 How to Get PSM 1 Certified at Scrum.org You can now get your PSM 1 certification in 3 steps: 1. Do the SCRUM OPEN assessment at Assessments/Scrum-Open-Assessment/ I recommend until you get 100% 3 times. This is just a guideline. You need to feel confident : ) 2. Until you pass - Read the Scrum Guide or take my online course: Read this book and the scrum guide again till you pass the open assessment.

157 The scrum guide is available at: You can also sit my udemy course which is available with a bonus offer at Udemy. Just go to udemy.com/scrumcertification/ and enter coupon code book25. That s book25.

158 3. When you pass the open assessment - Choose the certification of your choice (including the PSM 1) at:

159

160 WHAT S THE NEXT STEP So once again I want to congratulate you but the question we maybe ask what is the next step as you have got all the information and there are a number of different things you could do next. I want you to do the following: 1. USE WHAT YOU HAVE LEARNED. So the first thing is to use what you have learned. The theory is based on practice and if you really want to master scrum you are not going to get it from a book or from a course. That is going to help you excel and become a master at your game, but obviously you won t know until you start using it how to deal with various problems or how to overcome them.

161 2. TAKE THE OPEN ASSESSMENT The second thing is if you are sitting this course you are probably doing it because you either really truly want to understand what scrum is or you want to sit certification and I would recommend before you sit a certification to go over to scrum.org and sit the open assessment as suggested above: Again, I recommend until you get 100% 3 times. This is just a guideline. You need to feel confident : ) What the open assessment will do is give you confidence and prepare you for any scrum.org certification. Now there

162 are 2 bodies you go to that I recommend if you want to get certified, it is scrum.org and the scrum alliance and the reason being is that the founders of scrum, Ken and Jeff and their partners are the people that built those companies and you can guarantee that if you pass the certification with those bodies, you really truly know scrum as those founders intended it. I always really tell my students to go for courses which are affiliated or recognized by scrum.org or the scrum alliance and in terms of sitting certifications, I recommend only going for certifications that come from scrum.org or scrum alliance. So if you go over to scrum.org and you go and sit the open assessment you can then brush

163 up on your skills till you are happy, then based on everything you have learnt you can sit the certification exam, So step one is to start using scrum, step two is to actually sit the open assessment as quickly as possible while you have this new found knowledge and come back and use this course if there is anything you are really not sure of. Remember the scrum guide is the number one place to look to and really understand what scrum is as well. You can also sit my udemy course which is available with a bonus offer at Udemy. Just go to udemy.com/scrumcertification/ and enter couponcode book25. That s book25.

164

165 3. DOWNLOAD THE FREE SCRUM EBOOK The third and final thing to do is head over and download my free scrum ebook which will really explain in Layman s terms the kinds of things you have been through, it is absolutely free, no strings attached and you can get it right now by going over to and if you head over you will essentially see a page where you can click the download now button and I will send you over a free scrum ebook. You will also be on my list and you will get all my blog updates and any information that is going to help you change your scrum game and take it to the next level.

166 So those are the 3 things, once again I really want to say congratulations and thank you for your time. I will be making more courses in the future, and I will keep you abreast of that as well as supply my contact details for you to get ahold of me when you go to and download my free scrum ebook. You will get an with contact details, as well as videos and more content that is really going to help you maintain what you have learnt and take it to the next level.

167 Conclusion Thank you again for taking this class! I know this class was able to help you to pass the scrum.org Professional Scrum Master (PSM 1) Exam. The next step is to start putting into practice what you have learned. All the greatest practitioners achieved their goals by putting tips such as these into practice and learning from their

168 experiences. You can do it too! Finally, if you enjoyed this class, would you be kind enough to leave a review? Click here to leave a review for this! Thank you and good luck!

169 Scrum Master: 21 Sprint Problems, Impediments and Solutions

170 Table of Contents Introduction Tip 1: Make a Point of Not Planning Up Front Tip 2: Don t Worry About Advanced Tools Tip 3: Use the Daily Scrum Properly Tip 4: Do Not Give Out Tasks Tip 5: Don t Dwell on a Failed Sprint Tip 6: Keep the Scrum Master Separate Tip 7: Keep Your Product Owner Involved Tip 8: Don t Use Stretch Goals Tip 9: Make it Clear that Individual

171 Sacrifice is Not Required Tip 10: Avoid Letting the Team Organize the Product Backlog Tip 11: Know When an Interruption is Serious Enough to Warrant Canceling a Sprint Tip 12: Do What You Can to Avoid Lagging Sprint Times Tip 13: Properly Prepare for All Demos Tip 14: Work to Create Potentially Shippable Products Tip 15: Do What You Can to Keep the Team Intact Tip 16: Avoid Imposed Limitations Tip 17: Know What Done Means in Context Tip 18: Find the Right User Stories Tip 19: Discuss Features with Product

172 Owner before the Sprint Review Tip 20: Use Roundtable Discussions in Retrospectives Tip 21: Deal with Leftover Work the Right Way

173 Introduction Thank you and congratulations on taking this class, Scrum Master: 21 Sprint Problems, Impediments and Solutions. In this class, you will be given a multitude of proven solutions that you can use to effectively solve common, problems, blockers or impediments and improve the productivity of your agile scrum teams. Delivering complex projects is never a straight line. Therefore, I know you will get value from this class as it gives you a brief introduction to the concept of the sprint. I then talk you one by one through each common (and uncommon)

174 project problem and suggested solutions. Along the way, as usual, I will give you plenty of examples and enlightening insight for how to remove obstacles and increase productivity within an agile scrum team. In this class, you will learn: A brief recap of agile and scrum principles What is a sprint and why it is often challenging to complete projects on time, even using sprints Key principles to use when solving impediments Concise tips for solving common and uncommon impediments within scrum So let s get started and let me teach you how

175 to solve impediments in your sprints using agile scrum.

176 Copyright 2016 by Pashun Publishing Press - a division of Pashun Consulting Ltd. - All rights reserved. This document is geared towards providing exact and reliable information in regards to the topic and issue covered. The publication is sold with the idea that the publisher is not required to render accounting, officially permitted, or otherwise, qualified services. If advice is necessary, legal or professional, a practiced individual in the profession should be ordered. - From a Declaration of Principles which was accepted and approved equally by a Committee of the American

177 Bar Association and a Committee of Publishers and Associations. In no way is it legal to reproduce, duplicate, or transmit any part of this document in either electronic means or in printed format. Recording of this publication is strictly prohibited and any storage of this document is not allowed unless with written permission from the publisher. All rights reserved. The information provided herein is stated to be truthful and consistent, in that any liability, in terms of inattention or otherwise, by any usage or abuse of any policies, processes, or directions contained within is the solitary and utter responsibility of the recipient reader. Under no circumstances will any legal

178 responsibility or blame be held against the publisher for any reparation, damages, or monetary loss due to the information herein, either directly or indirectly. Respective authors own all copyrights not held by the publisher. The information herein is offered for informational purposes solely, and is universal as so. The presentation of the information is without contract or any type of guarantee assurance. The trademarks that are used are without any consent, and the publication of the trademark is without permission or backing by the trademark owner. All trademarks and brands within this class are for clarifying purposes only and are

179 the owned by the owners themselves, not affiliated with this document.

180 Before we can discuss the specific details about how to make the most use of a scrum, let s first understand what agile scrum is all about.

181 What is Agile Scrum? In a nutshell, agile is an umbrella term for a set of frameworks and methods. These use iterative time boxed approachesand focus on building products incrementally from the beginning of a project rather than delivering it all at once at the end. Agile basically encourages frequent inspection and adaptation plus teamwork, accountability and self-organization. Moreover, the engineering behind agile projects allow speedy delivery of firstclass products and their business approach aligns development with company goals and customer needs. Agile often works by breaking down projects into tiny user functionality bits

182 called user stories, which are prioritized and then continuously delivered in short cycles (mostly 2 weeks) called iterations. Scrum is an agile framework that traces back to early 90s, which provides a framework for managing complex product and software development with iterative and incremental processes. Scrum is a very popular framework for implementing agile project management. Although some people think that agile and scrum is the same thing, this is wrong. While there are many frameworks for implementing agile, scrum is the most outstanding owing to its specific concepts and practices categorized into roles, time boxes and

183 artifacts. And although scrum is an agile technique that can be used for any project, it s mainly used for developing different software. It s mostly suitable for projects with requirements that change and develop very fast. Agilemethods (including Scrum) implement the agile manifesto of: Individuals and interactions above tools and processes Working software over comprehensive documentation Customer collaboration above contract negotiation Responding to change over following a plan

184 Scrum Theory Scrum is based on empiricism or empirical process control theory. The simple idea behind this theory consists of three principles: transparency, inspection and adaptation. Transparency (honesty) among the scrum team members is emphasized in that the product functionality is not done until the team says so. Transparency creates trust among the team members and enables them to consistently check up the progress (inspection) and make improvements based on what they see (adaptation). These improvements include practices, communication, sticking to values, or otherwise. Consistently inspecting and

185 adapting is quite powerful stuff. In so doing, they are improving over and over again, during and after the release of a product a feature that s not possible with other models of development. Generally, the components of scrum framework are: 1. Three roles: Product owner, scrum master and scrum development team 2. Sprints: A project iteration of less than a calendar month 3. Scrum events/ceremonies: Sprint planning meeting (what and how meetings), daily scrum meetings, sprint review meeting and sprint retrospective meetings. 4. Scrum artifacts Scrum has three artifacts:

186 a) Product Backlog: a prioritized backlog with end user requirements; the product owner is responsible for this (refer to the next section) b) Sprint backlog; Elected items from the product backlog. It s like a miniplan for achieving the sprint goal and delivering the product increment. Forecast the functionalities in the next increment and what needs to be done to deliver that functionality. The development team are responsible for this. c) Product increments: At the end of each sprint, the new product increment should be in a functional state and meets the scrum team s definition of Done. If all works well and the

187 team s estimation stays on track, the increment has all sprint backlogs items, meeting the team s definition of done. To help you to understand this better, let s talk more about these components of the scrum framework: 1. The three roles The entire scrum team is made up of three roles. The product owner (PO) Before carrying out any scrum project implementation activity, you need to find a relevant person who is willing to be a product owner. The product owner is a person who guides the team towards creating the right product and is solely responsible

188 for managing the product backlog by: Ordering the product backlog items inline with the goal and vision Ensuring these items are clearly defined and explained to all team members and that the backlog is visible and transparent enough to the team Giving the team their next agenda and optimizing the value of the team s work. However, although all these can be done by the development team, the PO remains accountable. If there are changes to the backlog item s priority, the PO must be involved. For the project to succeed, the PO s decisions need to be respected.

189 Scrum master TheScrum master is responsible for explaining and enacting scrum and makes sure those outside the team understand whether their interactions with the scrum team are helpful or not. The Scrum master serves the product owner, the team and the organization in the following ways: Helps PO find effective product backlog management techniques. Helps the scrum team understand why the product backlog must be clear and concise. Helps the development team develop high quality products Facilitates scrum events when

190 needed Acts as a coach; teaches both the team members and organization how scrum operates Protects the team from external interruptions and gets rid of any impediments to ensure peak performance Plans the implementation process in accordance with the scrum theory Scrum development Team This team consists of professionals that work towards delivering an almost releasable increment of what s referred to as a done product after the end of each sprint. They have every skill necessary to create what s referred to

191 as a product increment. They re solely responsible for creating any increment. They decide on the number of priority items or user stories to complete during a sprint. As a member of this team, you re referred to as a developer regardless of what you actually do (no titles). In addition, there are no sub-teams when it comes to addressing various issues like business analysis or testing; everything is done as a team. The size of the team must be small enough to stay agile and large enough to finish all the chosen tasks in a given sprint. Select a development team of three to nine people to avoid issues such as poor

192 delivery of potentially releasable product increments (for extra small teams) and poor coordination or management (for extra large group). Unless the PO and scrum master are also executing sprint backlog s work, they re not include in this count. Key Characteristics of the Scrum Team -Self organization is important in all agile scrum projects. The team is selforganized in that there is no overall team leader or project manager to impose stuff on the team. Decision making includes all team members (all inclusive). In agile scrum, the PO and scrum master support the whole scrum team but the team decides on what and

193 how much to do in a given sprint. The scrum team is also cross functional, which means everyone in the team is capable of and involved in taking any feature from idea to implementation without outside help. -Continuous improvements; inspect & adapt, is another central aspect in scrum in that the scrum team must regularly inspect and assess their products and processes for adaptation and improvement purposes. Doing this optimizes results, increases predictability and therefore minimizing the overall risk. Scrum works on the maxim that requirements could change quickly or cannot be fully known at the start of the project.

194 -Communication is another cornerstone of scrum framework. To identify and prioritize functionality, the PO works closely with the scrum team. This functionality is presented in form of user stories and then stored in a product backlog. (I ll tell you more about user stories and product backlog later on). 2. The Scrum Events Scrum projects progress through a series of sprints which form the backbone of these projects. A sprint is a project iteration that takes a period of time less than a calendar month, within which the development team works on their tasks until they develop a working increment of the product. Sprint planning meeting: Time Box: 8

195 hours for a one month sprint Planning Meetings are held at the beginning of each sprint which lasts a maximum of 8 hours (for 1 month sprints). It is attended by product owner, scrum master and scrum team. During the sprint planning meeting, the PO submits and describes the prioritized product backlog and explains to the team about the sprint goal and product backlog s top items. The team agrees on which prioritized items to complete during the upcoming sprint and then shifts these items from the product backlog to the sprint backlog-a list of necessary tasks that they ll do during the sprint to attain the sprint goal. In doing so, they break each product

196 backlog item into specific tasks they can effectively do during the sprint. Conceptually, the team selects the items to complete starting from the topmost, and then draws a line on the prioritized backlog after the lowest high-priority item they ve selected. After this meeting, the sprint kicks off. During the sprint, the development team takes a few ideas, create them and tests their functionality. In the end, these features become created, tested and eventually integrated into the developing product or system. Daily scrum meeting; Time Box: 15 minutes Every day, during the sprint, the scrum

197 master, scrum team and or product owner (optional) must attend a daily scrum meeting of less than 15 minutes. During these day to day scrum meetings, the team members talk about what they worked on the previous day, what they ll work on that day and identify any setbacks to progress. This daily scrums synchronize the scrum team s work plus their project knowledge, communication and decision making is enhanced. Sprint review: Time Box: 4 hours for a 1 month sprint At the end of each sprint, the scrum team carries out a sprint review which lasts for four hours for a 1 month sprint. During sprint review, the team

198 demonstrates the new functionality to the PO scrum master, customers and other stakeholders/sponsors interested in providing feedback that may perhaps influence the following sprint. The relevant stakeholders express their impressions and clarify whether their user stories/requirements are well implemented. The PO ascertains whether the product is really Done. This feedback loop could lead to changes to recently released functionality or just lead to revising or adding items to the product backlog. Sprint retrospective meeting; Time Box: 3 hours for a 1 month sprint TheSprint retrospective meeting is another event in scrum attended by the

199 entire scrum team at the end of each sprint. The entire team comes together to reflect on the sprint that has just ended as well as spot any improvement measures needed. They generally talk about how to make their work more effective and efficient in the future. While the sprint review is on the product, sprint retrospective meetings focus on the process. 3. The Scrum Skeleton A very easy way I ll use to further explain the agile scrum process to you is using a scrum skeleton. Here is diagram showing a scrum skeleton

200 On the left side of the skeleton, you can see the product backlog and a sprint backlog is adopted by the team, split into tasks, and worked on during a sprint. The team carry out requirements