Scrum is a lightweight framework that helps teams work together on complex problems, generating value through adaptive solutions.
In other words, it has some rules, and it gives a structure. Still, it leaves much room for creativity, innovation, and ownership which is precisely the right approach for working with talented and intelligent people in the IT industry.
The Scrum framework consists of Scrum Teams and their associated Roles, Events, and Artifacts.
The Scrum Team
Let’s start with the Scrum team, knowing that the people are the ones adding the most value to everything below.
Scrum Team consists of Product Owner, Scrum Master, and Developers. The number of people in one Scrum Team is ten or fewer because smaller teams communicate better and are more productive. Also, it takes time for one team to function, so it is better to have consistent teams.
The Product Owner
In practice, the Product Owners “own” the product, have knowledge about it, and are accountable for maximizing its value from work done by the team. They’re the ones that order the work into Product Backlog, making it well-defined, transparent, clear, understandable, and visible.
That means that the Product Owners explicitly communicate the Product goal and Product backlog items. They’re those who can represent many Stakeholders and also serve as liaisons between the product and development. For example, to optimally define and communicate the requirements of the product, the Product Owner must understand the needs of the product but, at the same time, possible technical solutions.
The Scrum Master
Scrum Master is responsible for guiding and assisting the team itself. Not a manager but rather a guide that teaches the team self-management and cross-functionality. They remove the impediments to the team’s progress and are accountable for its effectiveness, ensuring that Scrum events are productive and within the timebox.
Scrum Master is putting agile values and principles into practice by training, motivating, and inspiring team members. A kind of glue for the team having a human supporting role.
The Developers
Developers are Scrum Team members who create usable increments each sprint. But don’t be confused by the term. “The Developers” are not only Software Devs but also QA and DevOps Engineers, Designers, etc. All who are committed to achieving the Sprint goal.
The Developers’ assignment is also to create a plan for the sprint, officially called — Sprint Backlog. This is usually the case in practice since they have the most technical knowledge. Developers are taking ownership of adding more technical details — refining tickets about the actual technical implementation.
For example, there is a specific request from the Product Owner — defined in the ticket regarding the need for the new feature. The Product Owner will be the one to define the request, and the developers will help refine how the request can be technically, functionally, and visually implemented. Scrum Master will help remove impediments, ensuring the team is productive. That’s why they’re called a Scrum team — each member adds value to achieve the sprint goal.
Scrum Framework
Let’s talk about how using the Scrum framework can help address the complexity of product delivery.
Empiricism
We can define it as a way to approach problems we encounter during product delivery. Empiricism is based on observation and experience in contrast to relying on theory or logic.
In practice, that means we constantly learn from our experience and observation of current and previous situations and create solutions and decisions accordingly.
Of course, Scrum will add a structure to that as well. So we can describe and define problems based on previous learnings and break them down into smaller increments to be executed. This circle never ends as we tend to be adaptable to changes and new encounters.
Daily Scrum is the perfect example of applying empiricism, where the team, daily, inspects and adapts based on previous results. The other instance of empirics is Sprint Review, where the team shows their results, receives feedback, and changes accordingly. That is how we are constantly improving.
It’s straightforward. The team works in short iterations, showing the results in the Review process, receiving the feedback, inspecting, and adapting accordingly. We can talk even more about the details of this transparency, inspection, and adaptation process, as those are also the Three Pillars of Scrum.
Three Pillars of Scrum
Transparency — We all know what’s going on
Sharing facts between the Scrum Team, Stakeholders, and other company members are key to success. Trust is a must-have ingredient for a strong company culture that benefits the company and its employees.
Transparency is used in Daily stand-ups. By openly sharing the work progress and further plans. The Sprint Review by showing the results of each sprint. In the Retrospectives, by evaluating and improving work processes and adapting the definition of done. And in the Refinements where is openly and transparently discussed what and how needs to be done.
Inspect — Check your work as you do it
Inspecting means that we constantly inspect the state of the product and the processes. That way, the team can adapt timely and create plans for improvements if the product doesn’t meet the stakeholders’ desires or the processes aren’t optimal. Without constant inspection, we can end up with the “wrong” product and useless processes, as simple as that.
Adapt — Change as a need occurs
Adapting is a logical next step after the inspection, as already mentioned. Without it, inspecting and giving feedback have no value. The ability to adapt means the product and the company can stay effective as the market changes.
Scrum Values
The processes cannot help if we don’t have specific human behavior. Again, it’s all about people. Under the Scrum Framework, we talk about sets of fundamental values and qualities needed for the process to function optimally.
Scrum values are commitment, focus, courage, openness, and respect.
These values create an environment where empirical processes, self-organization, and continual improvement are more successful.
Commitment
Commitment means being dedicated to a goal and a vision.
As a result of commitment, we can see the people’s actions and efforts, ultimately creating valuable products or features.
In practice, we can see commitment results in getting things done in a specific time frame, asking questions, creating the best solutions, and creating continuous improvements.
Commitment is a prerequisite for focus.
Focus
Not everything can be done simultaneously! Focusing on the priorities, and current sprint goals, making progress, and achieving it within the sprint, creates the space for moving to the next item.
In short, focus means selecting the priority and working on it from start to finish before moving on to the next item.
Courage
If you need to speak your mind, propose new solutions and ideas, work on something new or in a new way and run experiments, you’ll surely need courage. It’s an ability to be bold and innovative, and risk is the price for the opportunity.
Openness
There’s no transparency without openness since Scrum Master is only a helper, and the team is self-organizing. To do so, every team member needs to be open and transparent about what is going on and why. The best decision can be made only after being clear about the received information.
Respect
To feel safe and to stay open, respect is essential. Respect is needed while sharing different opinions, views, approaches, and ideas. We must respect other team members and have a starting point that they can implement suggested ideas and be independent in taking care of dedicated work. It increases motivation and boosts performance.
Scrum Events
The Scrum framework describes five events — Sprint, Sprint planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Scrum Events ensure that the team members are in sync.
Scrum Master is the one that teaches about the purpose, input, and output of those meetings.
Let’s do it here in a concise but concrete way.
The Sprint
It’s the heart of the Scrum, timeboxed to a maximum of one month, primarily held in 2 or 3 weeks. If the sprint is too long, the complexity rises. The definition of what needs to be done may not be as clear as change can occur, and the risks can get too high.
During a sprint, usable and potentially releasable product increment is created.
Each sprint has a goal — what we’re working on, design — how that should look like, and a flexible plan. A new Sprint starts right after the previous one has finished.
Events that occur during one sprint are:
Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective.
Product Backlog Refinement can be an additional Sprint event.
Sprint Planning
Sprint Planning is a starting meeting of a new sprint where all team members are included, and the plan and the goals for the upcoming sprint are created.
Scrum Master facilitates the meeting, ensuring people are present and prepared and the content is available to everyone.
The Product Owner presents and explains the prioritized list of the Product Backlog items.
Developers actively participate and should fully understand the work’s scope and purpose.
Daily Scrum — Stand-Up Meeting
Daily Scrum is an event held each day of the sprint at the same time and is timeboxed to 15 minutes. It’s a meeting for the Development team, and if additional members join that meeting, Scrum Master must ensure they do not interrupt.
Daily Scrum is used to check the status of the ongoing work, and by doing so, these kinds of questions can be asked:
· What did you do yesterday?
· What will you do today?
· Are you blocked, and if yes, where?
· How are we standing about hitting the Sprint goal?
They’re not mandatory. The team can decide to use a different way of checking the progress toward the sprint goal.
Sprint Review
During this meeting Scrum Team and the Stakeholders review what was done during the sprint.
Sometimes it’s also called The Demo, but it shouldn’t be just a presentation of the accomplished work.
The purpose of this event is to inspect and adapt so that the meeting members can have constructive criticism and collaboration about the next steps.
Sprint Retrospective
It’s an event held at the end of the sprint. The main goal is to inspect the past sprint and plan improvements for the next one. The team is doing self-evaluation regarding processes or adaptation of the definition of “Done” to increase product quality. The timebox for this meeting is up to 3 hours.
One of the examples how the Retrospective meeting can look like is:
The team gathers with the shared board, where they can post notes with their opinion on what went well and what didn’t. Notes are classified by the subject or main focus and discussed. As a result of a discussion, action points are created with owners, and the progress of action points is tracked.
Product Backlog Refinement
At this meeting, Scrum Team is getting more familiar with the work that needs to be done.
This meeting can also be used for estimating tickets to make a more precise plan about the number of tickets that can be done in one sprint.
It can be done in a way that each Developer gives their own estimate, and it is up to the team’s decision on the exact estimate for each ticket that will be selected. It can be done at any time during a sprint, and multiple teams can participate. It usually consumes no more than 10% of the development team’s capacity.
Conclusion
As you can see, Scrum is a framework that has specific rules, events, roles, and values. Still, it’s very adaptable and flexible to any organization based on specific needs.
Stay Agile and keep improving! 🤘
About Author
Tamara Petrović — Scrum Master with more than nine years of experience, a keen eye, and impressive problem-solving skills. She possesses deep functional and Non-Functional testing expertise and exceptional domain knowledge in the Fintech and Real Estate industries.