part0001

Scrum for Beginners An Ultimate Guide to Increase Productivity and Performances
ZANE LITTMAN

This document is geared towards providing exact and reliable information with 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 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 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 book are for clarifying purposes only and are the owned by the owners themselves, not affiliated with this document

TABLE OF CONTENTS

Introduction Chapter1 the origin of term Chapter2: Scrum: Technical and Advanced Scrum Chapter3: Organization Chapter 4:Sprint Retrospective
Chapter 5:Epics, Trends, and Problems
Chapter 6: Agile Calculation and Estimate Why Measure?
Chapter 7: Dialectical Spiral of Knowledge

Chapter 8: People
Conclusion

Introduction

Scrum is simple. There are few practices, only straightforward. But Scrum is difficult. The Scrum methodology consists of this process definition and the Scrum Project Management Program, which provides automated support for some of these tasks. The Scrum technique is a comprehensive framework for handling product development. Scrum can be fully scaled from small to large projects, from easy to complex projects. Scrum is an agile technique, so the likelihood of success with Scrum remains high across difficulty levels until chaos is reached at which stage there is no appropriate approach or procedure.

The technique for Scrum is composed of stages and tasks. The preparation, scheduling, production and release phases are in the process. Planning and planning plan the workload for the development phase, where all practical development is carried out iteratively, each Sprint produces a complete increase in the functionality of the product that can be released. The methodology shows the few objects and roles that are required. These artifacts and functions are organized in high-level tasks undertaken by each role within the phases. The tasks give information about what to do but not how to do it. Scrum is an agile way of doing things. The people applying for Scrum are provided with guidance, but flexibility and expertise will be needed to handle the project work and complete the activities. To successfully complete every task, their review of the unique circumstances and characteristics of the project is mandatory. Scrum is not a cookbook. Here's a reference. The preparation of the three main managers of a Scrum project is a key part of the methodology: the Product Owner (or customer), the Scrum Master (or project manager), and the production team(s). Training gives these parties the information they need to apply Scrum intelligently to their project.

Chapter 1

The Origin of Scrum.
Scrum is an agile model of growth characterized by:
➢ The application of a gradual development strategy rather than the full preparation and execution of goods.
➢ The consistency of the outcome is dependent more on people's tacit knowledge in selforganized teams than on the nature of the processes used.
➢ Overlapping the different phases of growth in a linear or waterfall process, instead of executing them one after the other.

Ikujiro Nonaka and Hirotaka Takeuchi described and established this model in the early 1980s, evaluating how the major technology companies developed new products, such as: the Fuji-Xerox, Canon, Honda, Neck, Epson, Brother, 3 M and Hewlett-Packard (Nonaka & Takeuchi, The New Product Development Game, 1986).

In their report, Nonaka and Takeuchi contrasted the new form of teamwork they described with the scrum formation of Rugby players and they called it "scrum" for that reason.

Since this type of work originated in companies with technical products, it is ideal for projects with uncertain requirements and for those needing speed and flexibility, frequent situations in the production of some software systems but also in many other sectors and industries.

In 1995 Ken Schwaber proposed "Scrum Development Process" in OOPSLA 95 (SCRUM Development Process), a software development system focused on scrum concepts. He used it in the development of Delphi and Jeff Sutherland in his company Easel Corporation (a company that would combine in a series of acquisitions and mergers in VMARK, later in Informix and finally in Accentual Software Corporation).

What we mean now as "scrum" 1.-Rugby

Rugby scrum formation Scrum is the term that describes the most identifiable rugby formation, in which both sides, crouching and grasping each other, fight to get the ball, and extract it from the formation without touching it by hand.

Scrum Guide

Scrum's aim is a structure for the creation and sustainability of complex products. This Guide includes the Scrum description. This definition consists of the roles, events, artifacts, and rules of Scrum which bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.

A system within which people can solve complex adaptive challenges while producing goods of the highest possible value in a productive and creative manner.

Scrum is:
➢ Lightweight
➢ Easy to understand
➢ Difficult to master

Scrum is a process system which has been used since the early 1990s to handle complex product creation. Scrum is not a product-building process or technique; rather, it is a structure through which you can employ different processes and technologies. Scrum makes it clear that your product management and growth activities are relatively effective so that you can improve.

The system for Scrum consists of Scrum Teams and associated positions, activities, objects, and rules. -function serves a specific purpose within the system and is important to the success and use of Scrum.

Scrum's rules tie events, tasks, and artifacts together, regulating their relationships and interaction. Scrum's rules are defined in the entire body of this text.
Specific strategies differ and are defined elsewhere for using the Scrum System.

Scrum Theory Scrum is founded upon theory of empirical process control, or empiricism. Empiricism argues that knowledge stems from experience and decision-making based on what is learned. Scrum makes use of an iterative, incremental approach to improve predictability and risk management.

How Scrum Works
➢ Embracing Change: Change and change is not an annoyance but a potential source. Organizations which handle uncertainty better have a competitive strategic advantage

➢ Self-Organization: Everyone is responsible for getting work done and encouraged to decide how to do it, from the CEO to the entry-level employees. WASTE is any structure more than the minimum required to work

➢ Business Value Focus: All actions are viewed through the lens of what is generating business value. Every sprint we prioritize the research that at that point in time produces the most business value.

➢ Continuous Improvement : We think about how to work better every day and in everything we do, and then follow through to eliminate the upper impediment. Our iterative approach to work lets us progress more quickly.

➢ Non interruption: We work best if we concentrate on one thing until it's finished, all the way through to a product that can be sold. Multi-task forces us to move costs, and is less successful.

➢ Customer-Centrism: The core motivation for our work is customer service. We are keen to find out what they like and our highest priority is to please customers early and regularly. ➢ Radical transparency: Knowing where we are as close to real time as possible enables us to make better and more responsive choices.
Scrum Scalability

Ideally Scrum Teams should have six to ten members to be successful. This behavior may be the explanation for misunderstanding that only small projects can use the Scrum system. Nevertheless, it can be easily incorporated into large projects for successful use. For cases where the size of the Scrum Team is greater than 10 members, multiple Scrum Teams may be formed to work on the project. The Scrum Convene Scrum process encourages collaboration between the Scrum Teams, allowing successful execution in larger projects.

Big or complex projects are often carried out as part of a program or portfolio. Often, the Scrum method can be used for handling both projects and portfolios. Within this context, the systematic methodology of the rules and principles can be used to handle projects of any scale, spanning geographies and organizations.

Large projects may have several Scrum Teams working in parallel making it important to synchronize and promote information flow and communicate better. The Scrums Convene Scrum is the mechanism that ensures this synchronization. At this meeting, the different Scrum Teams are represented and the aims are to provide feedback on progress, address the challenges faced during the project and organize activities.

There are no set rules as to the frequency of such meetings. The factors which decide the frequency are the amount of inter-team dependence, project size, complexity level, and Scrum Guidance Body recommendations.

Working methods

Agile self-organizing work environment in 1986, researchers Nonaka and Takeuchi gave a polygenic dimension to the word scrum that was originally used in sports as rugby when it was used to baptize the production concepts they found in the most innovative technology companies (Takeuchi & Nonaka, 1986).

Scrum, in Nonaka and Takeuchi's original conception, is characterized by the role of creative, selforganized and driven teams approaching the development of complex systems beginning from a general vision and overlapping phases of development.

Software development methodology In 1995 Ken Schwaber proposed a software development approach based on a scrum environment at OOPSLA (Schwaber, SCRUM Development Process, 1995), and they used the same concept to describe the process.

Software development framework based on Ken Schwaber's scrum methodology

The organization "Scrum Alliance" was founded by Mike Cohn, Esther Derby and Ken Schwaber in 2005 to disseminate a specific software development framework based on that methodology. It was called scrum too.

Scrum Manager uses the term in the original meaning provided by Nonaka and Takeuchi as a working environment defined by the composition of self-organized teams working together in an agile manner: flexibility and overlapping of development phases, sharing of knowledge and learning in an open manner.

Scrum Benefits Companies in thus ways:
Faster: Scrum helps teams improve constantly, so that they can deliver more in less time

Better: Scrum positions the customer at the forefront of design and development, resulting in more commercially successful goods
Happier: Scrum empowers working teams to make choices and unlock their strengths, leading to greater employee satisfaction.
Every implementation of empirical process control is enforced by three pillars: transparency, inspection and adaptation.

Scrum Values and Principles

Digital Scrum establishes a structure for organizing people and working flow. It is the "bone" or the observable code, but the agile ideals are the genuine agility driver of the concepts guiding the way they work.

Scrum principles can be applied in any organization to any type of project, and must be adhered to ensure successful application of the Scrum structure. Scrum Values are non-negotiable, and must be followed in conjunction with the scrum guide. Maintaining the principles intact and using them correctly instills confidence in the Scrum process for achieving the project's objectives. Nevertheless, the elements and procedures of Scrum can be changed to suit the project or organization’s requirements.

1. Empirical process control: This theory underlines Scrum's fundamental ideology focused on the three central principles of openness, examination, and adaptation.

2. Self-organization : This concept focuses on today's employees who, when self-organized, produce significantly greater value, resulting in better team buy-in and shared ownership; and an innovative and creative climate that is more propitious to growth.

3. Collaboration: This concept focuses on the collaborative work's three main dimensions: perception, articulation, and appropriation. It also supports project management as a mechanism of shared value development, with teams working and communicating to achieve the greatest value.

4. Value-based prioritization: This concept underlines Scrum's focus on delivering full business value, from early on in the project, and throughout.

5. Time-boxing: This theory explains how time in Scrum is considered a limiting constraint, and is used to help manage project planning and execution effectively. In Scrum, timeboxed components include Sprints, Regular Standup Meetings, Sprint Planning Meetings and Sprint Review Meetings.

6. Iterative Development: This definition describes iterative development and underlines how changes can be better managed and products can be developed to meet customer needs. It also delineates the roles of the Product Owner and the company in relation to iterative growth.

A scrum team's rules may be those of this, or others, technical structure. Agility does not come from the satisfaction of activities, but from beliefs.
➢ Interpersonal value. Team members have to trust each other and value their skills and competencies.

➢ Obligation and self-discipline (no forced discipline). ➢ Customer-focused and value-oriented jobs. ➢ Â Compromise.

And the principles guiding their way of working are: to empower the team and its leaders so that they can coordinate themselves and make development decisions. Data, accountability project development visibility. Frequent examination adaptation to detect and modify deviations.

Quality

To ensure a project meets the quality requirements, Scrum adopts a continuous improvement strategy whereby the team learns from feedback and involvement of stakeholders to keep the Prioritized Product Backlog constantly updated with any changes in requirements. The Prioritized Material Backlog is actually never complete until the project is finished or terminated.

In Scrum, quality is characterized as the ability of the completed product or deliverables to meet the Acceptance Criteria and attain the business value the customer requires. Any changes to requirements reflect changes in the internal and external business environment and allow the team to work and adapt to meet those requirements on a continuous basis.

Since Scrum needs work to be done in intervals during Sprints, this ensures that mistakes or faults are noticed earlier by repeated quality testing, rather than when the final product or service is close. In addition, the same team completes essential quality-related tasks (e.g. development, testing, and documentation) as part of the same Sprint — this guarantees consistency. This guarantees the intrinsic consistency of any deliverables created as part of a Sprint. Those deliverables which are theoretically shippable from Scrum projects are referred to as' Completed.'

Continuous improvement with repeat testing thus optimizes the probability of achieving the desired quality levels in a Scrum project. Constant meetings between the Scrum Core Team and stakeholders (including consumers and users) with actual product improvements being delivered at the end of each Sprint, ensures the difference between project customer expectations and actual generated deliverables are continuously every.

The Scrum Guidance Body may also provide quality guidance which may be applicable to all of the organization's Scrum projects.
Change
Any project is exposed to change regardless of the method or system it uses. It's imperative that project team leaders realize that the processes for Scrum creation are built to embrace change. Organizations should try to maximize the benefits of transition and mitigate any negative impacts by proactive change management processes in line with Scrum principles.

A primary concept of Scrum is its understanding that a) stakeholders (e.g. consumers, participants, and sponsors) change their minds about what they want and need throughout a project (sometimes referred to as project. "Specifications churn")) and b) stakeholders find it very difficult, if not impossible, to identify all the specifications during project initiation.
Scrum projects welcome change through the use of fast, iterative Sprints that integrate customer feedback on the deliverables from each Sprint. This helps the customer to communicate with the members of the Scrum Team on a regular basis, display deliverables as they are ready and adjust specifications earlier in the Sprint if necessary.

Also, the portfolio or program management teams can also respond to Change Requests related to specific Scrum projects at their level.
Risk

Risk is defined as an uncertain event or set of events that can affect the objectives of a project and may contribute to its success or failure. Risks that are likely to have a positive impact on the project are referred to as opportunities, whereas threats are risks that could affect the project in a negative manner. Risk management must be proactive, and it is an iterative process that should begin at the start of a project and continue throughout the lifecycle of the project. The risk management process will follow certain systematic steps to ensure that risks are detected, assessed, and a correct course of action is identified and acted upon as necessary.

Risks should be identified, assessed, and responded on the basis of two factors: the likelihood of occurrence of each risk and the possible impact in case of such occurrence. Risks with a high likelihood and impact value (determined by combining all factors) should be discussed before those with a lower value. In general, it is important to understand the risk with respect to the likely causes and potential effects when the risk occurs.

Initiate

1. Build Project Vision: The Project Business Case is checked in this process to create a Project Vision Statement which will act as the catalyst and guide for the whole project. During this process the Brand Owner is identified.

2. Determine Scrum Master and Stakeholder(s): In this process, unique Selection Criteria are used to determine the Scrum Master and Stakeholders.

3. Shape Scrum Team— Members of Scrum Team are established in this process. The Product Owner is usually primarily responsible for recruiting team members but often does so in conjunction with the Scrum Master.

4. Create Epic(s)—The Project Vision Statement serves as the foundation for the creation of Epics in this process. Meetings of user groups may be held to address related epics.

5. Creating Prioritized Product Backlog — in this process, Epic(s) will be optimized, expanded, and then prioritized to create a project backlog for the prioritized product. At this stage, too, the Finished Criterion is set.

6. Conduct Release Planning: In this step, the Scrum Core team evaluates the customer stories in the Prioritized Product Backlog to create a Release Planning Schedule that is effectively a staggered delivery schedule that can be shared with the project stakeholders. Sprint length is also set in this process.

CHAPTER 2 Scrum: Technical and Advanced Scrum

Beginning with scrum, the standard framework should be adopted: as discussed in this first section, where you can find the functions, objects and events that configure its lifecycle model (see diagram on page 20).

Once a continuous and iterative advance flow is reached, you need to decide whether the goal is to go beyond what is a simultaneous development model, or follow scrum practices, or other methods that may be more suitable to project or team characteristics. It is time to unlearn standard practices and rely not only on their technique, but on scrum values.

This part of the book illustrates the basic scrum techniques: applying rules and positions, and using the incidents and artifacts
Introduction to the technical framework
The scrum technical framework is defined by a set of practices and rules which lead to the following agile development principles:
➢ Evolutionary product management rather than conventional or predictive management. ➢ Quality of the outcome based on the tacit knowledge of the person, rather than the explicit information reflected by the processes and technologies used.
➢ Incremental strategy for development through iterations (sprints).
It starts with the general vision of the desired result, and thereafter the functionalities are defined and details are given to create them.

Every creation or iteration process (sprint) ends with the provision of an operating part of the product (increment). Each sprint can last from one, up to six weeks, although it is not recommended to exceed one month.

In scrum, the team tracks the progress of each sprint in brief daily meetings where they discuss together the work done by each participant on the previous day and the one scheduled for the current day. Such regular meetings will be closed for a period of 5-15 minutes and will be held next to a board or blackboard with details on the activities included in the sprint and on the work pending each member of the team. This meeting is called' standing meeting,'' daily scrum,'' stand-up meeting,' and' daily scrum' or' roll call morning.'

Transparency

Transparency lets us observe all aspects of any Scrum operation. This facilitates a simple and straightforward flow of information all over the enterprise and encourages an open culture of work. Important aspects of the process must be clear to those in charge of the result. Transparency requires a common standard to identify certain elements, so that audiences share a common understanding of what is being seen.

For example:
➢ All participants must share a common language referring to the process; and

➢ Those conducting the work and those accepting the work product must share a common meaning of "Done".
➢ A Project Mission Statement that can be interpreted by all stakeholders and the Scrum Team.
➢ An open Prioritized Product Backlog of priority user stories that can be viewed by everyone, both within and outside the Scrum Team.

➢ A production schedule that can be organized through several Scrum Teams· Good visibility of the progress of the team by using a Scrum board, Burn down Map and other details radiators.

➢ Daily Stand-up Meetings were held during the Conduct Daily Stand-up process, in which all team members discussed what they had done the day before, what they intend to do today and any issues that would prevent them from completing their tasks in the current Sprint.

➢ Sprint Review Meetings held during the Demonstrate and Confirm Sprint process, in which the Scrum Team will demonstrate to the Product Owner and Stakeholders the potentially shippable Sprint deliverables.

Inspection

Scrum users have to check Scrum objects regularly and work towards a Sprint Target to identify unwanted variances. Their inspection should not be so regular that it interferes with the way of the job. Inspections are most effective when they are carried out vigorously at the point of operation by trained inspectors.

Inspection in Scrum is shown by:
➢ Use of a rising Scrum board and other knowledge radiators that display Scrum Team's progress towards completing the tasks in the current Sprint.
➢ Gathering input from customers and other stakeholders during the Build Epic(s) process, building Prioritized Product Backlogs and Conduct Release Planning.
➢ The Product Owner and the Customer inspect and approve the Deliverables in the Demonstrate and Validate Sprint process.
Adaptation

If an inspector decides that one or more elements of a process deviate beyond acceptable limits and the resulting product is inappropriate, it is appropriate to change the process or the material being handled. To eliminate further variance an adjustment must be made as soon as possible.

Scrum prescribes four formal inspection and adaptation activities, as outlined in this document's Scrum Events section:

➢ Sprint Preparation
➢ Routine Scrum
➢ Sprint Review
➢ Sprint Review

The Scrum Team is made up of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and transversal in nature. Self-organizing teams choose the best way to accomplish their job, instead of being led by others outside of the team. Cross-functional teams have all the skills required to perform the work without having to rely on others not part of the team.

The Scrum Team Model is designed to optimize versatility, innovation and productivity.

Scrum Teams produce goods in an iterative and gradual way optimizing input opportunities. Incremental deliveries of the "Completed" product ensure there is always a potentially useful version of the working product.

The Product Owner the Product Owner is responsible for optimizing the value of the Development Team product and its function. How that's done can vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the single person in charge of handling the Backlog. Product backlog management includes:

➢ Explicitly communicating Product backlog products;
➢ Purchasing items in the Product backlog to help achieve goals and missions; ➢ Maximizing the value of the work carried out by the Development Team;

➢ Ensuring that the Product backlog is accessible, transparent and open to everyone, and demonstrates what the scrum team we work on next.
➢ Ensuring the Development Team understands things to the level required in the Product Backlog.
The Brand Owner may or may have the Development Team do the work above. The Product Owner, however, remains accountable.

One individual is the Product Owner, not a committee. The Product Owner will represent a committee's wishes in the Product Backlog but those who wish to change the priority of a Product Backlog item must address the Product Owner.

To be effective the Product Owner, the entire organization must respect its decisions. Decisions made by the Brand Owner are evident in the Product Backlog material and order. No one is allowed to tell the Development Team to work from another set of requirements, and it is not possible for the Development Team to rely on what anyone else suggests.

The Development Team

The Development Team is made up of professionals working at the end of each Sprint to produce a potentially releasable Increment of "Completed" product. The Increment is provided only by Development team members.

It is created by the group of professionals who perform each sprint increment. A scrum team should have no less than 3 or more than 9 men. It is difficult to maintain direct communication beyond 9, and the normal frictions of group dynamics (which start appearing from 6 people) are more strongly manifested. In the count of number of development team leaders neither the scrum master nor the product owner are considered.
It is not an architect, builder, or analyst, programmer, and tester working group. It's a multifunctional unit, in which all members work with shared responsibility in solidarity. Many participants may be experts in specific areas, but their responsibility is to increase each sprint and the development team as a whole takes on that responsibility.

Besides self-organization and the use of agile technologies, the main responsibilities are those which make the difference between "work group" and "team."

A working group is a set of people doing a job, with a common assignment of roles, duties and following the guidelines for a method or implementation. A chain operators form a working group: although they have a common supervisor and operate in the same organization, they are each responsible for their own jobs.

A team has a shared spirit and a common purpose: to achieve the highest possible value for consumer vision.

As a whole a scrum team is responding. It works in a coherent, self-organized manner. Each manager is responsible for delimiting, assigning, and organizing activities. The leaders do it themselves.

Inside the team:
➢ Everybody knows and understands the Brand Owner's dream.
➢ Contribute to the development of the inventory backlog and consult with the product owner. ➢ Share the purpose of each sprint and the success obligation.
➢ The decision-making process includes all stakeholders.
➢ Everyone values their views and achievements.
➢ All of us know scrum.

Chapter 3
Organization

The Organization develops the Development Teams and empowers them to coordinate and handle their own jobs. The synergy resulting optimizes the overall efficiency and effectiveness of the Development Team.

Development teams have the following characteristics:
➢ They organize themselves. No one (not even the Scrum Master) tells the Development Team how to transform Product Backlog into Increments of potentially releasable Functionality;
➢ Development Teams are cross-functional, with all the skills necessary as a team to create an Increment product
➢ Scrum does not recognize any titles for Development Team members other than Developer, irrespective of the work performed by the person; there are no exceptions to this rule;·

➢ Scrum does not recognize any sub-teams in the Development Team, irrespective of different domains to be addressed as testing or business analysis; there are no exceptions to this rule; and

➢ Specific Development Team members may have specialized skills and focus areas but the Development Team as a whole has responsibility.

Optimum Development Team Size is small enough to remain agile and big enough to complete important work within a Sprint. Fewer than three members of the Development Team lower the contact and result in lower productivity gains. Smaller development teams could encounter capability constraints during the Sprint, resulting in the Development Team being unable to produce a potential redevelopment

It takes too much time to have more than nine Leaders. Large Development Teams produce too much uncertainty for managing an analytical process. The Product Owner and Scrum Master positions are not included in this count unless they perform the Sprint Backlog function as well.

The Scrum Master

The Scrum Master is responsible for ensuring understanding and execution of Scrum. Scrum Masters do this by making sure the Scrum Team adheres to the philosophy, procedures and laws of Scrum.

The Scrum Master is a Scrum Team Servant-leader. Scrum Master helps those outside the Scrum Team understand which are beneficial and which are not in their experiences with the Scrum Team. Scrum Master makes all those interactions adjust to maximize the value generated by the Scrum Team.

Functions of Scrum Masters :
1. The Scrum Master, or the meeting leader, is responsible for and guarantor of: 1. Keep the meeting before every sprint.

2. Ensure an inventory backlog is maintained by the proprietor of the company.
3. Helps maintain communication between the owner of a company and the team.

4. Ensure an agreement is reached between the product owner and the team on what will include the increment.
5. Helping the team grasp client's dream and business needs.
6. Ensuring the team performed a practical decomposition and work estimate, and considering possible tasks of study, testing, or support.
7. Ensure that elements of the product backlog to be implemented are critically calculated at the end of the meeting:

➢ The sprint's intention.
➢ The sprint backlog for all activities calculated. Scrum Master Service to the Product Owner The Scrum Master helps the Product Owner in a number of ways, including: ➢ Finding methods for effective management of Product Backlog;

➢ Helping the Scrum Team recognize the need for clear and concise product backlog items;
➢ Understanding product planning in an analytical environment;· ➢ Ensuring that the Product Owner knows how to arrange the Project backlog to maximize value
➢ Understand and practice agility; and·
➢ Facilitate Scrum activities as needed or necessary.

Scrum Master Service to the Development Team The Scrum Master serves the Development Team in several ways, including: ➢ Coaching the Development Team in self-organization and cross-functionality; ➢ Assisting the Development Team in creating high-value products;· ➢ Removing barriers to the success of the Development Team;

Facilitating Scrum activities as needed or required; and, ̈ coaching the Development Team in organizational settings where Scrum is not yet completely implemented and understood.

Scrum Master Service to the Organization
The Scrum Master serves the company in various ways including:
➢ Leading and advising the company in its adoption of Scrum;
➢ Planning implementation of Scrum within the enterprise;

➢ Helping staff and stakeholders to understand and execute Scrum and practical product development;
➢ Causing change that improves the Scrum Team's productivity; and,
➢ Working with other Scrum Masters to improve the organization's success in implementing Scrum.
What about the Managers?

Remember the project manager position does not exist in Scrum. A (ex-) project manager may sometimes step into the role of Scrum Master, but this has a mixed record of success–there is a fundamental difference between the two roles, both in the day-to-day duties and in the attitude required to be successful.
Besides the three Scrum positions there are other contributors to the product's performance, including managers. They remain valuable as their position changes. For instance:

➢ Build a business model that works and offers tools that the team needs. ➢ Assist the team by adhering to Scrum's rules and spirit. ➢ Help eliminate barriers that the team finds ➢ Make their expertise and experience accessible to the team ➢ Encourage the team to step beyond mediocrity.

In Scrum, these individuals replace the time they have previously spent playing the role of "nanny" (assigning assignments, obtaining status reports, and other types of micromanagement) with time as the team's "guru" and "servant" (mentoring, coaching, helping to remove obstacles, helping to solve problems, providing creative input, and directing team members ' skill development). Managers could be needed to change their managing styles: For example, using Socratic questioning to help the team find a solution to a problem, instead of simply deciding on a solution and assigning it to the team.

I refer you to a paper by my colleague at Scrum Training Institute, Peter Deemer, for more information about the transition from conventional management systems to a Scrum management structure.

Scrum Events

The events prescribed in Scrum are used to establish regularity and reduce the need for meetings not specified in Scrum. All events are time-boxed events that have a maximum duration for each event. Once a Sprint is launched, its length is set, and cannot be shortened or extended. The remaining events can end whenever the aim of the event is met, ensuring a suitable amount time is spent with no waste allowed in the process.

Apart from the Sprint itself, which is a container for all other events, any Scrum case offers a structured opportunity to examine and adjust something. Such activities are clearly designed to allow for critical inspection and accountability. Failure to include any of these incidents leads to less clarity and is a lost opportunity for inspection and adaptation.

The Sprint

Scrum's center is a Sprint, a one-month or less time box during which a "Completed" product Increment, functional and theoretically releasable, is produced. Sprints have stable durations at their best throughout a development effort. A new Sprint begins immediately after the previous Sprint has ended.

The primary scrum event for maintaining a consistent pace of progress is the sprint: the time-box phase with a maximum duration of 4 weeks, during which a product increment is created. The increment made during the sprint must be finished in conditions to be delivered or distributed, which is fully operational and useful for the customer.

Review Backlog & Sprint

Every day in the Sprint Backlog the team members update their estimation of the time remaining to complete their current mission.
Someone adds the remaining hours for the team as a whole after this update and plots it on the Sprint Burn down Map. This graph shows a new calculation of how much work remains each day (measured in individual hours or relative points) until the tasks of the Team are completed. Ideally this is a downward sloping graph on a trajectory to achieve "zero remaining commitment" by the Sprint's last day. Hence a burn down map is named. And while it looks good at times, it often doesn't; this is the truth of product development. The important thing is that it shows the Team their success towards their target, not in terms of how much time was spent in the past (an insignificant progress fact), but in terms of how much work remains in the future–what distinguishes the Team from its objective.

If the burn down line does not move downwards towards mid-Sprint completion, the Scrum Emergency Procedure must be followed by the team:

1. Switch working approach or eliminate impediments to increase speed.
2. Get assistance in making someone handle some of the stuff outside the team
3. Reduce the work span.
4. Sprint abort.

It is necessary for the Scrum Master to coach the Team to take early action instead of falling into a Sprint failure. Some Scrum Masters demand a squad lower its early sprint commitments. Building on success continually strengthens successful teams. Failing teams remain stuck at low speeds.

Sprint Scope
It is best to regard the sprint as the case container for all events when starting to work with scrum: the sprint scheduling meeting, the daily scrum, the sprint analysis and the retrospective.

In this way, in addition to setting a daily progress rate and visibility of the tasks (daily scrum), it also establishes a defined rhythm for monitoring the product's progress and visibility (planning and revision of the sprint), which is also the same to offer the (retrospective) style of work exposure and a point of reflection and change.

It is best to regard the sprint as the case container for all events when starting to work with scrum: the sprint scheduling meeting, the daily scrum, the sprint analysis and the retrospective. In this way, besides setting a regular rate of progress and visibility of the tasks (daily scrum), it also establishes a defined rhythm for testing the progress and visibility of the professional.

Nevertheless, it can be assumed in advanced scrum implementations that the sprint's role is only the construction of the increase, leaving out the sprint's preparation and analysis meetings, and the retrospective.

➢ The consequences of narrowing the distance, for which the team may be concerned, are: Measuring the sprint pace considering only the working time, not including the starting, closing and retrospective meetings

➢ Allowing more flexibility to conduct sprints of different durations.
➢ Distinguishing the retrospective frequency from that of sprints.
During the Sprint:
➢ No changes are made that would jeopardize the Sprint Goal;·
➢ Quality targets do not decrease; and· Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint can be called a project that has a period of no more than one month. Sprints are used to achieve something, including tasks. -Sprint has a concept of what to create, a design and a flexible plan which will direct the development, the work and the resulting product.

Sprints are limited to a calendar month. When the horizon of a Sprint is too long description of what is being built may shift, complexity can increase and risk may increase. Sprints allow for predictability by ensuring that progress toward a Sprint Target is checked and adjusted at least every calendar month. Sprints often restrict the risk of costs to one calendar month.

Cancelling a Sprint

You should cancel a Sprint a Sprint before the Sprint Time-box is over. Only the Brand Owner has the right to cancel the Sprint even though, under the control of stakeholders, the Design Team or the Scrum Master, he or she can do so.

If the Sprint Target is irrelevant a Sprint would be cancelled. This could happen if the company changes course or if market conditions or technology change. A Sprint will, in general, be cancelled if, given the circumstances, it no longer makes sense. Yet cancelation is rarely sensible due to the short length of Sprints.

When a Sprint is cancelled, all Service Backlog products that have been completed and "Completed" are reviewed. When part of the work is theoretically releasable, it is usually approved by the Brand Owner. All missing backlog things of the company are re-estimated and put back on the backlog. The work done on them is quickly depreciating and needs to be often re-estimated.

Sprint cancellations consume resources, because everyone has to regroup to launch another Sprint in another Sprint Planning. Sprint cancelations are often upsetting to the Scrum Team, and they're very rare.

Sprint Planning
Description This meeting is focused on the business goals and needs of the customer, and will decide when and how the functionality will be implemented in the next sprint.

This is a meeting chaired by the person in charge of the operation of the scrum system (Scrum Master in basic scrum, or a team member in advanced scrum) to which the owner of the product and the entire team are expected to participate.

The meeting can last up to a full working day, depending on the number or complexity of user stories that the next increment needs to include.

The conference will discuss two issues:
➢ The speed of the sprint's end.

➢ That work is required to accomplish the expected increase and how the project will be accomplished.
The meeting is arranged in two sections of a similar length, the purpose of which is to answer in each one of these questions.

Work aimed at Sprint Planning is to be done in the Sprint. The collaborative work of the entire Scrum team produces this strategy.
Sprint Preparation is time-boxed for a single month Sprint up to a maximum of eight hours. The race is usually short for shorter Sprints. The Scrum Master ensures the event is taking place and that its function is understood by the attendants. The Scrum Master is telling Scrum Team to keep it in time shell.

Sprint Planning answers:
➢ What can be delivered as a result of the upcoming Sprint in the Increment process? ➢ How will research be done to produce the Increment?

Preconditions
➢ The company has defined and allocated the available resources to execute the sprint.

➢ The highest priority consumer stories are already "prepared" in the product backlog, so they already have an acceptable level of accuracy and a clear estimation of the work required.

➢ The team has knowledge of the products used, and the company business is adequate to use its expert judgment to make estimates, and to grasp the market principles that the product owner presents.

Inputs
➢ The software backlog of groomed consumer story collection.
➢ The product already produced (except for the first sprint) in previous increments.

➢ Last sprint team pace or performance data used as a guideline for estimating the amount of work reasonably expected for the next sprint.
➢ Circumstances of the customer's business and technical requirements.

Results
➢ Performance / Backlog for Sprint.
➢ Sprint length and revisit meeting time.
➢ Goal and aim of the sprint.

Meeting format
This meeting marks the start of any sprint.
Maximum time span: one day.

Attendants: Brand creator, Scrum Master Development Team and others who are able to attend: all those who have useful information, as it's an open meeting.

This consists of two sections separated by a pause (coffee break or lunch, depending on the length). First part: What's going to be given at the sprint end?

The product owner reveals the project backlog, revealing the user stories of the highest priority that he wants and expects to build in the next sprint. If the product backlog has undergone significant changes since the previous meeting, the causes that caused them are clarified.
The goal is that the entire team knows the right level of detail and could appreciate the sprint's work.

Product Owner: ➢ Germany presents the brand backlog's user stories that are of the highest priority and can be completed in the sprint.
➢ The presentation shall be made with an appropriate level of detail to communicate to the team all the information necessary to build the increase.

Team ➢ Ask the questions and ask the clarifications needed. ➢ Offers ideas, changes and alternatives.

The team's feedback that include improvements to the product backlog or its stories about users. This meeting is a scrum hot spot to encourage team concepts cross-fertilization and add value to the product's original vision.
After the product backlog stories have been rearranged and rethought, the team determines the "sprint target," which is the term synthesizing the value that will be provided to the consumer.

With the exception of sprints devoted to cluttered mission sets, the joint development of this philosophy in the meeting is a guarantee that the entire team recognizes and shares the intent of the job. It acts as a reference factor in the decisions that the team handles itself during the sprint.

What could this Sprint do?

The Design Team is working to predict the features to evolve during the Sprint. The Brand Owner addresses the target the Sprint will accomplish and the Product Backlog things that would achieve the Sprint Target if achieved in the Sprint. The whole Scrum Team is working together to grasp Sprint's work.

The feedback to this meeting is the Product Backlog, the latest product Increment, the Development Team's estimated potential during the sprint and the Development Team's past performance. The number of items picked from the Sprint's Consumer Backlog is up to the Development Team only. Only the Development Team will be able to determine what it can do over the forthcoming Sprint.

The Scrum Team designs a Sprint Target after the Development Team estimates the Consumer Backlog products it will produce at the Sprint. The Sprint Target is a goal that will be accomplished by resolving the Product Backlog within the Sprint, and it provides guidance to the Development Team on why it is creating the Increment.

How is the chosen work to be done?

After setting the Sprint Target and choosing the Sprint Product Backlog products, the Development Team determines how this feature will be built into a "Finished" product Increment during the Sprint. The selected product backlog items for this Sprint plus the schedule to produce them is called the Sprint Backlog

Generally, the Development Team begins by developing the framework and the work required to convert the Product Backlog to an Increment working product. Research can vary in size, or under estimated effort. However, there are scheduled enough for the Development Team during Sprint Preparation to predict what it thinks it can do in the upcoming Sprint. Work planned by the Development during the first days of the Sprint.

The Brand Owner will help explain products picked from the Product Backlog and make trade-offs. If the Development Team decides it has too much or too little work, the listed Product Backlog items could be renegotiated with the Brand Owner. The Development Team may also invite others to join to provide technical or domain advisory services.

The Design Team should be able to demonstrate to the Brand Owner and Scrum Master how it plans to function as a self-organizing team to achieve the Sprint Target and build the expected Increment by the end of the Sprint Planning.

Sprint Target

The Sprint Goal is a goal set for the Sprint which can be achieved by applying the Consumer Backlog. This gives the Development Team feedback on why it is creating the Increment. It is generated during the meeting with Sprint Planning. The Sprint Target allows the Development Team some flexibility with respect to the features introduced within the Sprint.

It is keeping the Sprint Goal in mind as the Development Team works. This incorporates the features and technologies to achieve the Sprint Target. If the job turns out to be different than planned by the Development Team, they will partner with the Product Owner to discuss Sprint Backlog's reach within the Sprint.

Sprint Review

A sprint review is held at the end of the sprint to evaluate the Increment and, if necessary, to adjust the Product Backlog. The Scrum Team and stakeholders consult over what was done in the Sprint during the Sprint Analysis. On that basis, and any improvements to the Product Backlog during the Sprint, participants work together on the next things that could be done to maximize value. This is an informal meeting, not a status meeting, and the aim of the Increment presentation is to generate feedback and encourage collaboration.

There's the Sprint Analysis, after the Sprint finishes, where the team discusses the Sprint with the Product Owner. This is often mislabeled as the "demo," but that doesn't reflect it meeting's real intent.

Inspect and adapt is a key idea at Scrum. Seeing and learning what's going on, and then changing in repeated loops, based on feedback. The Sprint Analysis is an inspection and product-adaptation operation. It's time for the Product Owner and key stakeholders to learn what's going on with the product and the team (that's a Sprint review); and the team to learn what's going on with the Company Owner and the business. Consequently, an in-depth dialogue and cooperation between the Team and Product Owner to understand the situation, get advice, and so on is the most important element of the analysis. The review provides a presentation of what the Sprint team built up, but if the review focuses on simulation rather than interaction, there is a disparity.

This is a one-month Sprints, four-hour time-boxed meeting. The event is usually short for shorter Sprints. The Scrum Master ensures the event is taking place and that its function is understood by the attendees. The Scrum Master advises everyone to keep it in time-box.

The Product Owner, Team members and Scrum Master are present at this meeting, as well as consumers, partners, experts, executives and anyone else involved. The Sprint Analysis demo section is not a "presentation" provided by the team-there is no slide ware. A rule in Scrum is that you should spend as little time as possible planning for the Sprint Review; Scrum recommends no more than 2 hours. It is just a sample of what was built up. Every person present is free to ask questions and to provide feedback.

The Sprint Analysis has the following elements to it: ➢ Participants include the Scrum Team and key stakeholders invited by the Product Owner;

➢ The Product Owner describes what Product Backlog things were "Completed" and what was not "Done;
➢ The Development Team addresses what went well during the Sprint, what challenges it encountered and how these problems were solved;
➢ The owner of the company addresses the stock backlog in its present state. He or she estimates possible completion deadlines based on success to date (if necessary); ➢ The entire group works together on what to do next, so that the Sprint Review offers valuable input to future sprint planning;·
➢ Consider how the demand or potential use of the product could have changed what is most important to do next
➢ Timeline review, budget analysis, future capabilities and demand for the product's next anticipated release.

The result of the Sprint Analysis is a revised Product Backlog that determines the possible backlog items for the next Sprint. Ultimately the Inventory Backlog can also be changed to meet new opportunities.

CHAPTER 4 Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to evaluate them and create a plan for enacting progress during the next Sprint.

The Sprint Retrospective takes place after the Sprint Analysis, and before the next Sprint Planning. This is a one-month Sprints, three-hour time-boxed meeting. The race is usually short for shorter Sprints. The Scrum Master ensures the event is taking place and that its function is understood by the attendees. The Scrum Master advises everyone to keep it in time-box. The Scrum Master contributes with transparency over the Scrum cycle as a peer-team member in the meeting. The aim of the Sprint Retrospective is to:

➢ Review how the last Sprint went in terms of people, relationships, processes, and tools;· ➢ Recognize and order key items that went well and future improvements; and,· ➢ Create a plan to incorporate changes to the way the Scrum Team does its work.

The Scrum Master is motivating the Scrum Team to improve the development process and procedures within the Scrum cycle system to make it more efficient and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to improve product quality by tailoring the "Completed" concept as necessary.

The Scrum Team should have defined changes which it will introduce in the next Sprint by the end of the Sprint Retrospective. Implementing those changes in the next Sprint is responding to the Scrum Team's own inspection. The Sprint Retrospective offers a formal opportunity to focus on review and adaptation, while changes can be introduced at any time.

Is there a need for a release sprint?

Remember that a Release Sprint requirement is a sign of some weakness; the goal is that it is not needed. If required, Sprints will continue until the Product Owner decides that the product is almost ready for release, at which point a Release Sprint will be available to prepare for launch. If the team has followed good development practices with constant refactoring and integration and successful testing during each Sprint, little stabilization prior to release or other wrap-up work should be expected.

Starting the Next Sprint

The Product Owner can update the Product Backlog with any new insights after the Sprint Analysis. The Brand Owner and Team are ready to start yet another Sprint process at this stage. There's no downtime between Sprints–teams usually go from one afternoon's Sprint Retrospective to the next morning's Sprint Preparation (or after the weekend).

One of the principles of agile growth is "sustainable speed," and teams can extend the cycle indefinitely only by working regular hours at a reasonable level.
Release Sprint

Scrum's dream of success is that the product will ideally be delivered at the conclusion of each Sprint, meaning that no work is required to be done. Such as testing or documentation. Rather the implication is that every Sprint is complete; that you can either ship it, or deploy it directly after the Sprint Review.

Most companies, however, have poor development practices and are unable to reach this excellence or other extenuating circumstances exist (such as "the system broke"). There will be some remaining work in this scenario, such as final production environment integration testing, and so a "Launch Sprint" will be required to manage this remaining work. Any Scrum Team's goal is to minimize the number of Release Sprints required to complete "undone" work. Undone work tends to accumulate exponentially and is causing low quality of product.

Ending the Sprint

One of Scrum's core tenets is that the Sprint's length is never prolonged–it finishes on the assigned date, irrespective of whether the team has finished the work to which it has committed. In the first few Sprints, teams typically over-commit and fail to meet objectives.

Then, teams could overcompensate, under-commit, and finish early. But by the third or fourth Sprint, a team has usually worked out what it can achieve (most of the time) and will be more successful in achieving its Sprint targets afterwards. Teams are encouraged Choose one Sprint length (say, two weeks) and do not change it. A constant duration lets the team understand how much it can achieve, which helps in both predicting and preparing the release over the longer term. It also helps the team maintain a pace for their work; in Scrum, this is often referred to as the team's "heartbeat."

The Artifacts of Scrum

Artifacts Scrum reflect research or merit to provide clarity and inspection and adaptation opportunities. Scrum identified objects are deliberately designed to maximize the accessibility of key information in such a way that everyone has the same understanding of the artifact.

Scrum, uses two formats for recording requirements:
➢ Product Backlog
➢ Sprint Backlog

Daily Scrum

The Daily Scrum is the Design Team's 15-minute time-boxed exercise to synchronize the tasks and create a plan for the next 24 hours. This is done by reviewing the work since the last Daily Scrum, and forecasting the work that could be completed before the next one. The Daily Scrum is performed separately, and put every day to reduce uncertainty. During the meeting, the development team members explain:

➢ How did I do yesterday helping the Development Team reach the Sprint Goal? ➢ What will I do to help the Development Team reach the Sprint Goal today?

➢ Do I see any hindrance stopping me or the Development Team from achieving the Sprint Goal?

The Team participates in another of the main Scrum activities once the Sprint has started: The Daily Scrum. This is a short meeting (15 minutes or less) that occurs at a specified time and place every workday. Everybody attends the Squad.

To keep it short, it's recommended that all stay standing. It is an opportunity for the Group to report to each other and review the success and challenges of each other. In the Daily Scrum, one by one, each team member reports to the other team members three (and only three) things: (1) what they have been able to do since the last meeting; (2) what they are preparing to finish by the week.

The Development Team uses the Regular Scrum to review progress towards the Sprint Target and to check how the progress towards completing the Sprint Backlog work is going. The Regular Scrum optimizes the chances of the Development Team achieving the Sprint Target. The Development Team will understand each day how it plans to work together as a self-organizing team to accomplish the Sprint goal and build the planned Increment by Sprint's end. Often the Development Team or team members meet for detailed discussions directly after the Regular Scrum, or to modify, or replant, the rest of the Sprint's work.

Remember that the Daily Scrum is not a status meeting to report to a manager; it's time for a selforganizing team to discuss what's going on with each other, help them organize their work and maximize their chances of achieving their commitments. Everyone takes note of the obstacles, and it is the duty of the Scrum Master to help team members overcome them.

There's no argument during the Daily Scrum, only reporting

The Scrum Master ensures the meeting is attended by the Development Team but it is the responsibility of the Development Team to execute the regular Scrum. The Scrum Master advises the production team to keep the Regular Scrum within a time-box of 15 minutes.

The Scrum Master enforces the rule that the Regular Scrum includes only members of the Development Team.

Regular Scrums strengthen coordination, remove other meetings, recognize progress impediments for elimination, demonstrate and encourage rapid decision-making, and increase the awareness level of the Development Team. This is a main meeting inspectorate and adapt.

Regular Scrums strengthen coordination, remove other meetings, recognize progress impediments for elimination, demonstrate and encourage rapid decision-making, and increase the expertise level of the Development Team. This is a main meeting inspectorate and adapt.

Product Backlog

The Product Backlog is an ordered list of all that may be included in the product and is the only source of specifications for any changes to be made to the product. The Product Owner is responsible for the backlog of the Drug, including its quality, availability and ordering

A backlog of goods is never complete. The earliest implementation of it only sets out the criteria which were initially known and best understood. The Product Backlog changes as the product evolves and the world it will be used in. The product backlog is dynamic; it is constantly changing to determine what needs to be relevant, profitable and useful for the company. As long as there is a product, its Product backlog also exists.

The Product Backlog lists all features, functions, specifications, improvements, and corrections that represent the changes to be made in future releases of the product. Item Backlog items have Description, Order, Estimate and Value attributes.

The inventory backlog becomes a wider and more detailed list as a product is used and gains popularity, and the customer provides feedback. Never stop changing specifications, so a Product Backlog is a living thing. Changes in business requirements, market conditions or technology can trigger product backlog changes.

Multiple Scrum Teams frequently work on the same product together. One Product Backlog is used to characterize future product function. A Product Backlog attributes which may then use community products.

Product Backlog refinement is the act of adding details, estimates and order to the backlog products. This is an ongoing process in which the Brand Owner and the Development Team work together on brand backlog item info. Things are reviewed and updated during refining of the Product Backlog. The Scrum Team decides how and when to refinish. Normally refinement consumes no more than 10 per cent of the Design Team's energy. Inventory backlog items can, however, be changed by the Product Owner at any time, or at the discretion of the Product Owner.

Higher ordered backlog products are usually clearer and more comprehensive than lower ordered objects. More precise estimates are made on the basis of greater clarity and more detail; the lower the order, the less detail. Brand backlog items which will dominate the Development Team for the upcoming Sprint will be streamlined so that any item within the Sprint time-box can fairly be "Completed. Item backlog things that can be "Finished" within one Sprint by the Development Team are considered "Ready" for selection in a Sprint Planning. Product Backlog items generally achieve the degree of transparency through the refining activities mentioned above. For all calculations the Design Team is responsible. By helping the Development Team understand and pick trade-offs, the Product Owner may influence the Development Team but the people who will perform the work make the final decision.

Product backlog Consumer Expectations
The inventory backlog is the ordered list of everything that the owner of the product assumes the needs of the product.
It is the inventory of functionalities, upgrades, innovations and error correction that has to be integrated through the successive sprints to the product.
This reflects all that the client, the consumers and the interested parties in general and the interested parties generally expect it.

In this backlog everything that includes a task that the team will perform must be reflected. Some examples of potential inputs to a product backlog could be:
➢ Allow users to access the works published by a particular author.
➢ Rising the system installation time.
➢ Provide a job application via a web API.

The backlog to the product is never completed; it is in constant growth and development. The specifications initially defined and better understood are included at the beginning of the project, and change as development progresses.

It represents what the product needs to integrate to match the circumstances at any moment, due to its dynamic nature.
Before beginning to iterate the product, it is important to: let the owner of the company have the vision of the business target he wants to achieve and share it with the team.
Have enough customer stories to execute the first sprint inside the product backlog.

Typically the product backlog is created as a result of a brainstorming session, or "cross fertilization," or an experimentation process called "extreme Programming," where the entire team collaborates, embraces and shares the product owner's dream.

The product owner maintains the product backlog ordered according to the priority of the elements, the highest priority being those which give the product more value or they are more important for some purpose, and decide the immediate development activities.
The degree of concretion of user stories in the backlog of the company should be proportional to the priority: the highest priority should be adequate information to be able to break down into tasks and move on to the next sprint.

The product backlog items that can be included in a sprint are called "prepared" or "acting" and can be selected at the sprint meeting.
Preparing the product backlog

The tasks of prioritizing, describing and estimating the items which compose it are called "refinement" or "grooming" or preparation of the product backlog. It is a process that is carried out by the product owner and the development team in a continuous and coordinated way whenever it is timely, at any time. It does not absorb more than 10 percent of the working ability of the team.

The task of estimating the foreseeable effort for each element applies to the team members who must do the job.
Project backlog style Scrum tends to write correspondence orally or explicitly. The backlog of the project is not a list of specifications, but a team communication resource.

When using a list format, the minimum details normally included for each user story is: ➢ Functionality / requirement summary called "user story."
➢ Assigned priority.
➢ Assessment of the required effort.

And sometimes, the app story also has a secret or special identifier.
Because of the project's or team's features, additional information can be included such as: — ➢ Findings,
➢ feedback and remarks—
➢ Requirements for validation.
➢ The designated individual.
Monitoring progress toward a target

The overall work left to achieve a goal can be summed up at any point in time. The Brand Owner records this total work, at least every Sprint Review left. The Brand Owner compares this number with the work left at prior Sprint Reviews in order to assess progress in completing the expected work by the desired time for the goal. This information gets clear for the transparent to all stakeholders

Various trend-based projective methods were used to predict development, such as burn-downs, burn-ups or cumulative flows. These proved useful. Such, however, do not substitute empiricism. What is going to happen in the complex environments is uncertain. Only that which has occurred can be used to make forward-looking decisions.

Sprint Backlog

The Sprint Backlog is the compilation of Product Backlog products selected for the Sprint, plus a strategy to produce the Increment product and reach the Sprint Target. The Sprint Backlog is a Development Team estimate of what features will be in the next Increment and the work required to deliver the feature into a "Completed" Increment.

The Sprint Backlog makes all the work that the Development Team defines as important for achieving the Sprint Target clear.

The Sprint Backlog is a schedule with sufficient detail to help the Daily Scrum to understand changes in progress. Throughout the Sprint the Development Team modifies the Sprint Backlog, and the Sprint Backlog appears during the Sprint. This emergence takes place as the Creation Team consult through the strategy to learn more about the consult required reaching the Sprint target.

The Development Team adds that to the Sprint Backlog as new work is required. The projected remaining work is revised as work is performed or completed. If design elements are deemed unnecessary they will be removed. During a Sprint only the Development Team can change their Sprint Backlog. The Sprint Backlog is a highly visible picture of the work planned by the Development Team in real time.

The sprint backlog breaks down user stories into units of sufficient size to monitor progress on a daily basis, and recognizes risks and issues without complex processes of management.

Also, it is a tool for direct team visual communication.
Conditions Meet together by all members of the team .
This includes all activities defined by the sprint target team.

➢ Worked together by all members of the team.
➢ Only the sprint team can change it.

➢ Excessive tasks should be divided into other tasks. In no case can a job be of such scale as to require more than the work of one day.
➢ It's open to the entire team. Ideally, in the same physical space on a board or wall, where the team is work

Format and Support
Normal supports are:
➢ Either a physical board or a wall.
➢ There is a spreadsheet.
➢ Tool for group or project management.

And it is necessary to develop the most comfortable format according to the characteristics of the project and the team, taking into account the following criteria:
➢ Include the following information: sprint backlog, person responsible for each job, state in which it is to be completed and the remaining work time.
➢ Include only the details strictly necessary.
➢ It should be used as a way of tracking the remaining time for each task at each daily sprint meeting.
➢ Facilitate team coordination and contact on a regular and direct basis.
The team reviews the pending effort regularly for every mission during the sprint. At the same time, they trace the burn-down graph with these results, defined later, in the chapter on agile metrics. Monitoring Sprint Progress

The overall work left in the Sprint Backlog can be summed up at any point in time within a Sprint. The Development Team tracks the total work remains to estimate the probability of achieving the Sprint Target for at least every Single Scrum. The Development Team will monitor its progress by mapping out the remaining work throughout the Sprint.

Increment

The Increment is the amount of all the Product Backlog things that were completed during a Sprint and the total of all previous Sprints increments. The new Increment must be "Done" at the end of a Sprint, meaning it must be in useable condition and meet the definition of "Done" by the Scrum Team. It must be in useable condition regardless of whether the Product Owner actually wants to release it.

The increase is the part of the product generated in a sprint and has the characteristic that it can be delivered to the consumer completely finished and operational.
Prototypes, modules or sub-modules, or sections of tests or installation pending, should not be considered an increase.
Ideally in scrum: ·
➢ Each product backlog element refers to deliverable items, not "database design" style internal works.
➢ In each iteration there is an "increment."

This is however a growing exception to the first sprint, also referred to as "sprint 0." It may include "verify platform and design" goals that are important when beginning those projects; these include design or production of prototypes to test the framework or product specifications that will be used.

Taking into account the typical exception
Increment is the commodity component realized in a sprint that could be delivered: started and finished.

If the project or program needs documentation, or recorded procedures of evaluation and verification, or independence levels involving third-party systems, these must also be conducted in order to consider that the increment is "done."

Agile Development and Scrum

As the reader allegedly knows, Agile Development and Scrum are an agile process. The agile family of methods of growth emerged from the old and well-known iterative and gradual approaches to the life-cycle. We were born from a conviction that a more holistic approach to human reality–and the reality of learning, creativity, and progress in product development–will produce better results.

Agile concepts prioritize designing job software that allows people to quickly get their hands on, over spending a lot of time writing requirements up front. Agile development relies on crossfunctional teams that are empowered to take decisions, against broad hierarchies and function-based compartmentalization. It also focuses on rapid replication, with continuous feedback from customers along the way. Often when people learn about agile growth or Scrum, there is a glimmer of awareness–it sounds a lot like "when we just did it" back in the start-up days.

Scrum was strongly influenced by a 1986 Harvard Business Review article on the processes associated with successful product development groups; the term "Scrum" was coined in this paper, comparing successful development to the Rugby game in which a self-organizing (self-managing) team moves together down the product development path.

Dr Jeff Sutherland (the author of this manual) formed the first Scrum team at Easel Corporation in 1993 and Ken Schwaber formalized the Scrum system in 1995.

Agile specifications engineering user stories. User stories are used in agile approaches to describe requirements; they are a brief description of the software features as interpreted by the user (Mike Cohn, 2004).

These explain what the client or user wants to implement, and they are written using the common language of the user in one or two sentences. People's thinking is like follows organized a novel, that's how we got to understand the universe. We can understand characters, interests and intentions and stories are the best way to acquire and maintain information. We place ourselves within the protagonists and we live like the tale that tells us, we are compassionate and we take better decisions at all levels involved in decision-making, even at the developer level. Will user story should be tight, easy to memorize and write to a card or post-it (note). They are clarified by discussions with users and the identification of their related validation requirements shortly before being implemented. As the improvements in agility are welcome, it is not worth going deeper before,since at the time of its implementation these may have changed since they were written. The validation criteria allow the product owner / business user to confirm that the team has correctly collected the requirements; the team performs the appropriate tests and develops guided by tests with TDD, and finally verifies that the history has been completed. User stories are part of the capture formula of functionality described by Ron Jeffries in 2001, called the three C's:

➢ Card-Chat-Confirmation
These are an agile way to manage the specifications of the customer without having to draw up a large quantity of formal documents and without taking much time to administer them. Advantages offered by user stories:
➢ These reflect business model criteria, which can be introduced rapidly (days or weeks) being very short.

➢ Little maintenance is needed.
➢ They allow a close relationship with the client to be established.
➢ Works can be split into limited deliveries.
➢ They promote the assessment of the development effort.
➢ They are suitable for projects with dynamic specifications or which are not very simple.

The root of user stories comes from XP's "extreme Programming" or extreme programming, where clients will write user stories. Kent Beck invented this technique and it was first mentioned in his book "extreme Programming Explained" in 1999.
In most agile methodologies, the user stories are applied, becoming a very powerful element in scrum too.

CHAPTER 5
Epics, Trends, and Problems

The so-called epics are stories of high level users that are characterized by their large size, unlike stories of users who have low granularity, epics have a high granularity. It's a label that we're adding to a big story, whose effort is too great to complete in one go or in a single sprint. Epics often have an associated flow from which they can be separated into user stories, in other words, user stories resulting from an epic's decomposition are closely interrelated. As it raises its focus and reaches the moment of its implementation, the team breaks down the epic into user stories with a more adequate size to be handled using agile concepts and methods that are near (usually daily) estimation and monitoring.

The topics above the epics are those covering a series of epics and/or related user stories describing a device or subsystem. For example, in an accounting management software system, the collection of epics: "create, update, and delete the client's file". "Preparation of one time and periodic invoices," "Navigation requests and loyalty acts," "Preparation of orders," "Returns care" The topic of customer service could be referred to.

The roles are the ones below the user stories. These are the product of the team's decomposition of user stories into appropriate work units for managing and monitoring their execution progress.

Through scrum and in agile methodologies in general, all customer tales and epics can be found in a product backlog. The product backlog must be sorted by priority, and each item's level of detail must be proportional to the item's location inside the backlog. It makes no sense, on a long list, to have something with very low priority in detail, because it will probably change over the whole project, and it may not even be built. The epics are put from the middle down to the bottom of the list, where the least priority is. As we move closer to the elements of higher priority, information needs to increase, so user stories are the elements that should be at the top of the list.

Information on a Consumer Account

Necessary and optional details it is better not to follow rigid formats when deciding on what information is included in a user narrative. The effects of scrum and agility are not based on the forms, but on the institutionalization of its values and the proper execution of the company's and project characteristics. Therefore, apart from 4 fields considered essential, it is possible to include any field which provides useful information for the project.

The fields deemed necessary for proper description of user stories are: ➢ Summary: Description of the user story synthesized. The style may be open, the most suitable, but it has to address three questions: Who benefits? What is it that you want? And what good is that? Mike Cohn advises following the next trend that ensures high-level and not too detailed explanation of the functionality:

➢ ID: User history user identifier, special for feature or task.
o I want[ feature] to be able to[ profit] as[ user role]

➢ Estimate: Estimation of the effort required to implement the user story in an ideal time. Depending on the suitability of the team, development units, known as story points (these units reflect the estimated development time / person stipulated at the start of the project) may also be used.

➢ Priority: method of priority setting that enables us to decide the order in which user stories should be enforced.
Depending on the type of project, the team's internal organization and the organization's structure and procedures, certain areas may be recommended, such as:
➢ Title: app tale concise heading.

➢ Criteria for validation: approval checks accepted with the customer or user. Those are the benchmarks the code needs to clear in order to mark the user story implementation as finished.

➢ Value: value (usually numeric) that gives the client or user a user story. The team's goal is to maximize the value and satisfaction experienced by the customer in every that is, repetition. Together with the calculation, this area will help to decide the priority the user stories should be implemented with.

➢ Dependencies: a user story does not depend on another story, but it is often important to establish a connection between them. In this region, we'd point out the identifiers of the other stories it relies on.

➢ Person assigned: the person who can execute the user story when we want to propose. Note that the self-managed team in scrum is the one that actually distributes and therefore assigns the tasks.

➢ Termination Requirements: The concept of finished / recorded includes the requirements or activities required to finish a user history (developed, checked, reported...), decided upon by the team and the product owner.

➢ Sprint: Having the sprint number where the story is likely to be rendered might be helpful for the product owner's organization.

➢ • Risk: technological or functional risk relevant to user story implementation. ➢ Module: device module or component it belongs to.
➢ Remarks: enrich or explain any knowledge or use which may be useful.

Mike Cohn insists that while user stories are versatile enough to explain most systems' functionality, they are in no way suitable for it. If a need has to be presented in a way different from a user story for any cause, it is recommended that it be done.
For example, screenshots usually explain the layout of the screens, so this is the best way to convey the design we want to offer to a specific application.

Validation Criteria

After 50 years of software engineering history, we have come to the conclusion that the validation criteria, which are converted into tests, are an excellent language for explaining functional requirements and that is why they take on great significance in user stories.

The SMART approach is used to measure the quality of an acceptance condition, in which the following criteria must be met to the maximum extent possible:

➢ S–Specific
➢ M–Measurable
➢ A–Achievable
➢ R–Relevant
➢ T–Time box

We are published as soon as in the sprint preparation the user stories which are likely to enter a sprint are collected and refined. Acceptance criteria help the development team understand the product's operation so they can measure the scale of the underlying story, and when the team is in the development phase and the developer has to make a decision, He'll take it as suitable. Next, thanks to these acceptance criteria, the product owner tests in the sprint analysis if each of the user stories can be considered as completed and finished.

Criteria for approval can be written in natural language; just as those are expressed by the product holders. Another alternative is to write them using Behavior Driven Development (BDD) own behavioral analysis technique or gherkin, a specific language created specifically for representations of software behavior. The Gherkin Syntax is as follows:

➢ Scenario I d: Number (Example 1, 2, 3 or 4), describing the story-related scenario. ➢ Scenario Title: Describes the context of the scenario which determines a behavior.

➢ Context: Provides a more detailed description of the circumstances under which the scenario is set.
➢ Event: Represents the behavior the user performs within the scenario-defined context. ➢ Result / Anticipated behavior: The result is the conduct of the device in that particular case, given the context and the intervention performed by the user.
User story content In 2003 Bill Wake created a system called INVEST to ensure accuracy when writing stories about users.
The tool is used to test the consistency of a user story by analyzing whether it fulfills a number of characteristics:

➢ I- Independent
➢ N- Negotiable
➢ V- Valuable
➢ E- Estimable ➢ S- Small
➢ T-Testable

Independent

It is beneficial that one can schedule and execute each user story in any order. Hence the prepared stories should be entirely independent (which encourages the team's later work). The fact that the dependencies between user stories can be minimized by combining them into one or separating them differently has to be highlighted.

Negotiable

A user story is a short description of a need without the specifics. Stories must be negotiable, because their information must be decided during the conversational process with the company or the user. User stories with too many specifics should therefore be avoided, as this would restrict the discussion about them.

Valuable
A customer story has to be beneficial for the developer or the user. One way to make a good story is to write it down yourself.
Estimable

A good user story must be calculated with reasonable precision to help organize and prepare its execution by the client, consumer, or product owner. The calculation will typically be carried out by the work team and is directly related to the scale of the user story (a large user story is more difficult to estimate) and to the understanding of the identified need by the team (In the case of lack of knowledge, more conversational phases will be required)

Small
User stories should at most cover a couple of weeks of work. Even teams do limit them to days / person. A brief description helps reduce a user story size and encourages its estimation. Testable

The user stories (confirmation process of a user story) should be checked. If the developer or user does not know how to check the story of the user it means that it is not completely obvious or that it is not worthwhile. If the machine is unable to check a user narrative, it will never know whether it is over or not.

There are companies that have produced their own cards like these from Brain trust that, apart from providing a professional appearance, provide all the information needed and each field has enough space to fill in.

Good practice advice: ➢ Just write "what" stories, forget "how."
➢ Do not write an exhaustive summary, just the right description. ➢ Write down and be clear enough the validity criteria. ➢ Estimate all the stories; it can create false perceptions not to do so.

➢ Do not trust all of the card information; sometimes it's a good idea to have an external documentation such as a wiki.
➢ Never send the finished story when it's "nearly"

Prioritization of User Stories
➢ Benefits of implementing the function.
➢ Failure or loss causing postponement of feature implementation.
➢ Problems of execution.
➢ Consistency with the needs of companies.
➢ Price difference for competitive products.

Although all user stories may be relevant, in order to focus effectively on the job, it is necessary to highlight those that give greater value to the system, so user stories should be given priority. They must be given a value by the owner of the product; this value is included in the prioritization method and will essentially be dependent on the following variables:

One thing to note is that the concept of "value" will differ for each of our clients. Beyond a high, medium or low priority classification system, use of a qualitative scale, one that has an intrinsic meaning, is highly recommended. This is the case with the Moscow strategy, in which the consumer in charge of assigning the priority is aware of the real impact of his choice will produce. This method was first described in the book Case Method Fast-Track: A RAD Approach by Dai Clegg of Oracle UK Consulting, 2004. The aim is to create a common understanding between the customer and the project team, specifically regarding the importance of each user story. The ranking is as follows:

M-MUST HAVE (it is necessary): the features must be incorporated in the solution, otherwise this will fail or the solution cannot be regarded as a success.

S-SHOULD HAVE (recommended): the functionality should be incorporated in the solution, since it is a high priority feature. The solution is expendable, if it does not exist, it does not fail, but legitimate reasons for failure to execute it will exist.

C-COULD HAVE (may be incorporated): it is a desirable feature; thus, it would be useful to have this functionality included in the solution, depending on the time and budget of the project.

W–WILL NOT HAVE (we don't want it... maybe in the future): at the moment this is a very low priority or discarded feature, but it may be relevant in the future. Subsequently it may switch to one of the previous states when it becomes significant.

It is necessary for the client to differentiate between priority and value. It may be that a user story does not have any interest for the client or customer, but it is absolutely necessary, and therefore of high priority. For example, the infrastructure required to implement a program does not bring value to the client itself, but the solution created cannot be implemented or performed without it.

The Agile Manifesto

In March 2001, 17 software experts, proponents of process-based production models, were invited by Kent Beck, who had published the book explaining the new technique for Extreme Programming a few years earlier (Beck, 2000).

They were meeting in Salt Lake City to discuss the processes that programming teams used.

At the conference, the term "Agile Methods" was coined to describe those emerging as an alternative to traditional methodologies: CMM-SW, (precursor to CMMI), PMBOK, SPICE (initial project of ISO 15504), which they considered to be overly "severe" and rigid due to their normative character and strong dependence on comprehensive pre-deviation

The meeting participants outlined what was considered the "Agile Manifesto" in four postulates, which are the principles on which those approaches are based.
Until 2005, extreme viewpoints were more prevalent among advocates of process models and agile models, more concerned with disqualifying the other than understanding their respective methods.

We respect individuals over processes and resources, and their interactions. This is the manifesto's most important postulate.

The procedures of course help to do the job. They're the guide to operations. Technologies improve performance, but there are always activities that require creativity and that require people to contribute and work with the right attitude.

The process-based development aims to ensure that the consistency of the outcome is a consequence of the "explicit" know-how deployed in the processes, rather than the information given by the executing persons. However, the systems are only an aid in agile development processes. A guiding aid to the job, The severe defense of the processes leads to the assumption that they can produce exceptional results with mediocre people and the fact is that when creativity and innovation are required this theory is not valid.

We trust software that works over essential documentation.

Being able to anticipate how the final product would work, studying previous designs, or already developed pieces, provides stimulating and enriching input, producing concepts that could not be conceived at first, and that could hardly be included in the drafting of a detailed specifications document at the project start.

The agile manifesto does not consider the report as useless, only unnecessary. The records support evidence, facilitate knowledge transfer, record historical information and are essential for many legal or regulatory issues, but their importance should be substantially less than the final product.

In addition to hiding the complexity of the contact with the product, if the company and the teams communicate through records, they create bureaucratic barriers between departments or between people

We prioritize cooperation with our customers over contract negotiation.

Agile methods are demonstrated for the continuously evolving goods. In this type of product, it is not possible to define how the final product should be in a closed requirement document, and it is more acceptable to continue to receive input, and in tandem with product development, redefining and strengthening parts specifications not yet produced in keeping with the lessons learned from previous iterations provided to stakeholders.

The goal of an agile project is not to monitor the implementation to ensure the preparation is met, but to provide the product with the highest possible value on a continuous basis.
Therefore a partnership relationship and continuing cooperation with the company is more fitting than a formal delimitation of responsibilities.
We value the response to change over following a schedule
Design goods according to unpredictable requirements, where change and rapid and continuous development are inevitable, sensitivity is much more important than monitoring and assuring plans. The core principles of agile management are anticipation and adaptation, which vary from orthos. The 12 Principles of the Agile Manifesto
The agile manifesto establishes these 12 principles after the postulates of those four values on which it is based:
1. Our highest priority is to please the customer by providing useful software. 2. Welcome demands that change, even late in growth. Agile methods change harnessing for the competitive advantage of the company.
3. Often produce working apps, from a few weeks to a few months, with a preference for the shorter timescale.
4. Throughout the project business people and developers have to work together every day. Create projects around motivated people. Give them the atmosphere and support they need, and give them confidence to get the job done.
5. Face-to-face communication is the most effective and efficient way of conveying information to and within a development team.
6. The primary measure of progress is job software.
7. Foster sustainable development by agile processes. The supporters, developers and consumers should be able to keep pace indefinitely.
8. Continuous emphasis on technical excellence and good design increases agility. 9. Simplicity-the art of optimizing the amount of work that has not been completed-is important.
10. Out of self-organizing teams emerge the best systems, specifications and designs. 11. The team is focusing on how to become more efficient at regular intervals, then tuning and changing its behavior accordingly.
Used at major companies

Today, scrum is used by companies large and small, including:
➢ Yahoo!
➢ Microsoft
➢ Google
➢ Lockheed Martin ➢ Johns Hopkins APL ➢ Siemens
➢ Nokia
➢ Motorola, SAP
➢ Cisco
➢ GE
➢ Capital One
➢ US Federal Reserve

Teams using Scrum show significant improvements in both efficiency and morale, and in some cases total transformations. This is important for product developers–many of who have been burnt by the "Month Club Management Fad" –.this is significant. Or to put plain: Scrum is just simple and powerful.

The Agile Manifesto

The "Agile Software Development Manifesto" was created by members of many of the emerging "agile" systems such as Scrum, DSDM and XP in February 2001. The manifesto is a collection of 4 values and 12 principles which defines "What Agile means."

The Agile Value
1. Individuals, and method and device experiences
2. Working applications over critical data
3. Consumer trust over contract negotiation
4. Reacting to change following a strategy
The Principles of Agile

1. Our highest priority is to please the client by providing useful applications at an early and continuous time.
2. Welcome demands that change, even late in growth. Agile methods improve harnessing for the competitive advantage of the company.
3. Sometimes produce working apps, from a few weeks to a few months, choosing the shorter time-scale.
4. Throughout the project business people and developers have to work together every day. 5. Create projects around motivated people. Offer them the resources and support they need, and give them confidence to get the job done.
6. Face-to-face communication is the most effective and efficient way of conveying information to and within a development team.

7. The primary measure of progress is job software.
8. Foster sustainable development by agile processes. The supporters, developers and consumers should be able to keep pace indefinitely.

9. Continuous emphasis on technical excellence and good design increases agility.
10. Simplicity-the art of minimizing the amount of work that is not completed-is important.
11. Out of self-organizing teams emerge the best systems, specifications and designs.

12. The team focuses on how to become more successful at regular intervals, then tunes and changes its behavior accordingly.
Agile Methods

In fact the term Agile refers to a philosophy, not to a particular technique. There are many approaches that can be used under the agile paraglide, and sometimes contradictory ones. It includes;

➢ Agile Unified Process,
➢ Behaviors Driven Development (BDD),
➢ Crystal Clear,
➢ Dynamic Systems Development Method (DSDM),
➢ Extreme Programming (XP)
➢ Feature Driven Development (FDD),
➢ Kanban
➢ Lean Development,
➢ Rapid Application Development (RAD),
➢ IBM - Rational Unified Process (RUP),
➢ Scrum,
➢ Test Driven Development (TDD),

Key Points
There are four key points in general across all the above approaches.
1. Iterative design of development.
2. Continuous interaction with stakeholders.
3. Aims at device quality and reliability.
4. Short development cycles (up to one month) allow producing software regularly.

It shows that an agile approach is suitable in situations where the outcomes are not (or cannot be known) in advance and where the transmission of the results cannot be fully controlled Critical Success Factors

The successful application of an agile approach depends on an organization's relative maturity with respect to Customer Engagement, Personnel Capital, Technology and Operation. Such steps are laid down as follows:
➢ Customer Engagement–Brand owners engaged in day-to-day operations by teams identifies

specifications, drive task prioritization and have authority delegation to make decisions.

➢ Staff–have experience in an agile system, are trained in the Standard Operating Environment (SOE) toolsets, have an understanding of the underlying data and technical infrastructure and are familiar with process development, testing, configuration and release.

➢ Technology–a robust and well-documented technology framework with clearly defined levels of ownership and operation, offering discreet development, testing and release environments that are sized and maintained for project execution, and managed by comprehensive setup and release management.

➢ Processes–business processes exist for all domains, with specified cross-stream interdependencies and accepted level of service, and specific business ownership and authority delegations established.

Common Misconceptions
Agile means different things to different people, being a generic term. I should therefore explain some of the more common misconceptions concerning Agile, before we go much further.

➢ Agile is ad hoc, without control of the process: First of all, Agile is not a lack of procedure. Agile offers a variety of formal frameworks and approaches for guiding work practices, customer engagement and models of management. On the other hand, Agile is not about blindly following the "agile" practices and procedures recommended. Agile is about using the common sense as defined by the current situation and influenced by the agile theory to implement processes.

➢ Agile is quicker and/or cheaper than alternative frameworks: Agile isn't much faster, or cheaper. Put another way, in most situations, by switching to an agile strategy, you cannot get substantially more effort out of your staff.

➢ While there is an overall gain in productivity when using agile techniques, well-managed Agile and non-Agile teams are about to produce products and services at the same time and effort.

➢ Agile teams don't prepare their work or write documents: Agile isn't an excuse to avoid proper preparation or documentation writing. It is an on-demand approach, or Just-In-Time, that encourages continuous planning and documentation, but only when needed for specific customer needs. This allows clients and teams to assess whether the preparation or documentation adds value to the process or product. It offers an opportunity to highlight important documents and delete anything that is not useful.

➢ An Agile project never ends: while this may be true in some cases, the benefit of Agile is that while the Client continues to gain business value, work will continue, and that value is worth more than the cost of developing it. Most ventures have a point of diminishing returns in any industry. This is the perfect time to end an agile project.

➢ Agile works only for small organizations: Agile operates for all types of programs, teams and organizations, not just small projects. That's not to say it'll fit for all organizations, but scale is seldom a factor. Large and complex projects and organizations are often excellent candidates for agile development, where pre-knowledge of all the criteria of your customers is difficult or impossible.

➢ Agile is inefficient without strategic planning: this means that your client knows in advance the specifics of all their specifications. If this is valid then do comprehensive advance planning by all means. In fact, however, this is unusual, and usually results in the greater' waste' of having done design and development work, which was essentially unnecessary. Agile Business Management emphasizes minimal strategic preparation, ensuring everyone works towards the same target, and reducing the possibility of miscommunication.

➢ At last, Agile isn't the solution to all of the problems. It is a change in mindset and community that comes with its own collection of benefits and questions.
Specifications Under Agile?
Contrary to common belief, having a good specification is very critical before beginning an agile project. A project must construct the specification (or backlog in agile terminology);

➢ Reduce risk & uncertainty
➢ Improve decision-making and align with long-term goals.
➢ Improved cost reduction (including employee hiring).
➢ Prioritizing research and information Collection.

Beginning the Process

In comparison to conventional waterfall approaches, an agile project's development process is very short; typically no more than 1 or 2 days, and the entire team should be available at the start. The customer should be made fully conscious of their position during the time. The model should include the following;

➢ Question statement that needs to be addressed
➢ Desired business objectives, outcomes and benefits for this project
➢ Identified key stakeholders / High-level business criteria
➢ Architectural and technical scope
➢ Testing Requirement

Outcomes
The results of the start of the project, or Sprint 0, are:
➢ The team should be identified and put together.
➢ If not part of the team, identify and train the owner of the company.

➢ Build the backlog of the product in small detail. Allowing customers to build up the product specifications slowly throughout the process.
➢ Estimate the backlog of the drug.
➢ Schedule sprint length, from 1 day to 4 weeks in any position. Every sprint is supposed to achieve something releasable. Quick sprints will cut back on overtime.
➢ Add any team trainings as activities to the backlog.

CHAPTER 6
Agile Calculation and Estimate Why Measure?

Data is the raw material for decision making, and the one which can be quantified offers conditions for accurate management and monitoring.
From the basic programming level to the most general organizational management level, there are three scales or zoom levels which can be used to calculate the work:

➢ Design and Technical solution management.
➢ Management of the enterprise.
➢ Company management.

For example, in the first one, the proportion of polymorphism can be calculated in the code of a program, in the second, the percentage of the project plan implemented, and in the third, the degree of job satisfaction.

This text covers the agile measurement in the project scope, although the general considerations Of this introduction are common to all three.

Criteria for Designing and Applying the Metrics

The Fewer the Better.
➢ It's costly to calculate.
➢ This requires complexity to calculate.
➢ The scrum team's task is to provide the best value / cost ratio.

Issues to be asked before an indicator is tracked and measured:
➢ Why?
➢ What is this measurement's value?
➢ If omitted, how much interest is lost?

The aim of scrum is to continuously produce the highest possible value, and the key issue for incorporating indicators into project management is:

What does the use of the indicator contribute to the client's value which the project provides? Is the indicator suitable for achieving the intended purpose?
Measuring is not an end in itself or should not be.
What's the Finish?
Meeting goals, improving efficiency of the departments, forecasts...?

Let's be serious. If you are not persuaded after evaluating it, if you choose not to include or alter an indicator: you are the boss, you agree to do so.
Is the hardest part to decide what to weigh. In the best-case scenario, misguided decisions will only lead to avoidable expense of managing; but they can also exacerbate what is meant to improve. Example: Measuring programming job efficiency
The XYZ Company has implemented standard software engineering productivity metrics: ➢ LOC / hour: total number of new or updated lines of code in each hour.
In order to increase efficiency, the performance paid to programmers was related to the results of this measure, so that more lines of code were generated without increasing the output. In order to avoid being a "hollow" increase in lines of code or an increase in the number of errors to be coded more efficiently, the metric also includes:

➢ Check Defects / KLOC
➢ Compile Defects / KLOC

➢ Total Defects / KLOC to ensure that the number of errors in the code does not increase, and=' appraisal time ' metrics to measure the time and cost of creating and conducting code reviews.
And for fear that the measurement system may prove to be excessively expensive, quality cost indicators (COQ) are included, which calculate the evaluation times and contrast them with the changes in times removed by reduction in failure.

What are we going to measure being a valid predictor of what we want to know? Relatively mechanical programming tasks exist, more geared towards integration and configuration than towards the development of new systems.
To those, considering output as the volume of work done per unit of time may be reasonably accurate.
However, for the latter it is more appropriate to consider the sum of Integrated Value per production unit; expressed in hours, iterations or feature points.

What do we want to know: the number of lines supplied to the customer, or the value? Are they all connected to each other?
Can the value given to the Customer be objectively measured?

There are many parameters in our work environment which can be calculated using objective and quantifiable criteria: task time, delta and interrupt times, number of feature points, instability specifications, coupling ratio, and number of errors per code line...

Are we still calculating this simply because the measurement is quantifiable and easy? Should we measure the number of lines people develop when we want to really know the value of their work?
Are we still calculating this simply because the measurement is quantifiable and easy? Should we measure the number of lines people develop when we want to really know the value of their work?
Is it the same as we try to measure: ease of use, ease of maintenance, versatility, portability, complexity, and so on?
Speed, work and time The three variables that make up the formula of speed in agile project management are speed, work and time, describing it as the amount of work per unit of time. For example, pace= work / time can be said to be 20 points per week or 80 points per sprint for a team of 4 members.
Time The agile development uses two potential strategies to sustain a consistent pace of progress: iterative increase or constant increase.

Progress by iterative steps keeps pace by relying on the pulses of the sprint. This usually uses sprint as a unit of time for this purpose, and communicates the pace as work or activities performed in a sprint.

Note: Technical scrum uses iterative increment, thus describing pace as the amount of work done in a sprint.
Progress through a steady increase allows a consistent forward flow without bottlenecks or dead points. There are no sprints, and therefore the time units are days, weeks, or months, so the pace is measured in "points" per week, day, or month.

Real time and Good Time

An important remark: the difference between' real' time and' ideal' time. Real time is the job hour. Equivalent to day of work.

The actual time in one week (five working days) for a team of four individuals with an eight-hour working day is: 4* 8* 5= 160 hours

Nevertheless, ideal time refers to working time under ideal conditions, that is, excluding everything that is not simply "work," if there are no interruptions, delays or attention to non-task issues and the individual is in his best conditions of focus and availability.

Typically, the optimal time is used in calculations, such as unit of work or required effort. Ex: "This job has an ideal size of 3 hours"
It is a term close to what PSP1 calls "Delta Time" as the working time component which is in fact efficient working time.
Ideal time is not a unit of time but requires work or commitment.
Work measuring the work may be needed for two reasons: to document the work already done or to predict what should be done in advance.
In both cases a unit is necessary, as is an objective quantification criterion.
Work already done
It isn't especially difficult to measure the work already done.
It can be done with product-related units (e.g. code lines) or with the resources used (cost, working time...).
To calculate it, you just need to count what the device used have already done: lines of code, task points, working hours, etc.
Agile project management does not assess the work already done to evaluate job progress by excluding it from the time planned.
Agile management for the work done, but for the pending, does not assess the degree of success of the project. It results in a better indicator of actual progress
Many business processes in the company may need to monitor the effort spent, so it needs to be registered, but not used to measure the success of the project.
Work to be done
Scrum tests pending work to:
➢ Estimate the effort and time taken (tasks, user stories or epics) to do a job. ➢ Decide project success, especially in each sprint.
It is a dubious undertaking to evaluate exactly, quantitatively and objectively the research that will need to construct a requirement.

The work required to satisfy a requirement or user story cannot be completely expected, as the functionalities are not specific realities of the solution, and the difficulty of the calculation would make a metric too heavy for agile management if it were feasible.

And since it's not possible to estimate the amount of work in a requirement correctly, you can't know how much time you're going to need because besides the uncertainty of job these other uncertainties are inherent in "time":

➢ Talking about the quantity or quality of work performed by an individual per unit of time is not practical, because the differences between people are massive.
➢ In different situations, the same task performed by the same person can require different times
On these premises:
➢ It is not possible to estimate reliably, neither the quantity of a requirement's function, nor the time required to do it.

➢ The sophistication of estimating techniques is increasing exponentially to the point that: we are attempting to improve the reliability and precision of the tests. Estimated job size increases.

The agile management strategy used is:
➢ Function with preliminary estimates.
➢ Estimate with the methodology of "expert judgment."
➢ Divide activities into smaller subtasks if forecasts surpass normal ranges or a real-time day.

Working Units A task can be dimensioned by measuring the product being created, such as the standard feature points or COCOMO; or the time required to complete it
"Points" are often used as units of work in agile management, using denominations as "points of story" or simply "points."
The "Story Point" unit of Extreme Programming is described as the amount of work done on an "ideal day"
-organization institutionalizes its working metric, specifying the name and the units according to its circumstances and requirements, so that it can identify its unit, its "point".
You usually employ it as the relative size of common activities.
Ex: The internet sales system team may decide that a "frame" is the size of a "user's invoice list.” Base on the optimal amount of time needed for the job.
Ex: A team will decide that the work done in ideal 4 hours is a "level."
It is crucial that the metric used, its context and implementation type is consistent in all the organization's measurements and known to all people:

It must be an institutionalized working process .
Speed
Pace Speed is the amount of work conducted over a period of time.

Speed in technical scrum is the amount of sprint work that the team does. A speed of 150 points, for example, means that the team performs 150 points of work in each sprint.

While operating in advanced Scrum implementations, sprints with different durations can be done or not always with the same number in the team, the speed shall be expressed, indicating the time unit and, where applicable, referring to the entire Team, or the average per person. For instance: "Team average speed is 100 points a week." "Team individual average speed is 5 points a day."

Measurement : Uses and Tools
Service Map of applications and devices.

The "burn up" or product map is a planning tool for product owners that visually show the product's predictable progression.
Plan the construction in time, based on the work team's pace.

The projection is carried out on a Cartesian diagram that reflects the projected effort to create the product backlog's different stories and on the abscissa axis is the time, estimated in real time or in sprints.

Example Conventions used by the team: ➢ Job estimation unit: scrum points. ➢ Working with fixed length sprints is planned: monthly (20 working days). ➢ The team is made up of 4 people and achieves an average sprint speed of 400 points.

The line reflecting the anticipated pace of progress is plotted on the graph, according to the team's average speed (400 points per sprint in this example).

With a negative and positive outlook it is also advisable to track the pace of progress. These are drawn based on the pace with the worst and best results obtained in previous sprints, or set a margin according to the criterion of the work team (e.g. +-20 per cent).
In this case, the owner of the software plans to release version 1.0 when the first four stories are available which have an approximate effort of 950 points (150 + 250 + 250 + 300).

To map the forecast each version is put in the location corresponding to the measured effort to build all the stories it contains on the vertical axis.
In the example below, the location of version 1.0 would be on the ordinate axis value 950:

The break points that mark this location on the horizontal axis with the team's speed lines (pessimistic, rational and optimistic) are the date or sprint in which the version is expected to be completed.

This tool projects the product backlog forecast which is a living document whose evolution dictates the product's future development.
Poker planning: An agile strategy.

It is an agile activity to conduct the meetings which estimate the effort and length of tasks. The strategy game was designed by James Grenning to avoid lengthy discussions that do not conclude with clear conclusions.

The original Grenning pattern consists of 7 cards, with 1,2,3,5,7,10 and infinity numbers (Grenning, 2002).
The operation is very simple: each participant has a set of cards, and all face up the combination which adds the estimated effort in estimating each task.

If this is deemed to be more than x ideal hours (the average size accepted for a story by the team), the "all" card will be removed.
Tasks exceeding the maximum size must be disassembled into smaller subtasks.
Each team or company can use a set of cards with the correct numbers to the unit of effort they are working with, and to estimate the maximum size of the mission or story.
Version: Fibonacci sequence
This version, which consists of using only Fibonacci sequence numbers, was built based on the fact that increasing the size of the tasks increases ambiguity and margin of error, so that: ➢ The card game consists of Fibonacci numbers in succession.

➢ The calculation is not rendered by raising multiple cards in order to compose the exact figure (as in the original version of Grenning), but by facing the card with the estimate nearest to it.

Operative
➢ Every person in the meeting has a set of cards.

➢ For each task (user story or functionality, depending on the level of requirements to be estimated), the client, moderator or product owner exposes the description using a time to no exceed.

➢ Another extra time is set for the customer or product owner to answer the team's possible questions.
➢ Based on the calculation method used, each participant selects the card, or cards representing his prediction, and distinguishes them from the rest face down. ➢ When everyone has picked them, they're shown to be faced.
➢ If the calculation is "infinite," the function shall be divided into smaller subtasks, beyond the defined maximum limit.

➢ If the figures are very specific, who assumes responsibility for handling the meeting, with its management requirements, and depending on the characteristics of the project, can choose from: staff, meeting, number of things to be assessed...

o Asking people for extreme estimates: Why do you think so much time is needed? And why do you think so little time is needed? The team must repeat the prediction, after learning the reasons.

o Setting aside the estimation of this mission and resume those which have remained pending at the end or at another time.
o Asking the consumer or product owner to decompose the functionality and analyze each of the functionalities that arise.

o Taking the lowest estimate, the best or the average.
This mediation protocol avoids the jams of circular debate between different implementation options in meeting, it lets all the participants involved, it reduces the estimate period of a specification from fifteen to thirty minutes to a few minutes, it encourages consensus-building without dispute, and it is also enjoyable and energizes the meeting and the team.

Advanced Scrum

Information in continuous evolution Agile method systems do not hit ICT projects as a "thesis" of information, but as an "antithesis" to the methods of project management that were traditionally established by Software Engineering.

To examine what this means, the reasons why IT projects adopted agility at the end of the last century and their discrepancies with process engineering need to be put into perspective; not from the actual procedures, but from the concepts on which they are based, and recognizing their strengths and weaknesses in agility.

The key to making the transition from technical management to expert management is to get a view of the motives and values of each practice, beyond the concretion of a blueprint. That is, switching from management based on applying policies and procedures to management based on applying our knowledge of ourselves.

The dialectical model starts its development by questioning understanding, following a dialectical pattern of: thesis, antithesis and synthesis.

The dialectical pattern can be described in a schematic way as the flow of advance which opposes an antithesis to a previous conception, understood as a thesis. The antithesis reveals the problems and inconsistencies of the thesis and a third phase, called synthesis, a resolution or a new understanding of the question, and emerge from their conflict.

In this way, the strategy based on attempting to solve the complexities of software projects with process engineering was the first study to respond to the "information crisis," and its antithesis has highlighted its problems and contradictions: agility.

In 1968, the issues of software programming were discussed at the first software development conference held by the NATO organization, and the word "information crisis" was coined to refer to them.

The conference's conclusion (Bauer, Bolliet, & Helms, 1969) was the need to establish a scientific discipline that, as in other fields, permitted a structured and quantifiable systematic approach to the development, operation and maintenance of software systems, that is to say the application of process engineering to software. Software Engineering was born.

The first software engineering approach (thesis) was focused on two pillars:
➢ Production engineering
➢ Predictive management:

The first to effectively contrast the basic principle of quality in industrial production environments: "the quality of the outcome depends on the efficiency of the processes used."

The second one to make sure goals and priorities are fulfilled.
While this approach had developed and was refined through various process models and project management information bodies (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE, SWCMM...) doubts arose in the software industry and this technique was challenged.

Is predictive modeling appropriate for any given project? Are the performance criteria always ensuring the times, costs and pre-established functionalities are met?

On the one hand, a new type of project emerged whose purpose was not to create a previously defined and entirely designed program. Drawing a closed plan from the start wasn't practical for this new type of project.

These are ventures in which it is not interesting to know if the final device will have 20 or 200 functionalities, or to know how these will be in detail: its purpose is to bring an innovation on the market as soon as possible, and the dream and meaning will grow continuously from that moment on.

On the other hand, it was also questioned whether the software could be generated with patterns of industrial processes, and it was begun to agree that the tacit awareness of the individual who knows it could be more important in the quality of the result than the know-how contributed through the process and the technology employed.

From the start of agility in the mid-90s to 2005-2010, there were numerous extreme positions between proponents of process models (thesis) and proponents of agile systems (antitheses) who were more likely to focus on disqualifying the others than on updating and testing the processes.

Examples of that stress are:
"The distinction between a bank robber and a theorist at the CMM is that you can bargain with the robber"...

"The evaluation in CMM depends more on a good paper presentation than on the actual quality of the software product. It has more to do with blind follow-up of a technique than with the development and production of a system in the technical panorama."

"If you ask a typical software engineer if you think CMM can be applied to agile methods, they will either answer with a surprise look or a hysterical laugh."
CHAPTER 7 Dialectical Spiral of Knowledge Technical knowledge is constantly evolving, because the world in which it is implemented is in perpetual motion, and also because it is still possible to improve.

The implementation of new methods, processes or models produces its own antitheses by exposing the shortcomings, inconsistencies and points of improvement, and the confrontation of both leads to a synthesis that will become a new thesis whose subsequent use will create its antithesis, creating a spiral of continuous evolution of knowledge through this dialectical pattern.
The speed of advancement on this dialectical spiral had allowed professionals to perform in nontechnical disciplines and in previous generations with the knowledge acquired during their entire professional career. This isn't possible today, however, especially in the IT field.

There are no processes, procedures or working models that will guide us for a long time with solvency but experience of evolution. This is a key consideration in the knowledge base of Scrum Manager, since it does not describe a fixed model, but rather an up-to-date knowledge base for expert management rather than technical management. It is based on the recorded and expert requirements of the manager, rather than the application of practices and process.

Company as a Network

Organizations are not composed of a variable number of separate divisions or regions. They are structural facts, and their efficacy is proportional to the unity of the working methods employed in the various departments. Considering scrum as the structure of the project management working rules, the procedures of which can be implemented without repercussions for the rest of the project management sector, whose activities can be implemented without consequences, produces minimal and even counterproductive results in the rest of the organization.

For example, in an enterprise where management is focused on industrial production models, and therefore the engineering area works with process-based models with sequential or cascade life cycles, the implementation of agile project management practices would create friction.

Flexibility

The aim is not to enforce a rules based scrum system. The goal is to reach an agile organization in its entirety, being able to "go forward in scrum." Being able to respond in rapidly evolving job situations, or having high doses of volatility, where no predictable criteria are present when designing new products or services. These are consumers who need to start using a product at the earliest opportunity and continually improve it. These are goods where the key value of innovation lies.

Flexibility is a basic principle of functional scrum implementation, which is to adapt scrum activities to the organization, not the other way around. This is more a matter of professional management than of scientific management. A management based on the manager's expertise, experience and criteria, not a search-oriented management and setting up the best pattern. Instead of the model a management based on the individual.

Knowledge of the various techniques and methodologies broadens the tool requirements and the fund for the manager.
It is advisable to follow the evolution of professional knowledge and to continually expand and improve the criteria and inventory of our own professional resources:
➢ Overcome resistance to transition, and stop model adoption behaviors or dogmatic protection.

➢ Have a critical-constructive spirit: to constantly question existing practices, with professional knowledge and standards, to adapt the working system itself to the characteristics of the project, team and organization in an "anti-thetic" manner.

The application of scrum procedures to the organization's own circumstances allows for the use of continuous or iterative techniques; Kanban boards with the most suitable structure for each project, and in general the methods and rules that best fit the circumstances of each situation. The guide lines of the defined rules are thus discarded, and the scrum values are applied directly.

Responsibility

Moving from the rule-based technical scrum to the advanced scrum, which applies the agile management concepts explicitly with the teams ' knowledge and experience, the scope of the duties to be undertaken goes beyond the project roles:

As a structural fact, the company must respond to responsibilities in three areas, in a structured and aligned manner with its vision: management, processes and production.

Management ➢ The organization's organizational equilibrium. ➢ Model continuity.
➢ Methods of preparation and instruction.

Processes ➢ Application of scalable scrum. ➢ Continuous development.

➢ Scrum operation guarantee for each project (in the technical scrum assigned to Scrum Master's role).

Production ➢ Product (assigned to the position of Brand Owner in the technical scrum). ➢ Self-organization (team delegated in professional scrum). ➢ Agile management (assigned to the equipment in the technological scrum).

The use of agile methods and techniques, operating in self-organized teams, identifying and maintaining a product vision throughout the project, and ensuring scrum activity during implementation, are tasks that fall within the scope of the project.

The various business areas are shared and integrated with a common vision, consistent with an agile style of work. Responsibilities within the organization include providing the ability to design and implement an agile framework suitable for the organization, continuous development of the model and training for employees.

Throughout technical scrum, project scope duties are handled by defined roles: · ➢ The responsibility for scrum activity is delegated to a particular scrum operation manager role: Scrum Master.
➢ Brand vision and management roles relate directly to the brand owner's position.

➢ The team is responsible for the self-organization and application of agile strategies and innovations.
The most advisable in implantation processes, in teams unfamiliar with agile development, is the adoption of the role model for the technological scrum.

In the evolution towards a more mature and global level of agility in the organization, it is advisable to adapt the scrum structure to the organization's truth, so that it is not the existence of certain roles and rules that are important, but to cover adequate the duties at the level of the organization.

One example of a versatile assignment of project scope obligations to the organization's current job scheme might be:

➢ Scrum project guarantor: consistency or processes
➢ product manager: self-organization
➢ Agile development= team

Whether it is in introducing agility, assigning the required responsibilities to the roles of the company's structure, or creating new positions (Product Owner or Scrum Master), the crucial thing is that the people who perform them have the expertise, knowledge and professional experience required.

Methodologies
A Technique Diagram.

Since the 1980s, so many process models, structures and work practices have been developed to improve the quality and productivity of software projects, which are useful for transcending labels and underpinning the underlying principles and strategies for their development; so that three concepts are coordinated: "growth, function and information" and two management models: "Predictive and evolutionary" clarifies and simplifies the apparent complexity of the process models, frames or work practices to which we refer: CMM-SW, CMMI, PMBOK, DSDM, Crystal, ISO 15504, RUP, XP, Scrum, ITIL, ASD, PRINCE 2, LEAN, KANBAN, TDD, etc.

1. Concepts Development

Complete : At the beginning of the project, the definition of what is needed is available, is complete and comprehensive, and acts as a basis for assessing the project plan: activities, resources and work agenda. Compliance is controlled at execution.

Incremental: At the outset, the definition of what you want to get is not accessible in a full and comprehensive way: it is complemented and develops in parallel with the growth, which incrementally produces the resulting product and can be handled with two different tactics:

Continuous incremental development: Use strategies to create a continuous flow of functionalities or parts of the product that are distributed continuously to the consumer.

Iterative development : The use of time-stamping or time boxing techniques to sustain cyclical and continuous output of product increments. This is the production system used to implement the standard scrum structure, which describes every development iteration as a sprint, at the end of which a product exists.

2. - Work

Sequential (waterfall): split the work into phases starting at the end of the preceding. The most common example is the cascade process with the specifications, analysis, design, coding, testing and implementation phases specified in the Software Engineering.

Concurrent: The various stages overlap in time. Following the example of software engineering, the results are described, evaluated, coded and implemented simultaneously and continuously checked.

3. - Information
Where the key information is used, the proper execution of the process or the know-how of the person carrying out the procedure?

Process-based production: In the processes and technologies used, information or know-how is more responsible for the quality of the result: "The quality of the result depends on the quality of the processes used."

Project management trends
Predictive administration

Management model whose goal is to produce predictable results: production of the expected product, in the expected time, and expenditure of the resources anticipated. It implements a full strategy of growth with the conventional planning practices. Management model whose goal is to produce predictable results: production of the expected product, in the expected time, and expenditure of the resources anticipated. It implements a full strategy of growth with the conventional planning practices. PMI and IPMA, and the process models CMMI, ISO 15504 and SPICE, among others, which employ sequential engineering and process-based production, are the key references in information creation for this type of management.

Evolutionary Management

Management model which aims to deliver a minimum viable product as soon as possible and to continuously increase its value. This uses a technique of alternating work stages, and gradual growth that can be accomplished by maintaining a pattern of brief and cyclic variations or a constant flow of development. It can be achieved with process-based development (concurrent engineering) or with manufacturing (agility) driven on humans.

This distinction is important because, without it, confounding situations are generated that come to consider agility in the simple application of the standard scrum rules (the process of iterative increase with roles and specified artifacts) or the simple use of kanban visual management techniques to maintain a continuous flow of tasks.

Agility and evolutionary control are not similar. Evolutionary management can be achieved with agility or by simultaneous engineering.
People, Processes and Technology
Scrum Manager's body experience reconsiders two vertices of the traditional development factor triangle: People - Processes and Technology, Method and individual.
Processes

We may assume that in one, people help the process, and in the other processes are the activities that help people, in order to differentiate the procedures2 into their two possible forms. The method is the protagonist in the first case, the one who knows how to do the job, and the individual is incorporated into the system as an instrument, as an operator or overseer.

In the second, the artificer is the individual and the process is a help, a tool which simplifies aspects of "mechanical" or routine.

Therefore, we are naming the first procedures and second activities.
The principal distinction between them is the sort of expertise in which they work. ➢ Explicit: method and technology material.

➢ Tacitus: the one applied by the individual based on his or her expertise, practice, experience and ability.
Scrum Manager takes the conventional people-process-technology triangle into consideration, provided that the working procedures may be:

➢ Processes: providing key information needed to achieve the outcome of their implementation. The method and the technologies it employs are therefore containers of "explicit" information.

➢ Practices: If the technique benefits the person who contributes the key to achieving the outcome with their tacit knowledge that is the "know-how."
It may be said that the person helps the procedure in the former, and in the latter, the procedure helps the individual.
Process engineering models regard the binomial "system-technology" as the main responsibility for result efficiency. The antithesis, the strength, gives people the importance of the product.

From Scrum Manager's point of view both choices are true, but for various types of jobs. People provide jobs for the implementation and control of processes in industrial production environments. However, for information firms operating in fast and creative scenarios, people contribute the know-how that gives value to the outcome with their talent.

CHAPTER 8: People

are organizations that need to add an innovative part constantly, or push in fast innovation sectors, get better results if they make the talent of people responsible for value generation rather than process execution.

In this form of organization it is necessary to ensure the ability to learn, in addition to the team's level of creativity. The knowledge conversion model Nonaka and Takeuchi (Nonaka & Takeuchi, The Knowledge-Creating Business, 1995) describes the mechanism for people to acquire tacit knowledge in 4 phases: exchange of experiences, direct communication, documents / manuals and traditions; which add new expertise to the organization’s common foundation.

Visual kanban Management for Continuous Increment. The picture below shows where the technical scrum is located, as illustrated in the previous chapter.

Its main characteristic is the use of sprint pulses; it uses timeboxing as an advance motor with a given and fixed cadence and the rhythm is marked by the sprint series.
The time boxing tactic helps the team push ahead while at the same time minimizing the normal trend towards missing planned delivery times.

The original scrum teams that Nonaka and Takeuchi (Nonaka & Takeuchi, The New Product Creation Game, 1986) encountered and defined and the agility principles do not recommend the use of a particular tactic for incremental creation. In fact, it is also possible to work, without increments, with a constant progression of tasks one after another.

It is not easy to achieve a continuous flow of tasks without the use of sprints because bottlenecks sometimes obstruct progress, creating dead times in other parts of the team in which they run out of tasks.

The Kanban visual management is currently the most commonly used technique for controlling a flow of continuous advancement in IT projects and information services controlled evolutionarily without sprints.

Kanban: Origin and Meaning

The Japanese word Kanban was used by Taiichi Onho (Toyota), which refers to the simulation method used in manufacturing processes that organize the timely delivery of each component just in time in an assembly line, preventing overproduction and excessive storage in intermediate states.

It can be translated as a board or signage coin, and its origin dates from the late 40s or early 50s. The term Kanban applied to agile project management refers to the techniques of visual representation of the information to improve the efficiency of project tasks.
Kanban in the IT Sector
Using Kanban boards displays and controls the process of advance and distribution, which helps to prevent the two main problems: bottlenecks and downtimes.
Agile software development uses visual management methods as they are the perfect way to incorporate transparent contact concepts and reporting and management efficiency principles.

Since 2005, it has become increasingly common to replace the product and the sprint backlog lists with sticky notes on boards that are more flexible and allow team members to add new tasks, changes in location, or rearrange user stories goals in a product backlog, or can represent by their position which ones are being programmed, checked, completed or otherwise posted.

The Kanban practices are true at continuous delivery for evolutionary management. They should be used with versatility requirements, without considering recommendations or exceptions in the working method and to achieve the customized implementation that gives the best response to the agile or concurrent engineering, or synthesizes concepts of both.

Expert Management Vs Technical Management
Several writers find scrum and Kanban as systems of different rules and practices. Subsequent distinctions would be made, according to Kniberg & Skarin (Kniberg & Skarin, 2009):

➢ Scrum stipulates positions, not kanban. ➢ Scrum works with fixed-time iterations, with Kanban (simple, multiple, or event-driven) cadences.

➢ Scrum limits the WIP by iteration, and Kanban limits the WIP by any workflow condition. ➢ Scrum teams are multidisciplinary; they can be professionals in Kanban.

➢ Scrum does not require the sprint tasks to be changed; the task can be changed in kanban until entering of flow.
➢ In scrum the product backlog must be at least one sprint long. The amount of tasks to pull must be attended in kanban.
➢ You must estimate the stories and tasks in scrum and calculate the pace; kanban does not quantify tasks or speed.
➢ Scrum wants a product backlog prioritized, the next story or job pulled from the customer in kanban.

➢ Scrum prescribes meetings every day, not kanban.
➢ Scrum uses burn down, not kanban, diagrams.
➢ At the end of each sprint, Scrum boards are reset, not in kanban.

By evolving towards an advanced scrum model based on the application of agility principles with one's own experience and knowledge and rejecting the rule-based models, it is learned to break.

These models and to adjust the procedures, leaving as trivial the technological and methodological problems' that otherwise distort the reality and the attention of the management: situation A:' On the one hand you want to use kanban but on the other hand you want to estimate the tasks (for example to record the pace for operational purposes of the company)...'

Situation B: "The Company manages simultaneous tasks with a project office organization and therefore suits roles better; but nevertheless, instead of scrum, you want to work with kanban... Should I do scrum ban? What is that? Or what should Scrum but do? Is it a bad manager's solution?

Boards at Kanban: principles
The methods of visual management in kanban are useful for:
1. They handle the workflow.
2. Data "Radio broadcasting."

A kanban board can only be used as an information broadcaster, or as a management tool for visual workflows.
1. - Kanban Workflow Management tools.

Guidelines for controlling the flow of progress of tasks can be placed on a kanban board. ➢ Each card's location on the board reflects the state of the work it represents. ➢ Regular minimum board states are "pending," "continuous" and "completed"

In some instances it is useful to include additional (e.g., checked, validated) states. The job order from the "pending" region represents the planned task sequence according to the priorities.

The works being controlled can be jobs, user stories or epics, depending on the board's use Kanban brings out the problematic stuff.

Conflicts in the prioritization of work, flow issues due to impediments or workloads, developmental incidences, etc. are immediately apparent when the state of the works is updated on board. Kanban Makes steady progress and stops Parkinson's rule
It produces a continuous development of the work whose rhythm is not "predestined" by temporal planning: Gantt or Sprint (iterative increase).
The lack of immediate milestones prevents the normal propensity to prolong working hours to complete the estimated time (Parkinson's Law)
At the other hand, the absence of temporary milestones without kanban techniques to track and control progress will result in time and delay prolongation due to uncertainty and perfectionism. Foster sustainable development by agile processes. Promoters, developers and consumers need to be able to keep a steady speed forever.

2. - The Broadcasting Knowledge.
Kanban serves as a broadcasting medium for updates on the progress of the project: It encourages direct contact.

➢ [It enables direct communication within the team by sharing information at meetings before a Kanban board].
➢ It shares the project's exposure with all those concerned.
It helps to spot problems early on

➢ Kanban is actively tracking project progress. The updating of just-in-time information helps to identify the potential impediments, challenges and threats at first, which otherwise go unnoticed before they start producing already unavoidable delays or repercussions.

This promotes a system of cooperation and resolution.
➢ It is an open and transparent contact tool for the team and all the participants.
Kanban: Operational
Sequence and Flexibility

Two variables that interact in a work scenario and decide the form and manner in which the kanban board is to be used:
➢ Task sequence: Do the tasks have to be carried out in a certain order, or can they be carried out in any order?

➢ · People's versatility: can team members perform any task? Series: Sequence.

Do the works expressed in the board's sticky notes need to be done in any order, or can they be performed in any order?

Designing a board for the development of a new information system is not the same as designing a corporation for the management of technological infrastructure. The first case requires that the tasks be performed in a given order. For example, the test function can't be performed if the programming wasn't completed before. However, a repair team's responsibilities may be the following: "installing a new printer on the Director's computer" "updating the web server's operating system" etc.

They can perform this type of tasks in any order. There are no dependencies between them so you can do anybody at any moment, even if the other tasks are not done.
Polyvalence

Are polyvalence a multifunctional team, or are they specialists? Can any member do any of the tasks? Following previous examples, a person may or may not be able to install a printer or an operating system indistinctly in the maintenance team; there may be hardware engineers and software technicians. Similarly, a programming project may include specific tasks of graphic design, engineering, development, testing, etc. that can only be carried out by some members of the team.

The following image illustrates kanban's main value: the management of a continuous advance flow, and the considerations that need to be addressed in order to design the board with the most suitable structure for our work and team.

Four are possible trends by combining concurrent or free work with a multi-purpose team or a team of specialists:
1. A polyvalent team which carries out non-sequential tasks.
This is the simplest setting to manage: anybody in the team can perform any task, and tasks can be carried out in any order.

In this case, if there are bottlenecks or dead hours, change steps will concentrate on maximizing the size of the team according to demand, and distribution of the types of tasks and demand times as far as possible.

2. - Team of experts performing non-sequential activities.
Group specialization adds an element of complexity in addressing bottlenecks or dead times.

If there are bottlenecks, the approach must go in one or both of the following lines to face the sort of tasks that provokes them:
➢ Sizing: either the number of people trained to perform this type of tasks, or the number of tasks of that kind that can be affected, or the customer response times.

➢ Optimizing this form of task execution process.
The existence of dead times will call into question the demand element or its non-homogeneous distribution.

3. - A flexible unit, performing concurrent tasks In this case, the key cause of tensions within the flow is the connection between tasks.

A common method of managing sequential tasks in kanban boards is to restrict the maximum number of tasks that can be found in a given phase. This is named "WIP-adjustment." WIP is a term used in lean manufacturing, from where it originates, it is used to denote the number of products that are not yet finished at the same time in a manufacturing phase.

By comparison, this term is used in kanban boards to denote the tasks that are in a process step, awaiting passage to or completion of the next one; and in this context, the term WIP indicates the limit or maximum number of tasks that may accumulate in a given area. For example, let's assume that in a software programming kanban board the test area "has a WIP of 3," this means that in that step there can be no more than three tasks at once.

4. - Professional team and work which needs a sequenced order.

It is the setting in which a continuous workflow is more difficult to adapt as it involves review and fine tuning of all potential lines of improvement: size and balance of team specialists, size or balance of interaction response times, and modification of WIP limits in each phase.

The board brings issues to the surface in each of these four possible situations, and the team or manager will make the changes in the potential lines of work taking into account the individual case and the circumstances of their company according to their requirements.

Practical Cases of Kanban Boards
Examples of different board types are given below.
Dashboard for providing information about product development.

Example of the board which may be found in the office of the product manager showing the condition in which the product is being built.
It is not used as a visual management tool in this case but as a "broadcaster" of information. The dashboard reveals the following details concerning the product's state of development: ➢ Suggested stories of users that are under review without yet deciding whether they will be integrated into the product.

➢ · Approved user stories: the feature will be added.
➢ User stories "prepared" to be scheduled (previously respected and prioritized). ➢ App stories now under programming.
➢ Scheduled usage history which can be analyzed in the test environment.
➢ Already analyzed user images, awaiting implementation.
➢ App stories shown in the two previous versions.

Evolutionary development boards, with continuous growth, and with iterative increase.

In addition to providing visual information, Kanban enables strategies such as restricting the WIP to be implemented, and shows the areas that need to be changed to ensure a continuous flow of growth. Operating with continuous increase is beneficial.

But can a team working with scrum and iterative steps use kanban to visually represent the progress of tasks with sticky cards, rather than using a forward graph?
Case 1: Continued growth.
The images below represent potential boards to direct a team's work management that is developing a product with continuous increases, and showing the following information:

➢ Activities backlog
➢ Activities that is "prepared."
➢ Analytical activities.
➢ Coding jobs.
➢ Duties done.
➢ Tasks built into server (labs) creation.
➢ · Integrated output tasks.

Case 2: The rise is iterative. Dashboard to direct a team's job management in iterative increments (sprints), and to show: ➢ Backlog of tasks
➢ Prepared tasks.
➢ Theoretical activities.
➢ Coding jobs.
➢ Duties done.
➢ Integrated Engineering System (Laboratory) tasks / Integrated output tasks.

The Operations and Maintenance Department Board. Management board of running and maintenance equipment reflecting: ➢ Status of scheduled weekly activities and the individual with whom each works. ➢ Status of accidental and critical events and individuals involved in each. Flow-adjustment tips: Muda, Mura, and Muri.

Muda, Mura and Muri are three core principles of continuous improvement of Kaizen, which Lean manufacturing integrates as key variables for increasing efficiency.

➢ Muda: Waste
➢ Mura discrepancy. Dynamic Workflow. Workflow interruptions. Time-off. ➢ Since Muri: stress. Work overload which creates bottlenecks.

Mudas
The most common Mudas or waste in IT projects is:
➢ Bureaucracy: processes, documents and needless paperwork not adding value to the result. ➢ Overproduction: Create more properties than necessary.

➢ Multi project: Alternating working hours between multiple projects and process interruptions.
➢ Waits: Waiting times because the system lacks cadence.
➢ "Beginning to do": ordering staff to carry out tasks that are not properly specified and thus preventing people from stopping working.
➢ Misalignments of capacity: highly talented individuals assigned to routine tasks, and vice versa.

➢ Errors: bugs rework.
The Kanban boards sense the other two kaizen variables and help manage them: Mura and Muri. Mura and Muri Distinguishing factors
It should be noted that each company or project type has its own characteristics of:

➢ Sequence: tasks must or must not be performed sequentially.
➢ Flexibility, flexibility or team members ' expertise.
And those are the variables that decide the greater or lesser difficulty in sustaining a continuous production flow in each case.
As has been seen, the polyvalent-member teams working with non-sequential activities are the ones that can more easily achieve a steady forward flow.

If problems arise, the variables to be combined in each case according to the possibilities are: ➢ Volume of Demand

➢ If a bottleneck is created in one step, care should be taken to ensure that the next story to be entered on the board needs little effort from that point.

➢ In a given process the WIP or function caps.
➢ Staffing: size of the staff and specialization or flexibility.
Muri
The WIP is an important variable for changing bottlenecks (Muri):

The idea of sprint disappears when kanban is used to sustain a continuous rise. The outcome of a sprint is no longer a rise, but every user story that is completed and delivered to the customer. Bottlenecks (Muri) must maintain a continuous flow of deliveries that increase the commodity in a sustained way Bottlenecks (Muri) must be avoided: hence, tasks must be accumulated at some stage of the process. One way this can be achieved is to limit the amount of work that can be accrued at each point.

The parameter indicating the maximum number of tasks in a kanban board area is the so-called WIP: Job in Process, or Inventory in Process. It should not be confused with Work in Progress, a concept designating a work that has begun but is not yet complete.

In other phases a "WIP" value that is too small may cause jams, particularly if the system is too rigid (sequential tasks and specialist equipment).
Experience shows you how to get the right fit to reach the optimum continuous flow. If previous experience is not available and the tasks should not exceed 4 ideal hours, a starting criteria must be defined by the team and added from there.
A generally useful advice in this context (in teams with multipurpose members) is to start with a WIP equal to the number of team membersx 1.5, rounding off the result by excess. Operating with tasks whose size is expected to exceed one operating day is not advisable and it is advisable to break them into smaller ones if this occurs.
Example: The following figure shows the "Information Evaluated" and "In Progress" kanban board with a work cap.
In this example the owner of the product has a backlog (A) sorting zone. It is the environment where user stories are frequently introduced, updated, and prioritized by the product manager But there are only three stories to go into development that can be in the "analyzed" condition. Three with which the review and revising of the estimate with the team is already scheduled.

Likewise the area "in development" has a three-story limit. When one goes to "DONE," every other will enter production, and for as long as there are three in the "ANALYZED" zone, the next story of the backlog to be selected will not be decided.

This requires a non-jamming, constant, and centered workflow.
Mura

The principal factors responsible for the fluid instability and the frequency of Mura or dead periods are:

➢ Degree of the team members being multifunctional. ➢ Flexibility in the order in which each job must be carried out in different phases. ➢ Flexibility to adjust the entry order of the product stacks user tales. The bigger those things are, the easier it is to prevent downtime.

Conclusion

Scrum guide was developed as a means to create a necessary guide for organization and professionals who want to implement in scrum, as well as those who already doing so who want to make needed improvement to their existing process. It is based on experience gathered from thousands of project from variety organization and industries. The contribution of many experts and project delivery practitioners has been considered in its development.

➢ The main thing about beginning a Scrum project is just that, starting.
o No need for weeks or months of preparing and writing specifications and criteria, just enough reasonable backlog to launch the first sprint
o Comprehensive advance preparation is 80 percent of the current cost of an average project... waste valuable resources
You can do five projects for the cost of one by removing the extensive preparation and accepting that you will know along the way.
Only remember to continue focusing on the Sprint Retrospective and enhancing processes... everything else you can find for yourself. Continuous assessment of where you stand is important!