Unlocking the power of Scrum, a beginner’s guide

Code with Mesfin
11 min readMar 10, 2024

--

Note : “The images featured in this article are not my own. I acknowledge and extend credit to their respective owners, utilized solely for illustrative purposes.”

Scrum Definition

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

Scrum is an Agile framework for developing and sustaining complex products. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).

The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.

Did you know that a negative work environment can decrease output for even the best performers? In fact, a positive work culture can even help less productive employees improve!

Why do companies prefer Scrum?

Let us revise the most common traditional model, waterfall model.

The waterfall model is an activity-centered life cycle model that prescribes a sequential execution of development phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. This traditional thinking leads to different personal expectations from different perspectives.

Scrum is different .

Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance for another iteration.

Scrum helps the team to deliver a really working value faster and with fewer/no headaches by focusing on delivering product/feature of the highest business value with the shortest possible time frame. It forces teams to be self-managed to determine the best way to deliver the highest priority features.

I can proudly say a Scrum is a work culture that allows teams to productively and creatively deliver products of the highest possible value in a shortest possible time frame. It clearly defines teams, artifacts, events, and deliverables. Scrum activities are transparent, inspectable, and adaptable.

The Three Pillars of Scrum: Transparency, Inspection, and Adaptation

Transparency

The emergent process and work must be visible to those performing the work as well as those receiving the work. With Scrum, important decisions are based on the perceived state of its three formal artifacts. Artifacts that have low transparency can lead to decisions that diminish value and increase risk. Transparency enables inspection. Inspection without transparency is misleading and wasteful.

Inspection

The Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently to detect potentially undesirable variances or problems. To help with inspection, Scrum provides cadence in the form of its five events. Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Adaptation

If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation. Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum Teams — Self-organizing and Cross functional Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

  1. Product Owner: Responsible for maximizing the value of the product and the work of the Development team.
  2. Scrum Master: A servant-leader for the Scrum Team. He/she is responsible for ensuring Scrum is understood and enacted.
  3. Developers: A team of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

The Scrum team is characterized by;

  • Self-organizing teams
  • Product progresses in a series of month-long “sprints”
  • Requirements are captured as items in a list of “product backlog”
  • No specific engineering practices prescribed
  • Uses generative rules to create an agile environment for delivering projects
  • One of the “agile processes”

Work of Product owner

1. The Product Owner is one person, not a committee.

2. The Product Owner is the sole person responsible for managing the Product Backlog.

  • Identifying and 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.

3. For the Product Owner to succeed, the entire organization must respect his or her decisions.

4. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog

What is a product backlog? It is a feature or user story identified as a potential to be implemented.

What is a user story? A simple description of a product feature that is told from the perspective of the user who wants that feature.

Work of Scrum Master

  1. The Scrum Master is responsible for ensuring Scrum is understood and enacted.
  2. 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.

3. Scrum master is expected to help:

  • The product owner
  • The development team and
  • The organization

Development Team

The Development Team consists of 5 to 15 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 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.

Scrum Events, Sprint

What is a Sprint ?

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.

What are the scrum events ?

  1. Product Vision
  2. Sprint Planning,
  3. Daily Scrums,
  4. The development work,
  5. The Sprint Review, and
  6. The Sprint Retrospective.

During the Sprint :

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Who has the power to cancel a Sprint?

A Sprint can be canceled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

Product Vision

The Product Vision captures the shared understanding of the goal that is to be achieved with building the product. It is created by the Product Owner (often in collaboration with other involved parties) and guides the Scrum Team(s). It is similar to a North Star indicating where you want to go without the details on how to get there.

Jeff Bezos (Founder & CEO of Amazon) describes it really well saying:

“Be stubborn on the vision and flexible on the details!”

Some teams mistake the Sprint Goal as the Product Vision. These two are inherently different. The Sprint Goal is something that can be achieved within a specific sprint i.e. maximum 4 weeks of work. Based on this, a Sprint Goal is smaller than the Product Vision and every Sprint Goal delivers towards the Product Vision. This is a good test for a Product Owner and their team to assess whether they are moving in the right direction or not.

Sprint Planning

  1. The Sprint plan is created by the collaborative work of the entire Scrum Team.
  2. Sprint Planning is time-boxed to a maximum of eight hours for a 1 to 4 week long Sprint. For shorter Sprints, the event is usually shorter.
  3. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.
  4. Sprint Planning answers the following:
  • What can be delivered in the Increment resulting from the upcoming Sprint? SMART Goal.
  • How will the work needed to deliver the Increment be achieved?

Daily standup meeting

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.

During the meeting, the Development Team members explain:

  1. What did I do yesterday?
  2. What I planned to do today?
  3. What were my obstacles or blockers (if any) ?

Sprint Review

The Sprint Review 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 Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team 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 completion 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 release of the product.

Sprint Retrospective

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

3. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by adapting the definition of “Done” as appropriate

4. By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint.

The Agile Manifesto

The Agile Manifesto, created in 2001 by a group of software developers calling themselves the Agile Alliance, outlines 4 core values and 12 principles for a more flexible and responsive approach to software development. The aim was to move away from cumbersome traditional methods that focused on documentation over working software and customer interaction.

The 4 Agile values

  1. Individuals and interactions over processes and tools: Agile places more importance and emphasis on people and their interactions over processes and even tools.
  2. Working Software over comprehensive documentation: Documentation requires a time and resource commitment that might be wasteful.
  3. Customer Collaboration over contract negotiation: Agile promotes a collaborative outlook when product owners work with customers in reaching an agreement on the details of the product delivery.
  4. Responding to changes over following a plan: Agile embraces the change that makes business sense.

The agile manifesto’s 4 paired values and its associated 12 guiding principles sets a solid foundation for the various agile frameworks that are currently being practiced by successful organizations in today’s digital age.

The 12 Agile Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • The goal of product development is the development of a successful product.

2. Welcome changing requirements, even late in development

  • Agile processes harness change for the customers’ competitive advantage.
  • Due to the competitive landscape, requirements can be & will change throughout product development.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shortest time scale.

  • Frequent and iterative delivery of working products provides the business with practical feedback.

4. Business people and developers must work together daily throughout the project.

  • The product owner and the agile team adopt practices that ensure inclusive and joint practices.

5. Build projects around motivated individuals.

  • Give them the environment and support they need and trust them to get the job done.
  • Agile leaders build agile teams with skilled resources who are willing to work together collaboratively with a growth mindset.

6. The most efficient and effective method of conveying information to and within a development team is face to face conversation.

  • For a product development team to succeed its members must communicate and collaborate effectively.

7. Working software is the primary measure of progress.

  • The primary measure of product development should be the delivery of working product increments, which meet the evolving needs of the business.

8. Agile processes promote sustainable development.

  • The sponsors, developers, and uses should be able to maintain a constant pace indefinitely.
  • A highly skilled team simply just cannot be expected to successfully develop a product by compelling people to work overtime for an extended period.

9. Continuous attention to technical excellence and good design enhance agility.

  • Built-in quality practices have enormous benefits
  • It allows for easier maintenance and scalability of the product

10. Simplicity — the art of maximizing the amount the amount of work not done is essential.

  • With the guidance of product owners, agile teams focus on high value activities, which allows them to focus on the high business value needs.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

  • This is a critical principle of the agile world to ensure that emerging and effective architectures, requirements, and designs are built into the product development life cycle to maximize technical excellence.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  • Finding concrete opportunities for improvement is a continual effort.

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

Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.

Thank you for your time. Your feedback is valuable in helping me improve this content.

Reference: https://scrumguides.org/scrum-guide.html

Written by:

Mesfin Tsegaye

Email: sciemesfin55@gmail.com

Linkedin: https://linkedin.com/in/codewithmesfin

Github: https://github.com/codewithmesfin

Website: http://codewithmesfin.et

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Code with Mesfin
Code with Mesfin

Written by Code with Mesfin

Dive into Code, Mesfin's Guidance

No responses yet

Write a response