THE SCRUM FRAMEWORK IN 30 SECONDS
After reading this post we must be able to understand what exactly is SCRUM framework? and what it is used for? When and where to use SCRUM?
WHO CREATED SCRUM?
Jeff Sutherland Created the SCRUM Process in 1993 and used the term SCRUM for comparing high-performing, cross-functional teams similar to that in a RUGBY Game.
What is a SCRUM?
SCRUM is a term used for a team that forms a ring of people with their hands interlocked around each others shoulders and the team march forwards to pull the ball towards their side. It's a term used to describe a circle formed in a RUGBY Game by the players.
SCRUM is the leading agile development methodology, used by Fortune 500 companies around the world. SCRUM is an Agile Framework for completing complex projects. SCRUM was originally formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The SCRUM Framework is deceptively simple.
It is lightweight, Simple to understand, Difficult to master. Actually, SCRUM is not a process or a technique for building products; rather,
it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them.
Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Transparency
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:
• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those accepting the work product must share a common definition of “Done”
Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaption
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal events for inspection and adaptation:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
THE SCRUM TEAM
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
THE PRODUCT OWNER
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
THE DEVELOPMENT TEAM
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
THE DEVELOPMENT TEAM SIZE
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
THE SCRUM MASTER
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
SCRUM MASTER SERVICE TO THE PRODUCT OWNER
The Scrum Master serves the Product Owner in several ways, including:
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
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;
After reading this post we must be able to understand what exactly is SCRUM framework? and what it is used for? When and where to use SCRUM?
WHO CREATED SCRUM?
Jeff Sutherland Created the SCRUM Process in 1993 and used the term SCRUM for comparing high-performing, cross-functional teams similar to that in a RUGBY Game.
What is a SCRUM?
SCRUM is a term used for a team that forms a ring of people with their hands interlocked around each others shoulders and the team march forwards to pull the ball towards their side. It's a term used to describe a circle formed in a RUGBY Game by the players.
SCRUM is the leading agile development methodology, used by Fortune 500 companies around the world. SCRUM is an Agile Framework for completing complex projects. SCRUM was originally formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The SCRUM Framework is deceptively simple.
It is lightweight, Simple to understand, Difficult to master. Actually, SCRUM is not a process or a technique for building products; rather,
it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them.
Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Transparency
Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.
For example:
• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those accepting the work product must share a common definition of “Done”
Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.
Adaption
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.
Scrum prescribes four formal events for inspection and adaptation:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
THE SCRUM TEAM
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.
THE PRODUCT OWNER
The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
THE DEVELOPMENT TEAM
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
THE DEVELOPMENT TEAM SIZE
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
THE SCRUM MASTER
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
SCRUM MASTER SERVICE TO THE PRODUCT OWNER
The Scrum Master serves the Product Owner in several ways, including:
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
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;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
SCRUM MASTER SERVICE TO THE ORGANIZATION
The Scrum Master serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Continued . . .
In the next post we will see:
SCRUM EVENTS
THE SPRINT
CANCELLING A SPRINT
SPRINT PLANNING
SPRINT GOAL
DAILY SCRUM
Till then stay tuned, keep reading. Do like it and share it with your colleagues. Sharing is Caring. The more you share the more you possess! If you like to give your valuable feedback please leave your comment and we'll get back to you as soon as possible.
God Bless! TING!!!
In the next post we will see:
SCRUM EVENTS
THE SPRINT
CANCELLING A SPRINT
SPRINT PLANNING
SPRINT GOAL
DAILY SCRUM
Till then stay tuned, keep reading. Do like it and share it with your colleagues. Sharing is Caring. The more you share the more you possess! If you like to give your valuable feedback please leave your comment and we'll get back to you as soon as possible.
God Bless! TING!!!
No comments:
Post a Comment