How does Scrum deal with risks?

Being an Agile, iterative process, the Scrum framework inherently minimizes risk. The following Scrum practices facilitate the effective management of risk:

1. Flexibility reduces business-environment-related risk
Risk is largely minimized in Scrum due to the flexibility in adding or modifying requirements at any time in the project lifecycle. This enables the organization to respond to threats or opportunities from the business environment and unforeseen requirements whenever they arise, with usually low cost of managing such risks.

2. Regular feedback reduces expectations-related risk
Being iterative, the Scrum framework gives ample opportunities to obtain feedback and set expectations throughout the project lifecycle. This ensures that the project stakeholders, as well as the team, are not caught off guard by miscommunicated requirements.

3. Team ownership reduces estimation risk
The Scrum Team estimates and takes ownership of the Sprint Backlog Items, which leads to more accurate estimation and timely delivery of product increments

4. Transparency reduces non-detection risk
The Scrum principle of transparency around which the framework is built ensures that risks are detected and communicated early, leading to better risk handling and mitigation. . Moreover, when conducting Scrum of Scrums Meetings, Impediments that one team is facing currently can be deemed a risk for other Scrum Teams in the future, and that should be recognized in the Updated Impediments Log.

5. Iterative delivery reduces investment risk
Continuous delivery of value throughout the Scrum project lifecycle, as potentially shippable deliverables are created after every Sprint, reduces investment risk for the customer.

 Acknowledgement: It has been borrowed from www.scrumstudy.com/blog/

The Value of Self-Organization

When people think about the corporate world, they often picture a hierarchical system in which orders filter through a chain of command that starts with the micromanaging CEO and ends with submissive, low-wage workers. That’s not the case in the world of Scrum, where self-organization plays an essential role. Scrum embraces “servant leadership,” which emphasizes achieving results by focusing on the needs of the Scrum Team. The belief is that when employees are self-organized they are self-motivated and seek greater responsibility, resulting in much greater value.
When paired with cross-functionality, self-organization offers Scrum Teams great flexibility. The use of cross-functional teams ensures that all of the skills and knowledge required to carry out the work of a project exists within the team itself. This provides an efficient working model that results in the creation of deliverables that are potentially shippable and ready for demonstration. Self-organization ensures that Scrum Team members determine on their own how to do the work of the project without a senior manager micromanaging their tasks. Having cross-functional and self-organized teams allows the group to adapt and effectively manage the ongoing work and any minor issues or changes without having to obtain support or expertise from members outside of the team.

The benefits continue. Self-organization leads to team buy-in and shared ownership, team-wide motivation and an innovative environment conducive to growth. Initiative, creativity and enthusiasm have room to grow when not shackled to tight parameters. It is important to note that self-organization does not mean that team members are allowed to act in any manner that they want to. It just means that once the Product Vision is defined in the Create Project Vision process, the Scrum Core Team itself works very closely with relevant stakeholders to refine requirements to match that vision through the Develop Epic(s) and Create User Stories process.
Prioritization is primarily done by the Product Owner who represents the Voice of Customer, but the self-organized Scrum Team is involved in task breakdown and estimation during the Create Tasks and Estimate Tasks processes. During these processes, each team member is responsible for determining what work he or she will be doing. The Scrum Team and Scrum Master work closely to demonstrate the product increment created during the Sprint in the Demonstrate and Validate Sprint process where properly completed deliverables are accepted. Since the deliverables are potentially shippable, the Product Owner and the customer can clearly visualize and articulate the value being created after every Sprint. In turn, Scrum Teams have the satisfaction of seeing their hard work being accepted by the customer and other stakeholders.
Although self-organization does not mean team members have free rein to do as they please, it presents an opportunity not to languish under the reign of a suffocating hierarchy. When employees are self-organized they are self-motivated, and when employees are self-motivated they generate much greater value. And that’s when deliverables make it rain.
For more interesting articles about Srum and Agile, visit www.scrumstudy.com/blog

Scrum Is a Haven for the Mentally Strong

A Forbes.com article at the end of 2013 identified thirteen things mentally strong people avoid and the characteristics they have that motivate their aversions. They still have those characteristics today. A comparison of that list with workplace practices makes it clear that mentally strong people would feel at home and energized in a Scrum environment.

Cheryl Conner, the writer of the Forbes’s piece, starts the list of “the things mentally strong individuals don’t do” with “Waste Time Feeling Sorry for Themselves.” She explains that these people “have learned to take responsibility for their actions and outcomes.” A Scrum Master readily sees several points of correlation. The first is the Sprint Review meeting in which the Scrum Team members demonstrate what has been accomplished during the Sprint to the customer, if possible, and the Product Owner, who speaks for the customer. This provides immediate feedback for the Scrum Team member, who will have that good feeling of having one’s “actions and outcomes” affirmed or will learn directly what must be done to make the outcome acceptable. Taking responsibility to improve or remake a product is easier with clear, direct communication. The mentally strong individual appreciates this.
Another point of correlation is self-organization in Scrum. “An important feature of Scrum is self-organization, which allows the individuals who are actually doing the work to estimate and take ownership of tasks,” according to A Guide to the Scrum Body of Knowledge (SBOK™). Having a real voice in estimating—setting real and achievable expectations—and being able to have ownership of what one is doing is freeing to the mentally strong who “have learned to take responsibility for their actions and outcomes.”
Conner also says that the mentally strong do not “shy away from change,” “fear taking calculated risks,” “make the same mistakes over and over,” “resent other people’s success,” nor “expect immediate results.” She explains that “they apply their energy and time in measured doses and they celebrate each milestone and increment of success on the way.” Scrum embraces change, uses risk assessment and mitigation throughout each project’s iterations, employs a retrospect meeting at the end of each Sprint to learn from mistakes and create actionable items for future Sprints, builds strong team camaraderie and moves forward incrementally to develop high-quality results.
The Scrum workplace is obviously a strong fit for the mentally strong worker and the mentally astute company.


Acknowledgement: This content is borrowed from http://www.scrumstudy.com/blog/scrum-is-a-haven-for-the-mentally-strong/

How are User Stories Created in a Scrum Project?

In a Scrum project, the responsibility for creating User Stories generally lies with the Product Owner(s). User Stories ensure that the customer requirements are clearly depicted and are understood by all the key internal and external stakeholders including the Scrum Team who deliver the outputs of the project. In Scrum, the User Stories and the associated Acceptance Criteria are outputs of the Create User Stories process which is executed by the Product Owner.

Before we discuss the process of creating User Stories, let’s understand what they are. User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. A User Story tells you three things about the requirement: Who, What, and Why. The requirements expressed in User Stories are short, simple, and easy- to-understand statements. 

The predefined, standard format results in enhanced communication among the stakeholders and better estimations by the team. Some User Stories may be too large to handle within a single Sprint. These large User Stories are often called Epics, and once they come up in the Prioritized Product Backlog to be done in an upcoming Sprint, they are further decomposed into multiple smaller User Stories. Now, let us understand Create User Stories process in detail. Similar to other Scrum processes, this process too has its key inputs, tools and outputs. 

The key inputs are Scrum Core Team, Prioritized Product Backlog, Done Criteria, and Personas. The most import tool is User Story Writing Expertise. And the major outputs are User Stories and User Story Acceptance Criteria. Let’s discuss the inputs first. Scrum Core Team includes Scrum Team, Scrum Master and Product Owner. Although the entire Scrum Core Team needs to be involved in creation of the User Stories, it is the Product Owner who decides the User Stories as he/she creates the project’s initial overall requirements, determines Product Vision, assesses the viability and ensures delivery of the product or service, decides minimum marketable release content and ultimately, provides Acceptance Criteria for the User Stories to be developed in a Sprint. However, the Scrum Team can seek clarifications from the Product Owner and also provide expert opinion on creation of User Stories. One of the major tools or techniques that can be used to develop User Stories is User Story Writing Expertise. 

The Product Owner, based on his/her interaction with the stakeholders, his/her own business knowledge and expertise, and inputs from the team, will develop the User Stories that will form the initial Prioritized Product Backlog for the project. The Prioritized Product Backlog represents the sum total of what must be completed during the project. The objective of this exercise is to create elaborated and refined User Stories that the Scrum Team commit to. Although the Product Owner has the primary responsibility for writing User Stories, and often carries out this exercise on his/her own, a User Story Writing Workshop can be held if desired.

Acknowledgement: This article is borrowed from www. scrumstudy.com  ( Original URL: http://www.scrumstudy.com/blog/how-are-user-stories-created-in-a-scrum-project/ )

Aspects of SCRUM

Various Aspects of SCRUM

Scrum is a framework for collaborative effort of the team on some of the very complex software projects. It is the most widely-used subset of Agile. The Scrum principles are the fundamental guidelines for applying Scrum framework. The Scrum framework drives on the goals of giving utmost business value in least time.

Various Scrum aspects are derived and are very essential to be addressed and managed throughout a Scrum project. Here are the five Scrum aspects as mentioned in the SBOK™ Guide

• Organization: Understanding defined roles and responsibilities in a Scrum project is very important for ensuring the successful implementation of Scrum. Scrum roles fall into two broad categories; Core Roles (which includes Product Owner, Scrum Master, Scrum Team) and Non-core Roles (which includes Stakeholder, Scrum Guidance Body, Vendors, Chief Product Owner, Chief Scrum Master)

• Business Justification: Business justification in Scrum is based on the concept of Value-driven Delivery. It is impossible to guarantee project success at completion, irrespective of the size or complexity of a project.
• Quality: Quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. The Scrum Guidance Body may also provide guidelines about quality which may be relevant to all Scrum projects in the organization.
• Change: Every project, regardless of its method or framework used, is exposed to change. Scrum projects welcome change by using short, iterative Sprints that incorporate customer feedback on each Sprint’s deliverables. This enables the customer to regularly interact with the Scrum Team members, view deliverables as they are ready, and change requirements if needed earlier in the Sprint.

• 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 should be identified, assessed, and responded to basing on two factors: the probability of each risk’s occurrence and the possible impact in the event of such occurrence.

Acknowledgement: The content is borrowed from www.SCRUMstudy.com (original blog url: http://www.scrumstudy.com/blog/various-aspects-of-scrum/)