Agile Scrum Cheat Sheet

Agile Scrum Cheat Sheet

Agile Scrum Cheat Sheet

Scrum is a framework that is used to address complicated problems, increase productivity and produce high-valued products. It is not so much a process but a way of developing processes that can be adaptable to any business and team. Although simple to understand, Scrum is challenging to master. The following information can help you review Scrum, especially when you are taking a test or are being interviewed about Scrum. Connect with our experts to learn more about our IT courses.

The Scrum framework came about in the 1990s to help manage and work on complex projects. Since then, it has been adopted by many prominent companies, such as Google, Apple, Yahoo and Facebook. Scrum is particularly used by software companies to drive productivity and create new software products.

Scrum is based on empiricism, which states that knowledge comes from experience and making decisions based on what we know. As part of Scrum, small teams work together as part of a larger team. Each team has a specific role. Everything is laid out, inspected to make sure the goal is being followed properly, and finally, the team adapts to create faster and better products more efficiently.

Scrum is used for software, hardware, governments, schools and managing daily activities. Since it is a framework, it can be adapted to any situation that requires producing something of value with efficiency. In this regard, Scrum is highly advantageous and can be used to perform twice the work in half the time.

There are three pillars of implementationtransparency, inspection, and adaptation.

Transparency

Major parts of the project must be visible to those overseeing the entire project cycle. Also, each part should have a standard to reach and it be judged based on this standard. This also helps people understand what they should achieve. For example, a rising company might use a competitor’s product as a standard; if they are really ambitious, they might want to use the competitor’s product and try to make something better. Additionally, each step must be spelled out so that everyone knows when every step is complete.

Inspection

All Scrum participants have to inspect each part of the process so that no variances are found. But inspection should not be burdensome and reduce productivity. In other words, inspection should not be overused. Inspection is best performed by skilled inspectors that do not get in the way of the work process. A skilled inspector will understand exactly what to look for and inform of any issues so that the process runs smoothly. Of course, the process is not always perfect. Nothing is perfect, but striving towards an ideal can produce above-average results.

Adaptation

There might be a need for an adjustment if the inspector finds one or more parts of the process or product is not up to the agreed-upon standard. The inspector may also find that the end product might not meet the end result in mind. In this case, an adjustment is made to divert away from the wrong course to get back to the standard. This adjustment must be made immediately to prevent any further deviations from the ideal.

Scrum has four major aspects of inspection and adaptation: spring planning, daily Scrum, sprint review, and sprint retrospective.

Start your 30-day free trial to get your hands on in-demand Scrum certifications

Scrum Values

If values such as respect, openness, commitment, courage and focus aren’t followed, then the above three pillars of implementation can’t run as designed. Teams that don’t trust one another can’t work efficiently, so having these Scrum values will help transparency, inspection and adaptation along the way to creating software or any product. The teams explore what values are important to them when working with Scrum roles, events and artifacts.

These five values drive the entire process and are very important to the success of the team and product. The Scrum Team is open to the team about what problems lay ahead and all work-related issues. The team members accept the rules and obey them to respect the other members and the process. They also have the courage to do what’s right and work diligently. The focus is on the Sprint and the goals of the project.

What Is the Scrum Team?

The Scrum Team includes the following: a Product Owner, the Development Team and a Scrum Master. Scrum Teams are also cross-functional and self-organizing. These teams choose how to reach their goals, so they have no one outside the team to govern them. Each team focuses on a specific goal. In regards to software, one team might focus on frontend development while another works on the backend development. In this way, the teams work on one task at a time, but each understands the ultimate goal and are on the same path to success.

However, a cross-functional team focuses on the big picture and has the capabilities to work amongst all the teams. The Scrum Team can be adaptable, creative and productive, as it can move from area to area to make sure the final product will be made as planned. For all of the above reasons, the Scrum Team is highly effective.

There are also small deliveries of important mini-goals, so feedback can be administered readily once each mini goal is accomplished. This also helps form the finished product by remembering the tiny details that made up the larger whole. For a physical product like a car, even a certain bolt can lead to the success of a vehicle. And the software applied to vehicles can be formed through Agile Scrum. Toyota, for example, uses Scrum for their Toyota Production System.

What Is a Product Owner?

The Product Owner makes sure the value is at its highest after work is completed by the Development Team. This is an important role, but how each Product Owner achieves value is up to the individuals, Scrum Teams, and organizations. Each person will have a different way to assess value. For example, an automobile manufacturer that wants to create a reliable and affordable vehicle won’t focus on expensive electronics while a luxury car will have the latest and luxurious gadgets. It would not be wise to use the same assessment for both these automobile manufacturers, since their goals are not aligned.

The Product Owner also is in charge of the Product Backlog. Taking care of the Product Backlog includes writing down the items in the log, ordering the items, assessing the work that the Development Teams provide, and making the Product Backlog visible and clear to everyone in the Scrum and Development Team. The Product Owner is a single person, so anyone who wants to change the backlog must speak to the Product Owner. The Product Owner’s actions must be respected for him/her to succeed.

The Development Team

The Development Team involves experts working together to create a product after the end of each Sprint. This is also after the Increment of “Done,” which are small goals after each Sprint, and a “Done” result is needed at the Sprint Review. The Development Team creates the Increment.

Development Teams also create a structure for their work and organizes it to become more efficient. They manage their own work, which helps make the team effective, as they understand what to correct and focus on in order to improve the entire process.

The following includes some facts about the Development Team:

  • They are self-governed. No one, including the Scrum Master, tells the Development Team how to release Increments.
  • Development Teams are cross-functional. They have the skills needed to form an Increment.
  • Scrum doesn’t recognize any titles used by people within the Development Team.
  • There are no sub-teams with the Development Team, even in areas that should be focused on.
  • Some team members might have specialized skills, but accountability ultimately resides in the Development Team in its entirety.

How Big Should the Development Team Be?

The Development Team is relatively small in size, which helps make it easier to manage and work amongst each other. This also helps improve productivity during a Sprint and finally lead to a useful product. The best number of participants in the Development Team is about four to eight. For some, four may be too small; for others, eight could be too many.

However, three or less is too small to create any meaningful work, and too many people become chaotic. Small teams also encounter a lack of more specialized professionals, as two or three assumed that those two or three are experts in many areas, which is not realistic for most. Small teams also slow down development, which makes putting out Increments difficult and slow. However, large teams are also too complicated to create anything of use. The Product Owner and Scrum Master aren’t counted unless they handle the work within the Sprint Backlog.

What Is a Scrum Master?

The Scrum Master simply administers Scrum as outlined in the Scrum Guide. Their job is to teach and help everyone understand the basic ideas, values, rules, practices and theory of Scrum. The Scrum Master is also called a servant-leader, as the role involves teaching while at the same time serving the team. They also coordinate how outsiders should interact with those inside the Scrum Team, which helps create a valued collaboration.

The Scrum Master Serves the Product Owner

The Scrum Master makes sure that the scope, goals and product are comprehended by every person on the Scrum Team, discovers way for better Product Backlog management, helps the Scrum Team understand why the backlog items should be clear and simple, creates agility, oversees Scrum events, comprehends product planning and makes sure the Product Owner understand the Product Backlog and how it’s used effectively.

Scrum Master Services to the Development Team

The Scrum Master serves the Development Team as well. The Scrum Master facilitates Scrum events, coaches the Development Team in cross-functionality and organization, removes roadblocks and helps the Development Team create value.

Scrum Master Services to the Organization

To the organization as a whole, the Scrum Master creates change to increase productivity within the Scrum Team, plans Scrum implementations, helps stakeholders and employees comprehend Scrum, leads the organization to effective Scrum implementation and teaches the importance and potential results from using Scrum within said organization.

Scrum Events

Scrum Events are timed events to prevent long, unproductive meetings. In other words, a meeting can’t be longer than the pre-meditated time. A meeting meant for five minutes can’t be longer. This also assumes that everything can be discussed within that time frame. A Sprint, once begun, cannot be shortened or lengthened. This ensures that the meetings are productive and aren’t wasted. According to the Scrum Guide, Sprints are containers for events. And they are meant to be adaptable and inspected to improve transparency and productivity.

Sprint

Sprints bring everything together; they are the focus of Scrum. A Scrum lasts for a month or less, where “Done” is completed, as Scrum calls it. Then a releasable product called an Increment is completed. Once complete, a new Sprints forms. This process goes on and on and involve Sprint Planning, development work, Daily Scrums, Sprint Review and Sprint Retrospective.

Each Sprint accomplished a goal. To do this, there is a goal of what to create, a plan to do so, the work to achieve this goal and finally the product Increment. Sprints are only a month long. Why? When the goal is longer, it becomes too complex, risk increases and what’s being created might change.

A large project can be successfully completed through continual Sprints of one month each. This also increases productivity because a month-long project is easy to focus on instead of a quarter-long or even a year-long project. It’s similar to building an automobile by first focusing on one step at a time, from basics to less important aspects.

Sprints are predictable since they are inspected often and adaptable to any environment, and this also reduces the cost due to only being one month in duration.

Enroll in our Agile Scrum Master Training at QuickStart

Can the Sprint be Cancelled?

The Product Owner can cancel the Sprint, but this is due to a joint solution discussed among the stakeholders, Scrum Master and Development Team.

Why would they cancel the Sprint? It might be because the goal has changed. It should be noted that cancelling a Sprint is rare since so much effort is put into creating the Sprint.

To use the repeating example, it would be like an automobile manufacture deciding to change their mind about creating a new vehicle. So much money is put on the line to create a vehicle that suddenly cancelling it would be extremely rare. A new product is a calculated goal that is rarely abandoned unless under extreme stress. A cancelled Sprint is rare.

Planning a Sprint

Sprint Planning lasts eight hours, but there can be shorter Sprints. The Scrum Master’s job is to ensure that everyone understand the purpose of the meeting and that the events takes place. The Scrum Master also teaches how to keep the planning within the eight hours.

There are two important questions as part of Sprint Planning: What is our goal for the Sprint, and how can we accomplish this goal?

The first step involves setting a goal and assessing past mistakes, if related to any prior Sprints. The first meeting involves the Product Backlog, a recent product Increment, the Development Teams past performance, and the competence of the Development Team while working on the Sprint.

The second step to planning the Sprint involves assessing how the team will achieve the goal at the end of the Sprint, which is also called a “Done” product Increment. This plan and the Product Backlog are collectively called the Sprint Backlog. This step involves figuring out how to turn the Product Backlog into a product. At the end of this meeting, the Development Team will tell the Scrum Master and Product Owner how it will create the product through the system they designed together.

Daily Scrum

A 15-minute event is held every day for the Development Team and is called a Daily Scrum. This inspects past work and forecasts future work. It’s also planned for the same time every day. Some teams will prefer the Daily Scrum to be more of an open discussion. Questions might arise, such as about what a person did the day before to help advance toward the Sprint Goal, what they’ll do help the Development Team reach the Sprint Goal and if there is anything that will prevent the person and the team from reaching their goal. The meeting should be within 15 minutes.

Sprint Review

A Sprint Review is a collaboration among stakeholders and the Scrum Team about what the Sprint accomplished. Any changes to the Product Backlog are made, and the progress of the Sprint and what goals were achieved are assessed. This makes sure that they learn from any mistakes and create the necessary adjustments. A Sprint Review is not a formal review though.

A one-month Sprint results in a four-hour meeting, but it should not last longer. If there were short Sprints, then the meeting will be much shorter. The meeting should help bring everyone together and not be about individual mistakes, as it is a team effort that is guided, not siloed into different areas. In this way, productivity increases, and it becomes more about what each person and each team can do to improve.

The Product Owner invites the Scrum Team and certain stakeholders. The product owner explains what’s been accomplished. The Development Team goes over any issues and if they were solved, then discusses what was done and answers questions. The Product Owner explains the Product Backlog and might give possible due dates for the product. Then the group understand what to do next, and this will help create new Sprint Planning in the future. Next a review is completed detailing the use of the product and the market demand for it; if anything has changed, then they will adapt to the change. Finally, they’ll review the budget, capabilities of the product, the timeline, marketplace in order to prepare for the next incremental release to the ultimate creation of the product.

Sprint Retrospective

The Sprint Retrospective is an important part of the Sprint that involves the Scrum Team creating improvements to help the process in the next Sprint. This part happens right before the next Sprint Planning and is set at a maximum three-hour long meeting for a one-month Sprint. The Scrum Master oversees that everyone who should attend is present and understand the reason for the meeting and that the event takes place. The reason for the Sprint Retrospective is to go over the previous Sprint in detail—the people, tools, process and relationships—and decide what needs to be improved and create a plan for these improvements in the future.

Scrum Artifacts

Scrum Artifacts are things visible to everyone and which provide openness in order to create value. These are things already discussed, such as an Increment, Sprint progress monitoring, Sprint Backlog, monitoring goal progress, and the Product Backlog. The Product Backlog is simply the list of things needed to create the product. The Sprint Backlog includes these items and creates a plant to deliver the product to meet goals. Then progress is monitored, and finally the Increment is the end, where Product Backlog items are completed during the Sprint and the collective value provided during all previous Sprints to reach the final goal.

Scrum is very versatile and is used in many different sectors. Toyota, Apple, Yahoo and Google all use Scrum to become productive. In this regard, learning Agile Scrum is advantageous and useful for working inside many established businesses across the world. Receiving training in Scrum could give you an advantage over your competition and be the next best step in your career.

Talk to our experts to learn more. Start your 30-day free trial to gain access to over 900 courses.

Previous Post Next Post
Hit button to validate captcha