The Real Scrum Guide 2024 – v.2.1.0 – 30/1/2024 Update
Developing innovative new products like autonomous vehicles requires overcoming many uncertainties and managing a high degree of complexity.
Traditional sequential project management approaches often struggle in these dynamic environments.
Agile frameworks like Scrum introduce new ways of working that emphasize flexibility, collaboration, and delivering value iteratively.
To get a hands-on look at how Scrum helps tame complexity, we will walk through an end-to-end example of developing an autonomous electric vehicle.
The Real Scrum Guide 2024. is like a practical exercise that will take us through Scrum fundamentals like writing user stories, estimating effort, sprint planning, and continuous improvement. The original Scrum guide is available here.
By simulating an Agile software development process, we’ll gain insight into how cross-functional teams can effectively build cutting-edge products despite rapidly changing requirements and technology uncertainties. Let’s dive in!
Before we get started with The Real Scrum Guide 2024, let’s establish some ground rules for how we’ll be working together. These ground rules will help us to ensure that we’re all on the same page and that we can collaborate effectively.
Introduction to the Scrum Framework
Scrum is an iterative and incremental framework for project management and product development. It is designed to help teams deliver products and services quickly and efficiently.
The five Scrum values are commitment, focus, openness, respect, and courage. These values guide the behavior of Scrum teams and help them work together effectively.
These five values are essential for the success of any Scrum team. By living these values, teams can create a culture of collaboration and trust, which will ultimately lead to the successful delivery of products and services.
The Real Scrum Guide 2024 showcases practical applications of the Scrum values:
- The team commits to the goals of the sprint and to working together to achieve them. This means that the team is willing to put in the time and effort to get the job done.
- The team focuses on the work of the sprint and avoids distractions. This means that the team is not multitasking or working on other projects during the sprint.
- The team shares information and ideas. This means that the team is transparent and honest with each other, and is willing to listen to and consider new ideas.
- The team members respect each other’s skills and abilities. This means that the team members are willing to help each other and learn from each other.
- The team is willing to make tough decisions and take risks. This means that the team is not afraid to challenge the status quo and try new things.
By applying these values in practice, Scrum teams can create a culture of collaboration and trust, which will ultimately lead to the successful delivery of products and services.
The Six Principles of Scrum
Scrum has six important rules that everyone in the team must follow during every project. These rules are like a must-do list, and Scrum followers believe sticking to them is crucial to keeping the team on track and avoiding project problems.
Keep an eye on the real process
Scrum uses a process based on actual evidence and testing, not just theories. This principle focuses on three main ideas: being clear about what’s happening, checking how things are going, and making changes when needed.
Work as a team
In Scrum, everyone gets a say, and individuals have the power to manage their own work. Working as a team makes it easier for everyone to get involved and see the value of their contributions.
Team up and collaborate
Scrum is all about teamwork, involving different roles (more on that later). This principle emphasizes three ways of working together: being aware of what others are doing, communicating clearly, and taking responsibility for the work.
Put important things first
This principle is about organizing tasks based on their value and figuring out the best way to do them.
Set time limits
In Scrum, tasks have specific time frames, like sprints with set durations. Planning and meetings also have fixed start and end times. Setting time limits helps everyone know how much time is available for each step, reducing wasted time and delays.
Improve as you go
This last principle recognizes that a project might need changes as it progresses. It allows the team to make improvements and handle changes more easily.
Now, let’s move on to the Scrum Roles and Responsibilities…
The roles and responsibilities in Scrum
- Defines the product vision and ensures that it is aligned with the business goals.
- Prioritizes the product backlog and identifies the most valuable features to be developed in the next sprint.
- Works with the developers to ensure the product backlog items are clear, concise, and achievable.
- Manages stakeholder expectations and communicates the product vision to them.
- Facilitates the Scrum process and ensures that the team is following the Scrum framework.
- Removes impediments that prevent the team from being productive.
- Coaches the team on Scrum practices and helps them to improve their skills and abilities.
- Promotes a culture of collaboration and trust within the team.
Developers in Scrum
- Develops the product according to the product backlog and the sprint plan.
- Performs all necessary work to deliver the product increment at the end of the sprint.
- Self-organizes and decides how best to work together.
- Inspects and adapts its work regularly.
The purpose of Sprint Planning is to create a plan for the upcoming sprint. The product owner and developers work together to identify the most critical product backlog items to be developed in the sprint, and to estimate the work required to complete them. The goal of the sprint planning meeting is to create a sprint plan that the team commits to completing.
Daily Standup (Daily Scrum)
The purpose of the daily standup is to synchronize the work of the developers and to identify any impediments to progress. The daily standup is a short meeting that takes place every day at the same time and location. The developers answer three questions (not mandatory but still very effective):
- What did I do yesterday?
- What will I do today?
- Are there any impediments to my progress?
The daily standup is a great way to keep the developers on track and to identify any potential problems early on.
The purpose of the sprint review is to inspect the product increment that was developed during the sprint and to get feedback from stakeholders. The sprint review is a meeting that takes place at the end of the sprint.
The product owner presents the product increment to stakeholders, and the developers answer questions and get feedback. The sprint review is an opportunity for the team to get feedback on their work and to make any necessary adjustments before the next sprint.
The purpose of the sprint retrospective is to reflect on the past sprint and to identify ways to improve the process for the next sprint. The sprint retrospective is a meeting that takes place at the end of the sprint.
The team discusses what went well during the sprint, what could be improved, and what they plan to do differently in the next sprint. The sprint retrospective is an opportunity for the team to learn from their experiences and to improve their process over time.
A sprint is a time-boxed period of work, typically lasting between one and four weeks. During a sprint, the Scrum team works together to complete a set of specific goals. The sprint is a fundamental unit of work in Scrum.
The sprint begins with a sprint planning meeting, where the product owner and developers work together to identify the most critical product backlog items to be developed in the sprint.
The team then estimates the work required to complete each product backlog item and creates a sprint plan.
The Real Scrum Guide 2024 offers practical examples of how these events can be implemented:
At the Sprint Planning meeting, the product owner and developers might identify a new feature that they want to add to the product. They would then estimate the work required to complete the feature and create a sprint plan that includes the feature.
At the Daily Standup, the developers might identify that they are having trouble completing a particular task. They would then discuss the issue with the Scrum Master, who would work to remove the impediment.
At the Sprint Review, the product owner might present the product increment to stakeholders, and get feedback on how the product can be improved. The developers would then use this feedback to make any necessary changes to the product before the next sprint.
At the Sprint Retrospective, the team might discuss how they can improve their communication with each other. They might decide to hold more frequent stand-ups or create a shared document to track their progress.
By following the Scrum process, teams can deliver products and services quickly and efficiently. The Scrum events are essential for this process, as they help teams to plan, collaborate, and improve their work.
Backlog Refinement is a crucial Scrum event that involves the entire Scrum Team to clarify, estimate, and prepare backlog items for effective Sprint Planning and execution. By maintaining a well-groomed backlog, the team can enhance its overall productivity and deliver value to customers more efficiently.
Backlog Refinement typically occurs throughout the Sprint. It is an ongoing and regular activity that happens several times during the Sprint. The Scrum Team collaborates to refine backlog items before they are brought into a Sprint Planning meeting for selection and inclusion in the upcoming Sprint.
The product backlog is a list of all the features, requirements, and improvements that are needed for the product. The product backlog is ordered by priority, with the most important items at the top. The product owner owns the product backlog.
The product backlog is used in the sprint planning meeting to identify the product backlog items that will be developed in the next sprint. The product backlog is also used in the daily standup meeting to track the progress of the developers.
The sprint backlog is a subset of the product backlog that the developers commit to completing in the next sprint. The sprint backlog is created during the sprint planning meeting and is owned by the developers.
The sprint backlog is used to track the progress of the developers during the sprint. It is also used to communicate the team’s progress to the product owner and other stakeholders.
The increment is the working product that is produced by the developers at the end of each sprint. The increment should be potentially releasable, meaning that it should be in a state where it can be released to customers.
The increment is inspected and adapted at the sprint review meeting.
The team reviews the increment and gets feedback from stakeholders. The team then uses this feedback to improve the product before the next sprint.
By using the Scrum artifacts and following the Scrum events, teams can deliver products and services quickly and efficiently.
Scrum Artifacts and Their Related Scrum Events
- Related Scrum Event: Backlog Refinement
- Explanation: Backlog Refinement is the Scrum event where the Scrum Team collaboratively reviews and refines the items in the Product Backlog. During this event, the team discusses upcoming user stories, tasks, or other backlog items to ensure they are well understood, estimated, and ready for future Sprint Planning.
- Related Scrum Event: Sprint Planning
- Explanation: During the Sprint Planning event, the Developers select a set of Product Backlog items to work on during the upcoming Sprint. These selected items are moved from the Product Backlog to the Sprint Backlog, which represents the work the team commits to completing during the Sprint.
- Related Scrum Event: Sprint Review
- Explanation: The Increment is the sum of all the Product Backlog items that have been completed during the current Sprint, plus the increments of all previous Sprints. The Sprint Review is the event where the Scrum Team and stakeholders inspect the Increment and provide feedback. The team demonstrates the completed work to stakeholders during the Sprint Review.
Definition of Done (DoD):
- Related Scrum Event: Throughout the Sprint
- Explanation: The Definition of Done is not tied to a specific event but rather is applied throughout the Sprint. It defines the criteria that a Product Backlog item must meet for it to be considered complete and potentially shippable. Every time a Development Team member completes a task, they ensure it meets the Definition of Done before marking it as done.
Introduction to The Real Scrum Guide 2024.
Scrum is an agile framework that helps manage complex projects through an iterative, incremental approach. To understand how Scrum works in practice, let’s walk through an exercise for developing an autonomous electric vehicle (AEV).
The Real Scrum Guide 2024. will demonstrate Scrum concepts like user stories, story points, sprint planning, and retrospectives.
By the end, we’ll have a good grasp of how Scrum enables flexibility, collaboration, and continuous improvement even in uncertain, fast-paced environments.
The lessons we learn can be applied to any complex project that requires cross-functional teamwork, adaptive planning, and delivering value iteratively.
Through my work, I’ve encountered several insights and challenges related to the Agile Manifesto.
Before we dive into the Real Scrum Guide 2024, let’s take a moment to explore the Agile Manifesto and its potential for an update.
Over the past two decades, Agile has evolved in response to seismic shifts in technology, business models, and culture. As we contemplate the need for an Agile Manifesto 2023 Update, we’ll reflect on its enduring values and principles. So, join me in this exploration as we consider the essence of Agile and its relevance in the modern era.
The Timeless Agile Manifesto Values and Principles
In February 2001, 17 software development luminaries came together to create the Agile Manifesto. This landmark document codified four core values and twelve principles that laid the groundwork for a more adaptive approach to building technology.
Agile Manifesto Values
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Agile Manifesto Principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, with a preference for shorter timescales.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity—the art of maximizing the amount of work not done—is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Over Two Decades of Agile Excellence
Fast forward over 20 years, and the Agile Manifesto’s values and principles still resonate with teams worldwide. They have enabled countless organizations to deliver value efficiently, embrace change, and foster collaboration. Yet, in these two decades, we’ve witnessed seismic shifts in systems, business models, and culture.
Is It Time to Reevaluate?
Given the dynamic nature of today’s technology landscape, it’s natural to wonder if the specifics of the original manifesto are due for a refresh. The Agile Manifesto 2023 Update aims to retain the timeless spirit of Agile while adapting to the demands of the modern era.
If you’re curious and ready to challenge the original Agile Manifesto, visit [URL] to explore proposed updates and join the conversation about the future of Agile.
Now that we’ve revisited the Agile Manifesto and its potential for an update, let’s bridge that understanding into our journey through the Real Scrum Guide 2024.
Just as Agile has evolved over the years, the Scrum framework continues to adapt to meet the ever-changing demands of the software development landscape.
In the following sections, we will explore how the core principles of Agile seamlessly integrate into the Real Scrum Guide 2024, providing you with a comprehensive and up-to-date understanding of how to thrive in the world of Agile project management…
Exercise 1 – Tackling a Complex Project
The Real Scrum Guide 2024 uses a sample project to demonstrate Scrum concepts.
- Project: “Development of an Autonomous Electric Vehicle (AEV)”
- Project Description: Our project involves developing an Autonomous Electric Vehicle (AEV) with cutting-edge technology to revolutionize transportation. The AEV aims to be fully self-driving, electrically powered, and capable of seamlessly navigating urban environments. This innovative project has the potential to transform the way people commute, reducing carbon emissions and promoting sustainable mobility.
Before we continue with our Scrum exercise, let’s cover Project Uncertainties in general.
Introduction to Project Uncertainties
The Real Scrum Guide 2024 uses a sample project to demonstrate project uncertainties.
In any project, uncertainties refer to potential risks, challenges, or unknown factors that may impact the project’s success. These uncertainties can arise from various sources, such as ambiguous requirements, technological complexities, external dependencies, resource limitations, and changes in the business environment.
Identifying and understanding these uncertainties is crucial for effective project management and successful delivery.
Importance of Discovering Uncertainties Early
The importance of discovering uncertainties as early as possible cannot be overstated, and The Real Scrum Guide 2024 emphasizes several compelling reasons for this.
- Risk Mitigation: Early identification allows project teams to proactively plan for and mitigate potential risks, minimizing their impact on the project’s progress.
- Resource Allocation: Understanding uncertainties helps in allocating resources more effectively, ensuring they are available when needed the most.
- Estimation Accuracy: By uncovering uncertainties early, project estimations become more accurate, providing stakeholders with realistic timelines and budgets.
- Stakeholder Alignment: Identifying uncertainties enables clear communication with stakeholders about potential challenges, ensuring shared understanding and buy-in.
- Adaptability: Early discovery allows the team to adapt plans and strategies to address uncertainties and changing project conditions.
Identifying uncertainties is a collaborative effort involving various project stakeholders, including:
- Product Owner: He has a crucial role in clarifying requirements and potential business risks, contributing to uncertainty identification.
- Developers: Team members actively participate in discussions, leveraging their technical expertise to recognize potential challenges.
- Subject Matter Experts: Experts in relevant domains (in our case, AEV experts) provide insights into specific uncertainties related to their areas of expertise.
- Stakeholders: Valuable input can come from external stakeholders, customers, or end-users who provide perspectives on potential risks and uncertainties.
By involving all relevant parties in the uncertainty discovery process, the project team gains a comprehensive understanding of potential challenges and can implement appropriate strategies to navigate uncertainties successfully throughout the project lifecycle.
Now, let’s continue with our Scrum Exercise. Our team has identified 5 uncertainties:
Uncertainty 1: Technological Challenges
Developing the necessary technology for a fully autonomous vehicle is a significant uncertainty. Advanced artificial intelligence algorithms, sensor integration, and real-time decision-making capabilities are just a few of the complex challenges we’ll face.
Uncertainty 2: Regulatory and Legal Compliance
The development of autonomous vehicles is relatively new, and regulatory bodies are still in the process of defining guidelines and standards. Complying with these regulations and ensuring the AEV’s safety and legality will pose uncertainty during the project.
Uncertainty 3: Supply Chain and Vendor Dependencies
Creating an AEV involves numerous components, systems, and suppliers. Ensuring smooth coordination among all the vendors, managing dependencies, and avoiding potential delays in the supply chain are crucial uncertainties to address.
Uncertainty 4: Data Security and Privacy Concerns
Autonomous vehicles rely heavily on data collection and processing to operate efficiently. Ensuring robust data security and privacy measures to protect user information and prevent potential cyber-attacks is another critical uncertainty.
Uncertainty 5: Stakeholder Expectations
As a groundbreaking project, various stakeholders will have high expectations regarding the AEV’s performance, safety, and environmental impact. Managing and meeting these diverse expectations will require effective communication and constant alignment.
While this project holds immense potential, these uncertainties make it challenging to estimate the exact timeline and effort needed for its successful completion.
Now, let’s move on to Exercise 2 and explore how breaking down the project into smaller tasks can help address these uncertainties effectively.
Introduction to key Scrum principles
Transparency is essential for effective teamwork and collaboration. By being transparent about the project’s goals, requirements, and progress, team members can stay aligned and work together effectively. In the context of breaking down the AEV project into themes and user stories, transparency can be achieved by:
- Clearly defining the project’s goals and objectives.
- Documenting the project’s requirements in a way that is understandable to all stakeholders.
- Sharing the project’s progress with stakeholders regularly.
Inspection is regularly reviewing the project’s progress to identify potential problems or risks. By inspecting the project regularly, teams can take corrective action early on and avoid major problems down the road. In the context of breaking down the AEV project into themes and user stories, the inspection can be achieved by:
- Conduct regular status meetings to review the project’s progress.
- Conducting peer reviews to ensure that the project’s deliverables meet the required quality standards.
- Conduct user acceptance testing to ensure that the project’s deliverables meet the needs of the users.
Adaptation is the process of making changes to the project plan in response to new information or changing circumstances. By being adaptable, teams can ensure that the project remains on track and meets its goals, even in the face of unexpected challenges. In the context of breaking down the AEV project into themes and user stories, adaptation can be achieved by:
- Being open to feedback from stakeholders.
- Being willing to make changes to the project plan as needed.
- Being proactive in identifying and addressing potential problems.
By following these key Scrum principles, teams can break down the AEV project into themes and user stories in a way that is transparent, inspectable, and adaptable. This will help to ensure that the project is well-defined, well-managed, and ultimately successful.
Breaking Down the AEV Project into Themes and User Stories
The Real Scrum Guide 2024 uses a sample project to demonstrate breaking down into Themes and User Stories.
In Exercise 2, we will take on the challenge of breaking down the complex “Development of an Autonomous Electric Vehicle (AEV)” project into themes and create easily understandable user stories, even for individuals without a technical background. By doing so, we aim to simplify the project’s management and enhance collaboration among team members, stakeholders, and end-users.
What are Themes?
Themes are high-level, cohesive categories that group related user stories based on common objectives or areas of focus. They provide an organized structure to manage a project’s diverse requirements, features, and functionalities. By organizing user stories into themes, we gain simplicity clarity, and visibility into different aspects of the project, making it easier to prioritize and plan tasks effectively.
By applying the concept of themes and user stories, we can harness the power of simplicity and clarity to ensure a smooth and successful journey in developing the Autonomous Electric Vehicle. This exercise will empower us to approach the project with focus, agility, and a shared understanding of the goals, ultimately leading to a more successful outcome.
Breaking Down the Project into Themes
- Autonomous Driving Capability: This theme will focus on developing the AI algorithms and sensors necessary for the AEV to operate autonomously and safely navigate through traffic.
- Electric Powertrain: This theme will involve designing and implementing the electric powertrain system, including the battery, motors, and charging infrastructure, to ensure an environmentally friendly and efficient vehicle.
- User Experience and Interface: This theme will concentrate on creating an intuitive and user-friendly interface for passengers to interact with the AEV and feel comfortable during their journey.
- Safety and Compliance: This theme will address the regulatory requirements, safety standards, and rigorous testing necessary to ensure the AEV meets all legal and safety guidelines.
- Sustainability and Environmental Impact: This theme will focus on maximizing the AEV’s sustainability, minimizing its environmental footprint, and promoting eco-friendly transportation solutions.
Creating User Stories and Mapping to Themes
Now that we have successfully identified the themes for the “Development of an Autonomous Electric Vehicle (AEV)” project, let’s move on to the next step of the process.
Our goal is to create user stories and associate each user story with one of the themes we’ve established. By doing this, we will further clarify the project’s requirements and ensure that each user story aligns with specific objectives within the themes.
Let’s proceed with the user story creation and mapping to themes. Please feel free to contribute your ideas and insights throughout this collaborative exercise.
- As a commuter, I want the AEV to autonomously navigate through city traffic, so I can relax and enjoy a stress-free commute to my destination. (Theme: Autonomous Driving Capability)
- As an environmental enthusiast, I want the AEV to be powered by electricity, so I can contribute to reducing carbon emissions and promoting a cleaner environment. (Theme: Electric Powertrain)
- As a visually impaired passenger, I want the AEV’s user interface to be accessible and easy to use, so I can independently request the vehicle’s services. (Theme: User Experience and Interface)
- As a regulator, I want the AEV to comply with all safety and legal requirements, so I can confidently endorse its operation on public roads. (Theme: Safety and Compliance)
- As a sustainability advocate, I want the AEV’s materials and manufacturing process to be eco-friendly, so I can support a vehicle that aligns with my values. (Theme: Sustainability and Environmental Impact)
- As a parent, I want the AEV to have advanced safety features, so I can trust my child’s safety during transportation. (Theme: Safety and Compliance)
- As a business owner, I want to partner with the AEV project to offer sustainable transportation solutions for my employees, reducing their carbon footprint. (Theme: Sustainability and Environmental Impact)
- As a city planner, I want to integrate AEVs into our urban mobility plans, so we can improve traffic flow and reduce congestion in our city. (Theme: Autonomous Driving Capability)
- As a technology enthusiast, I want to learn about AEV’s AI algorithms and sensors, so I can appreciate the innovative technology behind its autonomous capabilities. (Theme: Autonomous Driving Capability)
- As a tourist, I want the AEV’s user interface to provide information about the city’s landmarks during the ride, so I can enjoy a guided tour experience. (Theme: User Experience and Interface)
Prioritizing User Stories and Defining Acceptance Criteria
For this example, let’s prioritize the user stories and select the one positioned at the top of the list. Then, we’ll proceed to create acceptance criteria for this user story, which will provide specific, measurable conditions that must be met for the story to be considered complete.
Acceptance Criteria (AC) are measurable and testable conditions that determine whether a user story has been successfully implemented and meets the intended requirements.
NOTE: This process should be continued for each of the 10 identified and prioritized user stories. By systematically establishing acceptance criteria for all user stories, we ensure that each piece of functionality is well-defined, aligned with the project’s goals, and ready for efficient implementation by the developers.
TOP PRIORITY User Story: (EXAMPLE)
As a technology enthusiast, I want to learn about AEV’s AI algorithms and sensors so that I can appreciate the innovative technology behind its autonomous capabilities. (Theme: Autonomous Driving Capability)
- The AEV’s AI algorithms and sensor functionalities are documented in clear and understandable language.
- A presentation or document is created to explain the technology’s workings, highlighting its innovative aspects.
- The information is made accessible to the technology enthusiast through a designated platform (e.g., a web page or presentation session).
From Prioritization to Task Splitting, Developer Assignment, and Estimation
Splitting the User Story into Tasks enables a more granular breakdown of work, facilitates effective collaboration among team members, and enhances the project’s manageability and progress tracking.
We have 5 tasks for this user story: As a technology enthusiast, I want to learn about AEV’s AI algorithms and sensors, so I can appreciate the innovative technology behind its autonomous capabilities.
- Research and Gather Information: Research the AI algorithms and sensor technologies used in the AEV, and gather relevant technical documentation.
- Create Presentation/Document: Prepare a presentation or a document explaining AEV’s AI algorithms and sensor functionalities in a manner understandable to a technology enthusiast.
- Review and Validate Content: Have subject matter experts review the presentation/document to ensure accuracy and completeness.
- Design an Accessible Platform: Decide on a suitable platform (e.g., a web page or presentation session) to make the information accessible to the technology enthusiast.
- Publish Content: Make the presentation/document available on the designated platform for the target audience to access.
Appointing Developers to Tasks
John will be responsible for Task 1, as he possesses the expertise and skills required to handle the research and gathering of information.
Joanna will take charge of Task 2, leveraging her expertise in creating presentations and documents to explain AEV’s AI algorithms and sensor functionalities understandably.
Task 3 – Review and Validate Content: Emily will be responsible for this task. Her attention to detail and subject matter expertise make her the ideal candidate to review and validate the content of the presentation/document.
Task 4 – Design Accessible Platform: Alex, with a strong background in user experience and interface design, will take charge of this task, ensuring the platform chosen is accessible and user-friendly.
Task 5 – Publish Content: Sarah will be responsible for publishing the presentation/document on the designated platform. Her organizational skills and attention to timelines make her a reliable choice for this task.
By assigning specific tasks to developers based on their expertise and skills, we can ensure efficient collaboration and a higher likelihood of successful execution for each part of the user story.
Story Points Estimation
Based on historical data and complexity, the team has agreed that this user story is relatively simple.
Upon splitting the user story into tasks and appointing different developers, the estimation for the individual tasks may vary based on their complexity and the effort required. It’s essential to reevaluate the estimation for each task to ensure accuracy and provide a more granular representation of the work involved.
While the initial user story was estimated as 2 story points, the individual tasks may be assigned story points based on their relative complexity compared to the original user story. The team can conduct a collaborative effort to estimate each task’s story points, taking into consideration factors such as technical challenges, dependencies, and skill levels required for execution.
Updating the estimation for the tasks helps the team understand the effort needed for each specific piece of work and facilitates effective sprint planning and resource allocation. It enables a more accurate assessment of the team’s capacity and aids in making informed decisions about prioritization and project timelines.
By assigning specific tasks to developers based on their expertise and skills, the team enables efficient collaboration and increases the likelihood of successful execution for each part of the user story.
However, as work begins on the tasks during the Sprint, the Developers may gain new insights that require revisiting earlier estimates.
Backlog Refinement in Action
The Developers regularly refine and groom the Product Backlog to incorporate new insights and prepare items for upcoming Sprints.
During Backlog Refinement, the Developers may:
- Split or combine Product Backlog items as needed
- Clarify requirements and user stories
- Re-estimate effort based on new insights
- Add details like acceptance criteria
Reviewing the Definition of Done with the User Story
In this scenario, the Scrum Team collectively reviews their Definition of Done and applies it to the user story they are working on.
They go through each task of the user story, checking if it meets the criteria outlined in the Definition of Done. By doing so, the team ensures that their work is of high quality and potentially shippable at the end of the Sprint.
Team Members: John (Developer), Joanna (Developer), Emily (Developer), Alex (Developer), Sarah (Developer), Jane (Scrum Master), and Dejan (Product Owner).
Jane (Scrum Master): Good morning, team! Today, let’s review our Definition of Done and apply it to the user story we have for this Sprint. Dejan, as the Product Owner, your input and guidance are invaluable during this process. As a quick reminder, the Definition of Done outlines the criteria that must be met for a Product Backlog item to be considered complete and potentially shippable. It ensures that our work meets the highest quality standards before we present it during the Sprint Review.
Dejan (Product Owner): Thank you, Jane. I’m glad to be part of this discussion. We need to ensure that the work meets our quality standards and delivers value to our customers.
John: Sure, Jane. I have the Definition of Done document here. It covers functionality, acceptance criteria, quality assurance, documentation, peer review, demonstration, and having no outstanding defects.
Jane: Great! Now, let’s take a look at the user story we are working on: “As a technology enthusiast, I want to learn about AEV’s AI algorithms and sensors, so I can appreciate the innovative technology behind its autonomous capabilities.”
Joanna: Okay, the first task is to Research and Gather Information. According to the DoD, we need to ensure that all the relevant technical documentation is gathered, and the research is complete. Have we fulfilled that criterion?
John: Yes, we have conducted thorough research on the AI algorithms and sensor technologies used in the AEV. The information is compiled and ready for use.
Jane: Excellent. Next, we have to Create a Presentation/Document. Joanna, did you prepare the presentation or document in a manner understandable to a technology enthusiast?
Joanna: Yes, I have prepared a comprehensive presentation that explains AEV’s AI algorithms and sensor functionalities clearly.
Jane: Well done. Task 3 is Review and Validate Content. Emily, have you had the subject matter experts review the presentation to ensure its accuracy and completeness?
Emily: Absolutely. The subject matter experts have reviewed the content, and we’ve incorporated their feedback to ensure accuracy.
Jane: Perfect. Task 4 is Design an Accessible Platform. Alex, have you decided on a suitable platform to make the information accessible to the technology enthusiast?
Alex: Yes, we’ve decided to create a dedicated web page to host the presentation, making it easily accessible to the target audience.
Jane: Great choice. Finally, Task 5 is Publish Content. Sarah, did you make the presentation available on the designated platform?
Sarah: Yes, the presentation is live on the web page, ready for the audience to access.
Jane: Excellent work, team! It looks like we have successfully met all the criteria in our Definition of Done for this user story. By doing so, we have a potentially shippable increment of work.
Emily: This process helped us ensure that our work is of high quality and meets the agreed-upon standards.
Jane: Precisely. Regularly using our Definition of Done during Sprint Review helps us stay focused on delivering valuable and high-quality increments. Keep up the great work, everyone!
Enhancing User Story through Backlog Refinement
By incorporating the Definition of Done review during Backlog Refinement, the team ensures that each user story meets the highest quality standards before entering the Sprint.
This collaborative effort between the Product Owner and Developers allows for a clear understanding and alignment with the customer’s needs and vision. Let’s see how the team used Backlog Refinement to further enhance a high-priority user story.
Here is what happens in our team.
- During Backlog Refinement, the Product Owner and Developers review this user story which is a high priority for the next Sprint.
- The team realizes that “safety and legal requirements” are vague. They need to understand the specific regulations to implement this.
- The Product Owner invites a subject matter expert from the regulatory compliance team to the meeting.
- The SME explains the key regulations including safety testing, traffic rules, vehicle inspections, etc. that the AEV must comply with.
- Based on this input, the Developers suggest splitting this into multiple user stories, one for each regulation.
- The Product Owner agrees to split the user story into:
- “As a regulator, I want the AEV to pass safety testing requirements.”
- “As a regulator, I want the AEV to follow traffic rules.”
- “As a regulator, I want the AEV to pass annual vehicle inspections.”
- The Developers then add detailed acceptance criteria for each of these new stories based on the SME’s input.
- Finally, they re-estimate the overall effort for the new stories and update the Product Backlog accordingly.
- The Product Owner thanks the SME for their time and input.
In this way, the team used Backlog Refinement to clarify an unclear requirement and split it into actionable, detailed user stories for the Development Team. This set the foundation for a successful Sprint.
By continually refining the Product Backlog, the Development Team ensures the top items are shovel-ready for Sprint Planning. This allows them to incorporate new information and learning, keeping estimates up-to-date.
Before we conclude…
The Real Scrum Guide 2024. walked us through breaking down a complex, uncertain project into actionable user stories, estimating effort using story points, appointing developers, and planning sprints.
With the help of The Real Scrum Guide 2024, we have effectively deconstructed the intricate ‘Development of an Autonomous Electric Vehicle (AEV)’ project into manageable themes and formulated user stories that are accessible to individuals outside the tech industry.
By organizing our requirements into themes, we gained clarity and focus on different aspects of the project, enabling effective prioritization and planning.
Furthermore, we defined acceptance criteria for each user story, providing clear guidelines on what constitutes a successful implementation.
This process ensures that our user stories are well-defined and aligned with the project’s objectives, fostering efficient implementation by the developers.
We then proceeded to split the top-priority user story into tasks, assigning each task to the appropriate developer based on their expertise and skills. This approach fosters effective collaboration among team members and optimizes our chances of successful execution.
As we continue this process for each of the ten identified and prioritized user stories, we move forward with confidence, knowing that our project is well-structured, our goals are well-defined, and our team is equipped to deliver value to all stakeholders.
So far in The Real Scrum Guide 2024, what conclusions have we reached?
- Scrum is iterative: Scrum breaks down the project into short, iterative sprints. This allows the team to deliver value to the customer more quickly and frequently. It also allows the team to adapt to changes in the project’s requirements or environment.
- Scrum is flexible: Scrum allows the team to change the project’s plan as needed. This is because the team plans and executes the project in short sprints. If the team encounters a problem or a change in requirements, they can adjust the plan for the next sprint.
- Scrum encourages collaboration: Scrum requires the team to work together to deliver the project. The team consists of the product owner, Scrum master, and developers. The product owner represents the customer and defines the project’s requirements. The Scrum master helps the team to follow Scrum and to resolve any issues that may arise. The developers are responsible for developing the product.
- By being iterative, flexible, and collaborative, Scrum enables teams to deliver value to the customer more quickly and efficiently.
By embracing Agile principles, effective communication, and collaborative decision-making, we set ourselves up for a successful journey in developing the groundbreaking Autonomous Electric Vehicle, bringing us closer to a future of sustainable and innovative transportation solutions.
Let’s maintain our focus and determination as we progress through the project, knowing that we can achieve great results together as a team.
The following document, titled “The Real Scrum Guide 2024,” aims to provide insights into one possible way of implementing Scrum. However, it is essential to acknowledge that Scrum is a flexible framework, and some various interpretations and implementations can be effective based on unique circumstances.
The information presented in this guide is not exhaustive, and it may not cover every scenario or address specific situations that teams might encounter. Therefore, it should not be considered the definitive or only way to run Scrum.
Furthermore, it is crucial to understand that this guide is a work in progress. As the world of technology, business, and project management continues to evolve, so does Scrum. Therefore, this guide will remain a living document, continuously subject to updates and improvements.
Your constructive contribution to the ongoing development of this guide is highly appreciated. Your insights, suggestions, and experiences can help enhance the content and make it more valuable for the broader Scrum community.
While efforts have been made to ensure the accuracy and relevance of the information provided, we cannot guarantee its completeness or suitability for specific purposes. Consequently, the use of the information presented in this guide is at your discretion and risk.
Before implementing any practices or processes based on this guide, it is advisable to consult with experienced Scrum practitioners and tailor the approach to best fit your organization’s unique needs and context.
By accessing or using this document, you agree that the authors, contributors, and publishers are not liable for any direct, indirect, incidental, or consequential damages arising from the use of the information contained herein.
Thank you for your understanding and for being a part of the continuous improvement journey of “The Real Scrum Guide 2024.” Together, we can shape the future of Scrum and enhance its impact on organizations worldwide.
The Real Scrum Guide is a work in progress, and it will remain so. If you’d like to contribute, please don’t hesitate to share your insights. I would be more than happy to include them in this guide. Also, check our Scrum Blog for the latest info.
— Dejan Majkic