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.
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
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.
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.
