SIMPLY #SCRUM IS: The Rules of the Game

Introduction:

As touched from the scrum benefits in my day-to-day activities in work, home, decision, brainstorming, and so on.

I recommended this article for those who have the experience and even who need to kick off the door of the scrum and #agilemethodologies to go through it, hopefully, the highlighted points will help you to reach the details and start #learning more about the #Scrumframework, and use it in your upcoming journeys.

The Scrum Framework:

Definition of Scrum

#Scrum (n): Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat

Uses of Scrum

Scrum was initially developed for managing and developing products. Scrum has been used extensively, worldwide, to:

1. Research and identify viable markets, technologies, and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
5. Sustain and renew products.

Scrum Theory

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials. 

The Scrum Values:

The Roles of the Scrum Team:

The Scrum Team consists of a Product Owner, a Scrum Master, And Developers.

1. Product Owner – This role represents the client and the business in general for the product on which they’re working. They own the backlog & strive to prioritize items to be worked on before every sprint. They make executive product decisions on a daily basis. Ultimately, they’re translating customer needs into actionable work items for the Developers.
2. Scrum Master – This person is responsible for ensuring the team has everything they need to deliver value. They are a coach, counselor, advocate, impediment-remover, facilitator, mentor, teacher, and mediator all rolled into one.
3. Developers – The specific skills needed by the Developers are often broad and will vary with the domain of work, However, the Developers are always accountable for Creating a plan for the Sprint Backlog, Instilling quality by adhering to a Definition of Done, Adapting their plan each day toward the Sprint Goal, and Holding each other accountable as professionals

The Scrum Events:

• Sprint:

Sprints are the heartbeat of Scrum, where ideas are turned into value.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint #Goal;
• Quality goals do not decrease;
• The Product Backlog is refined as needed; and,
• The scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.

Shorter Sprints can be employed to generate more learning cycles and limit the risk of cost and effort to a smaller time frame.

Each Sprint may be considered a short project.

• Sprint Planning:

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning addresses the following topics:

• Topic One: Why is this Sprint valuable?
• Topic Two: What can be done this Sprint?
• Topic Three: How will the chosen work get done?

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter

• Daily Scrum:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work, Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key to inspect and adapt meeting.

• Sprint Review:

Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

The #SprintReview includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
• The Developers discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Developer demonstrates the work that it has "Done" and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint

• Sprint Retrospective:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.

The maximum sprint size is 4 weeks and the smallest sprint not less than 1 week of executive work. The example here shows the scrum events time as per sprint size for time #estimating which will help the team to estimate and control each event.

Scrum Artifacts:

• Product Backlog:

The #ProductBacklog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove their completeness when "Done"

• Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

The Sprint Backlog makes visible all the work that the Developers identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high-priority process improvement identified in the previous Retrospective meeting.

• Increment:

The #Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

Artifact Transparency

Definition of "Done":

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Developers in knowing how many Product Backlog items it can select during Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of "Done".

Developers deliver an Increment in product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of "Done" for an increment is part of the conventions, standards, or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

#Scrumguide #scrum #scrummaster #productownder #developmentteam #scrumframework

THE END