The Scrum Framework — Second Edition

This chapter retains the second edition’s historical and practical teaching context. The third-edition curriculum is also available in the contents below.

---

Scrum Example: A Real-World Scrum Example for Top Agile Teams

In this article, we would love to present you a Scrum methodology example that could inspire your Scrum teams, other business stakeholders and people related to your projects. We have seen many instances where companies and businesses have trained Scrum professionals, but due to the lack of Scrum experience, they encounter challenges in their daily Scrum operations and product implementation.

This problem usually hinders Scrum teams from reaching their optimal team velocity and releasing their deliverables on time and within budget. And here comes the importance of this Scrum methodology example.

Therefore, in this short article we will try to help you see the big picture of the Scrum framework, from the construction of your Scrum processes that build unprecedented value for businesses, products and services that create an extensive agility experience for your clients to how you configure and leverage your Scrum burndown chart in order to improve and sustain the velocity of your Scrum teams.

With this Scrum methodology example, we will assist you in understanding how a Scrum team operates and how it can benefit your organization. Data suggest that in most businesses, Scrum teams typically consist of a Product Owner, a Scrum Master, and developers, together forming the Scrum Team, who work together in short iterations called sprints to deliver valuable increments of the product. This iterative approach allows for flexibility, adaptability, and faster feedback.

Here are the main characters of this example of scrum methodology:

• Alex, the Scrum Product Owner.
• Frank, the Scrum Master.
• The Scrum Team.

Before starting the first Sprint

Alex is assigned as the Scrum Product Owner of a new software development project. One of his first tasks is to start requirements engineering. He writes down the most important use-cases and discusses them with the architects, customer representatives and other stakeholders. After collecting the high-level use-cases and requirements, he writes them into the Scrum Product Backlog and initiates an estimation and prioritization session with the architects and some senior developers. As a result of this session all the items in the Scrum Product Backlog have an initial rough estimation and a prioritization. Now he starts to break down the high-level requirements into smaller-grained user stories. With this list he then calls for the first Sprint Planning meeting.

Introduction to Scrum – A Real World Example across various Scrum Phases and Sprints

Sprint 1 - Day 0

During the Sprint Planning meeting Alex presents the Scrum Product Backlog items from the highest priority to the lowest. The team clarifies open questions and for each item the team discusses if they have enough capacity, the required know-how and if everything else needed is available. After this discussion they commit to complete stories 1, 2, 3, 6, 7, and 8 by the end of this Sprint. The items 4 and 5 cannot be realized in this sprint, as some technical infrastructure is not yet in place.

After the Sprint Planning meeting Frank - the Scrum Master of the team - calls the team to define the details of how the committed items are going to be implemented. The resulting tasks are written down on the cards at the prepared Sprint Task board. Now every member of the Scrum Team selects a task to work on.

Protip for Scrum Teams:

Alex, serving as the Scrum Product Owner, is leading a new software development project within his organization. His role is akin to being the conductor of an orchestra where each person plays a part. His cross-functional role brings significant responsibility and focuses on creating self-organizing agile software development frameworks, where improvement is an ongoing process. This framework is not a one-size-fits-all solution but rather a charted course to guide the developers in their work. He is the pulse of the company, ensuring that the end products created are those that the customers need. An agile approach, such as this, iterates continually, hence promoting constant refining of products and methods.

Next, Alex propels an estimation and prioritization session using user stories (See more about Scrum User Stories) and story points as a relative-estimation technique. Kanban-style visualization can complement this work by making tasks and workflow visible to everyone on the team. As a result, all items in the Scrum Product Backlog receive an initial approximation and a prioritization. Alex draws from his project management experiences to break down high-level requirements into user-centric stories, an approach that effectively translates requirements into deliverable chunks. These user stories, acting as concrete examples of the things customers want, illustrate paths to achieving project goals. Armed with this list, he convenes the first Sprint Planning meeting, fostering a culture of close collaboration across the software development team.

Sprint 1 - Day 1

In the morning the whole team gets together for their Daily Scrum Meeting. Everyone briefly explains what has been achieved so far, updates the estimation of remaining hours on the cards of the Sprint Task board, tells what he or she is planning to do today and explains whether any impediments are blocking progress. Today, one of the team members explains that he has a problem because he needs a new license for one of the software tools he is using. Frank checks if other team members have the same problem and says that he'll take care of that after the meeting. After 15 minutes everyone goes back to work.

After the meeting Frank updates the Sprint Burndown. Then he calls the software vendor of the tool, orders licenses and forwards them to the people that need them.

Protip for Scrum Teams:

During Sprint Planning, Alex outlines the Scrum Product Backlog items, ranked by priority. It's his organization-bound responsibility to ensure that every person comprehends the overarching goal of the project. The team's stand-up meetings facilitate open discussions that clarify roles and resolve potential issues.

Frank, the Scrum Master, plays another instrumental role in this diverse team. He navigates each daily stand-up, helping conversations stay focused on the Sprint Goal when needed. The developers own their plan and choose their tasks collaboratively; Frank does not assign their work.

Sprint 1 - Day 2

In the morning again the whole team gets together for their Daily Scrum meeting. In the afternoon one of the Scrum team members is unsure about the details of one of the user stories. He calls Alex –Scrum Product Owner- and discusses the open points with him. After the team member finds out what to do, then he can continue with his implementation.

Sprint 1 - Day 28

This is the final day of the first Sprint and Frank –Scrum Master- has invited the team for the Sprint Review Meeting. The team has prepared a machine with the current software implementation. Alex –Scrum Product Owner- sits in front of the machine and checks if the implementation meets his expectations and if the features are documented as required. At the end of the Review Session he concludes:

• Stories 1, 2, 6, and 7 are finished as expected.
• Story 3 couldn't be finished in time and was not presented at all.
• Story 8 has some points that need refactoring.

In the afternoon the team gets together for the Sprint Retrospective Meeting and discusses what went well during the sprint and what could be improved. One piece of feedback is that the team feels they do not know enough about the overall system architecture. Frank takes the task to invite the system architect to give a more detailed introduction.

Scrum Methodology Example

Protip for Scrum Teams:

As the final day of the first Sprint arrives, Frank leads the team in the Sprint Review Meeting. Their consistent collaboration yields a tangible prototype reflecting the team's commitment and hard work.

In the afternoon, the team convenes for the Sprint Retrospective Meeting. Here, they exchange insights on their progress and revisit aspects that demand improvement for future sprints. This meeting proves to be a critical element of the agile approach, offering substantial value to the project at large.

Planning for the next Sprint, Alex's pivotal role as a Scrum Product Owner shines once again as he adds new items to the Scrum Product Backlog based on recent customer meetings. As the second Sprint commences, it is evident that principles of teamwork, transparency, and effective project management continue to propel this information-driven team towards success.

Sprint 2 - Day 1

Alex –Scrum Product Owner- adds new items to the Scrum Product Backlog based on his recent customer meetings. Moreover, he adds additional items for the refactoring of story 8. Alex then invites the team for the Sprint Planning Meeting for Sprint 2. The team discusses and commits to stories with the guidance of Frank –Scrum Master- and the second Sprint begins.

Protip for Scrum Teams:

The second Sprint puts the team’s learning into practice: the revised Product Backlog reflects customer feedback, the unfinished work is reconsidered, and collaboration continues around the next Sprint Goal.

Studying Scrum examples and case studies is imperative for organizations aspiring to cultivate efficient and high-performing Scrum teams. Analyzing real-world scenarios provides invaluable insights into successful implementations and, equally crucially, helps identify common pitfalls to avoid. By learning from these examples, teams can expedite their journey towards becoming top performers, leveraging best practices, sidestepping potential mistakes, and achieving quick wins in their Scrum endeavors.

Stay tuned for more real-world scenarios and case studies that will further enrich your understanding of the Scrum Framework and its practical applications.