Scrum Notes for Cert Test

docx

School

University of the People *

*We aren’t endorsed by this school

Course

1234

Subject

Management

Date

Nov 24, 2024

Type

docx

Pages

Uploaded by SmoothLyric30

Scrum Notes for Cert Test Non-adaptive and inflexible models are, for example, legally binding. Another example is a close contractual relationship for projects such as integrating banking software, where you have neither the freedom of creativity nor the ability to make decisions independently when problems arise. Each activity is performed step by step, according to a specific plan in the contract. A popular term for these situations in project management is the word "waterfall". The waterfall pattern is a similarity to the falling water on the stones step by step, from its beginning to its end. You create a completely innovative virtual reality platform. After six months, markets and users change. Users change, and new competitors emerge. Technologies evolve. This problem needs to be solved. The only way is to act according to your abilities, intuition, competence, and skills. You subsequently change your product, your technology, while simultaneously, research customers. You adapt to change. The popular term for a flexible working model is Agile. Rules are rules. For example, a meeting cannot be more than a certain number of minutes. Another rule is that your team cannot be more than 9 people. During a meeting, a role representative may be absent or may be present, but in no way engaging in the conversations. An iteration is just one period - for example, two weeks during which you work. Scrum requires regular work quality and results inspections. Inspection is performed daily and weekly, for example, which helps the team quickly identify obstacles and synchronize their efforts to overcome them. An adaptation then follows the inspection. This adaptability to changing requirements is key to achieving higher value. Scrum is created with roles, events, artifacts, and rules with the mission of delivering the most value to the end-user in the present events. The purpose of time-limited iteration at Scrum is to provide value in the form of a potentially incrementing product that can be delivered. This term is known as “potentially releasable product increment”. The success of an iteration is measured by the amount of value provided. The more value, the more success. The Daily Scrum is a limited-time event during which each member of the Development Team presents to the others very briefly what they did the previous day, what they will do today, and what problems and obstacles they have encountered or anticipated. This event is typical of the Scrum framework and is mainly used by Scrum teams. During the event, the members of the Development Team answer the following sample questions: What did I do yesterday that helped the Development Team meet the Sprint Goal? What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediments that prevent the Development Team or me from meeting the Sprint GoaL? four Agile manifesto values and principles. The "Agile Manifesto" states:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan

The Agile approach promotes repetitive, growing, and highly adaptable workflows that lead to the delivery of a functioning product as soon as possible after the start of the project (within weeks, not months). The highest priority is customer satisfaction through early and continuously phased delivery of a high- value customer product. Changing requirements are welcomed and not seen as troublesome or inconvenient, even if the change is in the final stages of the project. A working product is a substantial measure of progress. Sustainable development is encouraged. Sponsors, developers, and users must be able to maintain a steady pace as the project progresses. Continuous attention to technical excellence and good design increase flexibility. The three Pillars of Scrum are applied for productive improvement. They are:  Transparency The three Pillars of Scrum are applied for productive improvement. They are: Transparency Inspection Adaptation  Inspection o Verification is performed throughout the Sprint. If a Scrum team member has any concerns and encounters any obstacles, those concerns are shared with other team members. Sharing occurs during the Daily Scrum meeting, the Retrospective meeting, or during the Sprint Review meeting. BVOP states that sharing problems can happen at any other time without waiting for specific events if this does not interfere with the team in any way. o The official term for these meetings is "events". o The Scrum Team consists of all product developers, Scrum Master, and Product Owner.  Adaptation o When obstacles arise as a result of inspections, the Scrum team adjusts how they work to remove them. These can be situations where the Scrum process is compromised or can be improved in some aspects.

o Another problem may be, for example, that the team is not progressing as expected, or the work of the team is not increasing the business value of the product, etc. o Scrum requires the removal of these obstacles as soon as possible, but it is up to the team to determine exactly how to do it. Developers, Scrum Master, and Product Owner work together to solve their problems. Empirical practices are used in Scrum to ensure continuous improvement of workflows and real results. Scrum allows continuous improvement through its events (Daily Scrum, Retrospective, and Sprint Review). These events are inspection and adaptation opportunities that take place at regular intervals. Kaizen Kaizen includes all aspects of organizations and all their participants. This philosophy aims to eliminate waste and deliver even more high-quality practices. Empirically, Kaizen involves performing small experiments and then monitoring the results and making appropriate adjustments. Kaizen proposes doing this all the time when it is applicable. The Kaizen cycle can be defined as: "Plan → Do → Check → Act". This is also known as the Shewhart or PDCA cycle. Another technique used in conjunction with the PDCA is the "Five Whys". This is a form of root cause analysis in which the user asks a series of five "why" questions in the event of failure, where each follow-up question is based on the previously given answer. Kanban Kanban is a Just in Time (JIT) production planning system. Taiichi Ohno, a Toyota industrial engineer, developed Kanban to improve production efficiency. It is one of the methods of achieving JIT. Kanban is perceived as a useful tool for maintaining the manufacturing system as a whole, and a great way to encourage improvement. Problem areas are highlighted by measuring execution time and cycle time of overall process steps. One of the main advantages of Kanban is to set a maximum limit for work that is in the process of being created and completed (Work in Progress). n software engineering, Kanban is used to limit the work in progress. These limitations aim to reduce the number of defects and the stress on teams and increase their focus. By introducing work limitations and minimizing obstacles, overall productivity should increase The team plans the number of "cards" (items, tasks) during the Sprint Planning meeting. Validation and change are at the heart of the whole Agile culture. Scrum has sprints and roles (Scrum Master, Product Owner, and Development team). There are no sprints or roles at Kanban. In both cases, the teams are self-organizing. The Kanban board is used continuously throughout the product development lifecycle

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

by simply replacing the cards. At Scrum, at the end of each sprint, the dashboard is renewed. No new cards (items) are added until the end of the sprint. Cards are also often found in columns and have a corresponding status. What is Lean? Lean thinking is a business idea that aims to provide a way of thinking about organizing human activities to provide more benefits while eliminating waste. What is MVP MVP stands for “Minimum viable product”. A minimum viable product has sufficient functionality that satisfies early adopters who provide feedback on its future development. MVP is recreated in cycles. MVP is recreated in cycles and iterations by generating ideas, prototyping, collecting data, analyzing, and learning from the results so far. The goal is to minimize the total time spent in an iteration. The process is repeated until the desired product is obtained or until it is considered unsustainable. The Waterfall method is the traditional project management approach. The Waterfall is a linear and consistent procedure. This means that in this approach, you are processing one phase after another in a linear fashion and do not have any overlap in the phases. Iterations in Scrum. Scrum is organized in cycles. It is "iterative". It means repetitive. In Scrum, work is organized at intervals called Sprints. Inspection and adaptation also occur iteratively within each Sprint. Scrum events (Daily Scrum, Sprint Planning, Sprint Review, and Sprint Retrospective) also take place at each iteration (repetition). What is Increment? The simplest explanation is that increment is the current version of the product you are developing. This current version contains all the previous work put into the product, plus the one in the current sprint. Scrum has three roles: Development team - The development team may include people of different competences, skills, and positions. These can be programmers, designers, architects, engineers, quality control, business analysts, and anyone else who actually works on the product. Product Owner - The Product Owner is the role that represents the voice of the stakeholders and is responsible for ensuring that the team delivers value to the business. The Product Owner role prioritizes all items in the Product Backlog list by their "business value" for the product. This role comprises high product and field knowledge, holding consultations with stakeholders, and giving individual judgment to each task or idea. Scrum Master - The most important role of the Scrum Master is to make sure that the Development team works by following the values and practices of Scrum. It also seeks to create comfort, remove barriers, teaches and educates the team on productivity, self-organization, responsibility, and discipline. The Scrum Master role, like all other roles in Scrum, has no authority to manage people, work, or anything. However, it has authority over everything related to Scrum processes, events, rules, ideas. The Scrum Master acts as a leader for the team, not as a manager. Leads the team toward their goals.

Key responsibilities of the Scrum Master role include : Monitoring and eliminating obstacles in the workflow. Protecting the team from unwanted outside interference. Assistance with meetings and Scrum events. Collaboration with the Product Owner role. Coaching and guidance of all product stakeholders (Scrum team and business stakeholders) on Scrum practices and concepts. The official Scrum artifacts are: Product Backlog - Product Backlog is a whole bunch of ideas, items, and development proposals that are accumulated and compiled into a list. All the ideas, requests, and tasks that come in the form of a large list are called Items Sprint Backlog - Sprint Backlog is a work and task list that is a sample of the entire Product Backlog list. Sprint Backlog is the "list" of "tasks" that the Development Team must complete during a specific sprint (period). They are called items because their form can be very different. Something can be written down as an idea, another as a task, third as a defect, fourth as a suggestion for improvement, fifth as a User story, sixth may be just a graph or a diagram, etc. Product Increment - The increment is the current version of the product under development. This current version contains all the previously done work on the product, plus the work done in the current Sprint. By "work done" we mean finished Product Backlog Items from the Sprint Backlog list. BVOP adds a few more essential artifacts to this list that underpin every product development : Sprint Goal - Sprint Goal is an abstract and common goal for the current sprint. A sprint can have many "tasks" from the Sprint Backlog list, but the overall "goal" is a summary of them all. The Sprint Goal can be defined in free text. The goal should explain why the current product increment is being developed and direct the team towards achieving the goal. It is also indicated that the Sprint may be terminated if its purpose becomes obsolete. The goal of the Sprint is defined during the Sprint Planning event by the entire Scrum team. the following purposes of a practical Sprint goal: To help prioritize work during sprints. It helps to make effective decisions. Supports focus during the Sprint Planning meeting.

Assists teams and collaborations. Definition of Done - Definition of Done is a set of criteria that must be met by all Product Backlog Items so that they can become part of a Product Increment. Once all these requirements and criteria are met, and everything described in them is complete, the Product Backlog Item can be considered done. Product Vision - A product vision can be understood as a "description" of the product. It contains several sections with information such as users, competitors, advantages, promotion methods, ways of distribution, etc. Burn-Down Chart - Burn-Down Chart is a simple graph that shows the finished work and the remaining time in a sprint. By finished work, we mean completed items from the backlog. Most often, this chart is valid for the current sprint only. The purpose and application of this graph are simply a quick and easy way to view your progress on the task at a glance. The official Scrum events are: Sprint - The length of a sprint, according to the official definition in the Scrum Guide, should not exceed one calendar month. Sprints usually last from one to four weeks. A popular term for stopping a sprint prematurely is “Cancelling a Sprint”. Only the Product Owner role has the right to terminate the Sprint. Sprint Planning - Sprint Planning meeting. At the beginning of the Sprint, the Development team receives some User Stories (ideas and needs that the customer expects to be made soon), prepared, and prioritized by the Product Owner role. The development team chooses precisely how many User Stories can be developed through the upcoming Sprint and how exactly the work will be done. Daily Scrum Sprint Review - The Sprint Review event (meeting) involves the entire Scrum team as well as the roles and representatives of the client or user. During this event, the Scrum team presents the completed work. Scrum has no rules as to who should do this. Usually, the Scrum Master or Product Owner roles present the product increment, but everyone from the Development team is welcome to perform the presentation. Sprint Retrospective - After the work is completed and before you reach the official end of the Sprint, a Sprint Retrospective event is held. The team discusses their work, customer comments, evaluates work, and processes. After the end of this meeting, the Sprint can officially be considered as finished. The next Sprint begins on the next business day. Sprint Completion The Sprint must be completed at the end of the last day even if some User Stories are not completed. Sometimes it happens that some User Stories are not completed. One idea is to move all incomplete User Stories back to the list of all Product Backlog Items. The Product Owner role can decide whether to put unfinished User Stories at the top of the Product Backlog. The Items placed above are considered the

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

highest priority. If these User Stories are put back on top, they should be taken on the next Sprint. However, the Product Owner role may choose to move the unfinished User Stories down the list if he or she believes that for the next Sprint, the team may need to work on something else. The Product Owner represents the stakeholders People can have a work schedule and work hard on every project but there is always the likelihood that they will put effort into parts that are not that important. The Product Owner role is the "stakeholders' voice" and is responsible for giving value to the work that comes from the Development team. Value, in this case, means producing an effort (work) on tasks that are of the utmost importance to the product. The Product Owner role creates user-oriented "tasks" (items). Items have a broad meaning and include not only User Stories but also defects (bugs), research tasks or technical improvements, ideas, etc. The most popular item format is called User Stories. These are the "tasks" that the entire team works on to create the product. The Product Owner also prioritizes the entire User Stories list (the Product Backlog) so that the team can focus on the most valuable ones. User stories can be broken down to separate small tasks, which facilitates the team and makes tracking and control a bit easier. User Story can be defined as a whole idea that is developed by one or a number of team members who each do their part (task or tasks). Product Vision Product Vision is a collection of information divided into groups. Data is collected on the actual users of the product, their needs or expectations, ways of distribution, sales methods, and other market factors. The factors determining the price can also often be a theme in the Product Vision. When all this information is gathered, the Product Vision serves as a basis for creating ideas, concepts, prototypes for the project, as well as its actual production. In classic Product Management, working on the Product Vision is Product Manager activity. But since Scrum does not include a Product Manager role, the Product Owner role is the closest to Product Manager. The primary responsibilities of the Product Owner role can be defined as: Keeping an idea and vision of how the product will develop. Continuous cooperation and communication with stakeholders. Creating and maintaining a Product Backlog - writing User Stories. Prioritize Product Backlog. Release Management - Define phases and release dates for new product releases. Track work progress, time, and budget

User stories The Product Owner "translates" stakeholders' desires and records them in the form of User Stories using an understandable language. In the process, the Product Owner and the Scrum Master roles communicate with the Development team to ensure that they understand the user stories.User Story is an informal and brief description of any consumer need. Usually, a User Story is a written form that represents the perspective of the potential consumer of the product regarding its functionality. User Stories are based on users who need functionality and have goals. It is recommended that a User Story is created in such a way that it can be completed within a Sprint. If a duration of a Sprint is one week, this means that the User Story should not take more than that to be created, tested, and accepted (approved) by stakeholders. It should allow easy testing, validation, and acceptance. The user story follows a standard and is created using the following format: As a (role), I need (capability), so that (receive the benefit). (role) - The role is "who" needs something. (capability) - the exact need (receive the benefit) - a positive result for one who requires something (the user). Acceptance criteria A User Story is recommended to include an Acceptance criteria section, as it is an important part. These "acceptance criteria" contain the "conditions" that the work of the Development Team must meet. Acceptance criteria are added to each User Story to guide testing conditions. A User Story cannot be accepted partly for any reason. All conditions must be met. Of all the prioritized Product Backlog Items, the Development Team decides how many tasks it can develop during a Sprint. Logically, during the Sprint, the team works on the User Stories, which are listed at the top of the Product Backlog. These stories become part of the Sprint Backlog list. Release management The release is understood as releasing or providing completed work. Project Managers, Product Managers, Product Owners, and other roles from different methodologies, often use this term. A release may mean a finished part of a product or a specific version that has been modified or made more advanced than previous ones. A release can also be used as a phase or a period. For example: "In Release 2, we are completing user registration. In Release 3, we need to fix any registration defects." The Development Team The Development team at Scrum has between 3 and 9 developers in total. The Scrum Master and Product Owner roles are not included. If the team has one Scrum Master, one Product Owner, and a

Development team of three, the entire Scrum Team is made up of 5 participants in total. If the Scrum Master and the Product Owner are not part of the Development Team, then the entire Scrum Team will be 11 people total. If the Scrum Master and the Product Owner take two roles and they are also developers, then the entire Scrum team will be 9 people. Responsibilities of the Development Team Creates the so-called Product Increment - product update and enhancement. Shares responsibility for creating a quality product, along with the Product Owner role. Shares estimated time to complete their tasks. Sprint Completion The Sprint must be completed at the end of the last day even if some User Stories are not completed. Sometimes it happens that some User Stories are not completed. One idea is to move all incomplete User Stories back to the list of all Product Backlog Items. The Product Owner role can decide whether to put unfinished User Stories at the top of the Product Backlog. The Items placed above are considered the highest priority. If these User Stories are put back on top, they should be taken on the next Sprint. However, the Product Owner role may choose to move the unfinished User Stories down the list if he or she believes that for the next Sprint, the team may need to work on something else. Alternatively, a User Story can be split into many smaller User Stories. The completed parts of it during the Sprint can be composed into one new User Story and all the unfinished parts can become other User Stories, which can be distributed among the next Sprints. Calculating Team Velocity During a Sprint, the entire team completes tasks or User Stories. At the end of the Sprint (a week or two weeks, or any other period), the team completed, for example, 10 User Stories (Product Backlog Items). Each of these 10 tasks, User Stories or Product Backlog items, had specific Story Points. A Product Backlog item was rated 3 Story Points. Another was rated 8. Some could be 1 or 21. If we add up the total of these completed 10 items during the Sprint, we get a number. For example, 133. 133 is the Velocity value of the team. What can we use Velocity for? Planning Sprint work. After we have calculated the Velocity of the team, it can be easier to predict how many tasks or Product Backlog items can be completed by the Development team in the next period (Sprint). If one participant leaves the team, you simply subtract 27 from 133 to get 106. The team can produce such work points during the next period (Sprint) if you are left without one participant. Fibonacci numbers are often used as the standard for Story Points, which are used for work sizing: 1, 2, 3, 5, 8, 13, 21. If a project manager listed the task "Creating a Product On/Off Button" and it had an estimated development time of 1 day, the Product Manager or the Product Owner would write a User Story with the content "As a product user, I need to turn on and off the product. " The Product Manager or the Product Owner will then consult with the technical teams, and they together estimate the

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version

Access to all documents
Unlimited textbook solutions
24/7 expert homework help

development time required as Story Points 3. With these principles of "sizing" work, a User Story that will take very insignificant development time can be written to take "1" work time or "S" work time. You can define a more significant task as "5" or "L", for example. A huge task may need a "21" or an "XL". Recommendation for using relative estimation - When estimating time using relative units, we recommend applying numerical values (1, 2, 3, 5, 8, etc.), especially when planning and estimating development time for more extended periods. If 133 was the Team Velocity of the past Sprint, the new planned Product Backlog Items with their Story Points need to have a total sum of about 133. When that sum reaches a total Story points of about 133, you can count on the fact that those planned Product Backlog Items will be successfully developed by the team during the next Sprint. Suppose the Development team consists of 5 participants. They all completed 133 points of work. If you divide 133 work points amongst 5 participants, you will receive 26.6. Let's round this number to 27. So we can roughly say that one member of the Development team completes 27 points in one Sprint. MVP is recreated in cycles MVP is recreated in cycles and iterations by generating ideas, prototyping, collecting data, analyzing, and learning from the results so far. The goal is to minimize the total time spent in an iteration. The process is repeated until the desired product is obtained or until it is considered unsustainable. A minimum viable product has enough basic features (or functionalities) for effective initial product launch and nothing more. MVP stands for “Minimum viable product”. A minimum viable product has sufficient functionality that satisfies early adopters who provide feedback on its future development. The product vision A product vision can be understood as a "description" of the product. It contains several sections with information such as users, competitors, advantages, promotion methods, ways of distribution, etc. This information is defined at the earliest stages when the product is still just an idea. Product teams use this "vision" as a basis for creating concepts, ideas, and further. The Burn-Down Chart Burn-Down Chart is a simple graph that shows the finished work and the remaining time in a sprint. By finished work, we mean completed items from the backlog. Most often, this chart is valid for the current sprint only. The purpose and application of this graph are simply a quick and easy way to view your progress on the task at a glance. Indications for a self-organizing Development Team The team does not have a specific person who makes decisions for everyone or orders others. The whole team takes responsibility for the work that is done. The team and its members choose their tasks themselves, without anyone else assigning them.

There should be no situation where Scrum Master, Product Owner, or some team leader assigns tasks. All decisions and all teamwork are focused on achieving the Sprint goal. The entire team and all members estimate the time required to develop tasks. The team provides the work itself. The whole team keeps track of their progress and tries to go according to plan. The team inspects its work and makes the necessary improvements. Timeframe Each Scrum event has a specific purpose and a particular time frame (fixed time). The concept of accurate time-keeping allows participants in an event to be clear-headed, more precise, and focused on their goals rather than distracted by unnecessary activities or discussions. It is the Scrum master’s responsibility to ensure that everyone in the Scrum team adheres to the timeframes. It is up to each Scrum team to decide the length of their Sprint. The duration of the Sprint is consistent, which means that throughout the project (from start to finish), all Sprints must have the same duration. The length of a sprint, according to the official definition in the Scrum Guide, should not exceed one calendar month. Sprints usually last from one to four weeks. Sprint Retrospective After the work is completed and before you reach the official end of the Sprint, a Sprint Retrospective event is held. The team discusses their work, customer comments, evaluates work, and processes. With shorter sprints, you have more frequent meetings. Problems are defined more often, and solutions are found faster. Short sprints provide more frequent customer feedback. Thus, the chance of creating unnecessary work or doing something wrong is reduced because the client will identify these irregularities when the increment is demonstrated.

Scrum Notes for Cert Test

Related Documents