Chapter 12. Agile (Adaptive) Project Management
12.3 Scrum
12.3.1 Scrum Roles
The fundamental unit of Scrum is a small team of people, a Scrum Team. This team comprises a Scrum master, developers, and a product owner. There are no hierarchies among the members or sub-teams within the team. The Scrum rules clearly state that a person, not a committee, fills the Product Owner and Scrum Master roles. The team size generally does not exceed ten members. The small team size ensures that the team can remain nimble and large enough to complete significant work within a sprint by communicating better and being more productive. If more people are needed to create a product or service as an outcome of the project, more than one team is established with sub-goals to achieve a common product goal. These cohesive Scrum teams work together by focusing on the same product and sharing the same product goal, product backlog, and product owner
12.3.1.1 Scrum Master
The Scrum Master is responsible for ensuring the Scrum process is upheld, working to ensure the Scrum team adheres to the practices and rules, and coaching the team on removing impediments[4]. The Scrum Master helps the team focus on creating high-value increments that meet the “Definition of Done” and ensures that all Scrum events take place and are positive, productive, and kept within the timebox[5]
Definition of Done (DoD)
The differences between a Scrum Master and a traditional project manager are:
1. Focus and Responsibilities:
- Scrum Master: The Scrum Master is primarily a facilitator for the agile team, ensuring that Scrum practices are followed and helping the team work efficiently within the framework. They focus on removing obstacles that hinder the team’s progress, coaching the team on self-management, and protecting it from external interruptions. The Scrum Master also facilitates Scrum ceremonies such as Sprint Planning, Daily Standups, Sprint Reviews, and Retrospectives.
- Project Manager: In contrast, a traditional Project Manager is responsible for planning, executing, and closing projects. They have a broader focus that includes defining the project scope, developing the project plan, managing the project budget, scheduling, and overseeing all aspects of the project. The Project Manager often makes key decisions and has authority over the team, guiding the project to meet its objectives within time and budget constraints.
2. Approach to Team Leadership:
- Scrum Master: The Scrum Master takes a servant-leader approach, meaning they lead by serving the team, fostering a collaborative environment, and empowering team members to take ownership of their work. The Scrum Master does not manage the team directly but guides the team to be self-organizing and autonomous.
- Project Manager: The traditional Project Manager typically has a more directive and controlling leadership style. They are often seen as the authority figure within the project, making decisions on behalf of the team, assigning tasks, and ensuring that team members follow the project plan and schedule.
3. Scope and Flexibility:
- Scrum Master: In Scrum, the focus is on delivering increments of the product in short, iterative cycles, with the flexibility to adapt to changes and new requirements. The Scrum Master supports this flexibility, encouraging the team to embrace change and continuously improve processes.
- Project Manager: Traditional Project Managers work within a more rigid framework, often guided by detailed project plans, timelines, and predefined scope. They typically manage change through formal change control processes, which can be less flexible and slower to respond compared to the iterative approach in Scrum.
4. Interaction with Stakeholders:
- Scrum Master: The Scrum Master’s role involves ensuring that the Product Owner and team members communicate effectively with stakeholders, but they are not usually the main point of contact. The Product Owner often takes the lead in managing stakeholder expectations and ensuring the team delivers value to the business.
- Project Manager: The traditional Project Manager is often the primary point of contact for stakeholders, responsible for communication, reporting progress, managing expectations, and ensuring that the project meets stakeholder requirements.
12.3.1.2 Developers
In Scrum, developers are the team’s cornerstone and are responsible for delivering a usable increment at the end of each sprint. The specific skills developers require can vary widely depending on the work domain, but their accountability remains consistent across all Scrum Teams.
Developers are entrusted with creating a plan for the sprint, known as the Sprint Backlog. This plan is collaboratively developed, with the entire Scrum Team participating in the planning process. Unlike traditional project management, where a single person dictates the plan, Scrum emphasizes self-organization, allowing developers to collectively decide what will be delivered and how it will be achieved. They hold each other accountable, ensuring that quality is maintained by adhering to the Definition of Done.
The planning process is dynamic and ongoing. While the initial plan is set during Sprint Planning, it is continuously adapted as the team checks in with each other during the Daily Scrum. Each developer communicates their next steps to the team, and if any issues arise, the team works together immediately to address them. This iterative approach ensures that the team remains aligned with the Sprint Goal, making necessary adjustments to deliver the best possible outcome.
This emphasis on collaboration, accountability, and flexibility enables Developers to consistently meet the demands of each Sprint, delivering high-quality increments that contribute to the project’s overall success.
12.3.1.3 Product Owner
The Product Owner plays a critical role in a Scrum Team by ensuring that the team builds the most valuable product possible, closely aligned with users’ needs. They work daily with the team to help them understand the features in the Product Backlog, why they are important, and how they meet users’ needs. The Product Owner is accountable for maximizing the product’s value resulting from the team’s efforts, a responsibility that can vary significantly across different organizations and teams.
Effective Product Backlog management is a key aspect of the Product Owner’s role. This includes developing and clearly communicating the Product Goal, creating and ordering Product Backlog items, and ensuring that the backlog is transparent and understood by everyone involved. While the Product Owner may delegate some of these tasks, they remain ultimately accountable for the outcome.
For the Product Owner to be successful, their decisions must be respected across the organization. These decisions are reflected in the ordering and content of the Product Backlog and are made visible through the inspectable Increment during the Sprint Review. Importantly, the Product Owner is a single person, not a committee. While they represent the needs of multiple stakeholders, any changes to the Product Backlog must be made through them.
12.3.2 Scrum Events & Artifacts
As seen in Figure 12.3.1, the Scrum framework is an iterative process with interconnected components. Product Goal guides the process that begins with a Product Backlog, where prioritized user stories are stored. After the backlog items are refined, the Scrum Team selects user stories to include in the Sprint Backlog. Then, the Sprint Backlog guides the Sprint Cycle, where the team of developers works on the tasks of the user stories and has daily meetings to discuss progress and address obstacles with the Scrum Master and Product Owner. The output of the Sprint Cycle is a potentially shippable product increment, which is an incomplete but working product. The Product Owner and stakeholders can provide feedback on this increment in the Sprint Review, where the increment is demonstrated to stakeholders. It is followed by the Sprint Retrospective, where the team reflects on the process to identify improvements. As a part of a continuous loop that highlights the iterative nature of Scrum, the Product Backlog is refined and updated, which leads to another Sprint.
Scrum events:
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Scrum artifacts:
- Product Backlog
- Sprint Backlog
- Increments
In this section, we will start with the “Product Roadmap” and continue with the Scrum events and artifacts.
12.3.2.1 Product Roadmap
Although a Product Roadmap is not considered a Scrum artifact, including the roadmap in the Scrum project can provide valuable strategic context and long-term vision for the Scrum team. It ensures their work on the Product Backlog aligns with broader business goals and market demands. This alignment helps the team prioritize work more effectively and maintain focus on delivering features that contribute to the overall product strategy.
Product Roadmap
-
A plan of action for how a product or solution will evolve over time.
-
Outlines future product functionality and when new features will be released.
-
The context for the team’s everyday work and future vision.
-
Should be responsive to shifts in the competitive landscape.
The Product Roadmap is a high-level strategic plan that outlines the product’s vision, direction, and major goals over time. It provides a timeline for when new features or major updates are expected to be released, helping to align product development with business goals and market demands. The roadmap typically focuses on the “what” and “why” aspects of product development, offering a broad view of the product’s evolution and future direction. Table 12.3.1 provides an example of a goal-oriented product roadmap[7].
Table 12.3.1: A Goal-Oriented Product Roadmap
| Q1 (Bronze 01-01-2020) | Q2 (Silver 01-04-2020) | Q3 (Gold 01-07-2020) | Q4 (Platinum 01-10-2020) | |
| Goal | Launch MVP with at least 1000 early adopter users | Improve early adopter user satisfaction to an 8+ on average | Convert 50% of early adopters to a paying membership with at least a basic subscription | Increase user base with at least 1000 more paying subscribers (at least basic membership) |
| Features | Homepage with Top 10 most read articles Share with your friends via social media |
Save articles for later reading Launch in-app customer feedback functionality |
Personalized search function Migrate the current user base to the new app version Launch first third-party APIs |
Launch marketing campaign in the USA Integrate video subscriptions in the new app Integrate QuickNews |
| Metrics | # App Downloads # Registered Users # Social Media Mentions |
In-app customer satisfaction score Customer satisfaction survey |
In-app customer satisfaction score % Paying users of all users # Registered Users |
In-app customer satisfaction score % Paying users of all users # Registered Users |
12.3.2.2 Product Backlog
Let’s continue with the Product Backlog before diving into the Sprint and Sprint Planning to underscore its critical role in the Scrum framework. The Product Backlog serves as the foundation for all work in Scrum, representing a prioritized list of everything that might be needed in the product. It is an evolving, ordered list that is essential for guiding the team’s efforts and ensuring that they are always working on the product’s most valuable features.
Creating User Stories
User stories are more detailed elements derived from the broader epics within the Product Backlog. An epic is a large body of work that can be broken down into a number of smaller stories[8].
The Product Backlog is comprised of user stories. The Product Owner plays a pivotal role in creating user stories, ensuring that they accurately reflect stakeholder requirements and are prioritized according to the value they bring to the user. This role is critical because it involves constant communication with stakeholders to gather requirements and feedback, which is then used to inform and refine the Product Backlog.
User stories describe specific pieces of functionality from the user’s perspective and follow a simple template:
“As a [user], I want to [functionality] so that [benefit].”
This format ensures that each story is aligned with user needs and the overall product vision.
- As a <customer>, I want to <see the catalog of items that can be sold> so that <I can order one of them>.
- As an <administrator>, I want to <be able to disable accounts> so that <I can prevent unauthorized access or misuse of the system to ensure the security and integrity of the platform>.
- As a <trainee>, I must <answer all the questions> so that <I can demonstrate my understanding and readiness to progress to the next stage of my training or certification>.
User Stories of the “Bookstore Website and Mobile App” Project
Our agile team targets developing a website and a mobile application through which customers can purchase books. We can consider several epics such as User Management, Book Catalogue, Shopping Cart, and Payment and Checkout. Each epic can be broken down into more detailed user stories:
- Epic 1: User Management
- User Story 1: “As a new visitor, I want to register an account so that I can securely save my payment and shipping information for future orders and track my purchase history.”
- User Story 2: “As a registered user, I want to log in using my email and password to access my account so that I can manage my personal details, view past orders, and continue shopping seamlessly.”
- User Story 3: “As a registered user, I want to reset my password if I forget it so that I can regain access to my account without assistance and maintain my security and privacy.”
- Epic 2: Book Catalogue
- User Story 1: “As a user, I want to search for books by title or author so that I can quickly find what I’m looking for.”
- User Story 2: “As a user, I want to view book details, including the synopsis, author, price, and ratings, so that I can make an informed decision before purchasing a book.”
- User Story 3: “As a user, I want to see recommended books on the homepage based on my previous purchases so that I can discover new books that match my interests without having to search for them.”
- Epic 3: Shopping Cart
- User Story 1: “As a shopper, I want to add books to my shopping cart so that I can conveniently collect all the books I want to buy in one place before proceeding to checkout.”
- User Story 2: “As a shopper, I want to view the items in my cart, including quantity and total price, so that I can review my selections and ensure everything is correct before completing my purchase.”
- User Story 3: “As a shopper, I want to remove items from my cart if I change my mind so that I can adjust my order and only purchase the items I truly want.”
- Epic 4: Payment and Checkout
- User Story 1: “As a buyer, I want to choose between different payment methods (e.g., credit card, PayPal) to pay for my order so that I can use the most convenient and preferred payment option available.”
- User Story 2: “As a buyer, I want to receive an email confirmation after I’ve successfully placed an order so that I have proof of my purchase and can track the status of my order.”
- User Story 3: “As a buyer, I want to choose gift wrapping for paper books during checkout so that I can present my purchase as a gift without needing to wrap it myself.”
12.3.2.3 Product Goal
The Product Goal is a key element within the Product Backlog that guides the Scrum Team toward the product’s future state. It serves as a long-term objective, providing a clear target for planning and development. The Product Goal is embedded in the Product Backlog. It shapes the direction of all other backlog items, which collectively define “what” needs to be done to achieve that goal.
Product Backlog of the “Bookstore Website and Mobile App” Project
To create a seamless and secure online book shopping experience by building a user-friendly platform where customers can easily register, search for books, manage their shopping carts, and complete purchases with multiple payment options while also ensuring personalized recommendations and account management features to enhance user satisfaction and loyalty.
This goal provides a clear direction for the Scrum Team. It focuses on key aspects like user registration, book browsing, shopping cart functionality, payment processing, and personalization. The team will deliver a product that meets user needs and business objectives by achieving this goal, driving value for all stakeholders.
12.3.2.4 Sprint
Now, we can start working on the user stories in our backlog to achieve the product goal. The whole Scrum project is divided into timeboxes of Sprints. A Sprint is the core element of Scrum. It is a short project with a set time limit, typically lasting no longer than one month but ranging from one week to two months. Scrum teams most commonly prefer a two-week sprint duration. Each Sprint starts immediately after the previous one ends, keeping work consistent and predictable. During this time, the team focuses on completing specific tasks and progressing toward the Product Goal.
Sprint Goal
- The Sprint Goal is the primary objective the team aims to achieve during the Sprint. It helps keep everyone focused and working together toward the same outcome.
- The Sprint Goal is set during Sprint Planning and stays the same throughout the Sprint.
- For our first Sprint in the “Bookstore Website and Mobile App” project, the Sprint Goal could be:
- “Enable users to register and log in to the system, ensuring account security and user data storage.”
- By keeping the Sprint Goal in mind throughout the Sprint, the team ensures that they’re always working toward the most important outcome.
- By the end of Sprint, we will have a working system where users can create accounts and securely log in.
Sprints help the team constantly check and adapt their progress toward the Product Goal, ensuring they always deliver value. If a Sprint gets too long, the risk of uncertainty or wasted effort increases. For this reason, shorter Sprints allow the team to learn more quickly and limit risks.
12.3.2.5 Backlog Refinement
The Product Owner presents the Product Backlog to the Scrum team. Before the Sprint Planning starts, backlog refinement (previously called grooming) is carried out when the Product Owner and the development team collaborate to review and discuss the items in the Product Backlog. This is when the team estimates the story points required to complete user stories in the upcoming Sprint. This session aims to ensure that user stories are well understood and appropriately sized and to address any dependencies or uncertainties. Estimation at this stage helps prioritize the backlog and ensure that the stories are ready for the upcoming sprint planning.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. Details, such as a description, order, and size, are added in this process[9].
The developers who will be doing the work are responsible for the sizing. The Product Owner may influence the developers by helping them understand and select trade-offs. This process is carried out before the Sprint Planning meeting during the sprint. It is not done immediately after the retrospective.
Issues
User stories can be broken down into smaller stories and tasks, and new items can be assigned in addition to user stories. Atlassian Jira is one of the software most utilized by agile teams. Jira lists user stories, tasks, and bugs as issues[10]. Issues may also relate to improvement, incidents, change requests, and problems.
In the example of the “bookstore website and mobile app development project” above, we used epics representing broad objectives or large bodies of work that can be broken down into stories, tasks, and bugs. Issues consist of stories and tasks representing work that must be completed to support those larger goals. Bugs, another issue in Jira, are problems that impede the progress or functionality of work. Finally, sub-tasks are granular pieces of work required to complete a story, task, or bug.
1. Reviewing and Refining User Stories
The Product Owner presents the user stories, particularly the high-priority ones, and starts the session by providing an overview of the project’s current state and any changes in business priorities.
Priority Ranking
Let’s assume that users have had a significant demand for the website and app to provide book recommendations based on their reading history. The user story for this stakeholder requirement was:
- “As a user, I want to see recommended books on the homepage based on my previous purchases so that I can discover new books that match my interests without having to search for them.”
Therefore, this user story might be moved up along the priority rank.
User Stories that Need Clarification
- “As a new visitor, I want to register an account so that I can securely save my payment and shipping information for future orders and track my purchase history.”
The team discusses the issues below to clarify this user story:
- What information is required for registration?
- Should the user be able to register with social media accounts?
- Do we need email verification?
- What fields are mandatory during registration? (e.g., Name, Email, Password, Address)
- Do we need CAPTCHA to verify that the user isn’t a bot?
Based on the discussions, the acceptance criteria for the story might be updated to provide clear answers.
Breaking Down Big Stories into Smaller, More Manageable Stories
- Current User Story: “As a user, I want to search for books by title or author so that I can quickly find what I’m looking for.”
We can consider the following questions:
- What are the search parameters? Title, Author, Genre, ISBN?
- Do we want to implement a full-text search?
- Should there be a feature for auto-suggestions?
After a discussion session within the team, they decided to have the new user stories below instead of the current user story:
- New User Story 1: “As a user, I want to search for books by title or author so that I can quickly find books that match these specific criteria.”
- New User Story 2: “As a user, I want to refine my book search with additional parameters (e.g., genre, ISBN) and receive auto-suggestions so that I can quickly and accurately find books that meet my criteria.”
The product backlog might have user stories that are no longer relevant due to changes in business goals or user feedback.
Removing or Updating Outdated Items
Initially, a story was about the “Gift wrapping” option during checkout.
- User Story 3: “As a buyer, I want to choose gift wrapping for paper books during checkout so that I can present my purchase as a gift without needing to wrap it myself.”
Based on market research, the team has determined that this feature is not a priority at the moment and has decided to either remove it from the Product Backlog or deprioritize it for a future sprint. This decision ensures that the team remains focused on higher-value features like payment options and order confirmation, which are more critical to the user experience at this stage.
2. Acceptance Criteria Review
Each user story has clear acceptance criteria, which specify the conditions the story must satisfy to be considered “done.”
Acceptance Criteria of the “Registering an Account” User Story
“As a new visitor, I want to register an account so that I can securely save my payment and shipping information for future orders and track my purchase history.”
- Users should see a “Register” option on the homepage.
- Clicking on it should open a registration form with fields: Name, Email, Password, Confirm Password, and Address.
- The password fields should enforce strong password requirements (e.g., minimum length, inclusion of numbers/special characters).
- All fields should be validated before submission, with clear error messages for incomplete or incorrect input.
- After successful registration, the user should receive a confirmation email with a verification link.
- Upon clicking the verification link, the account should be fully activated, and the user should be able to log in.
- Following industry-standard encryption practices, the system should securely store payment and shipping information.
- After registration and login, the user should be redirected to their account dashboard to view their purchase history and manage their saved payment and shipping information.
3. Definition of Done (DoD)
While the acceptance criteria define the specific functional requirements, the Definition of Done (DoD) ensures that every user story adheres to the team’s quality standards before being marked as complete. This includes not only meeting the acceptance criteria but also ensuring that the feature passes all necessary tests, meets regulatory and compliance standards, and is ready for delivery to stakeholders.
Each user story must meet the DoD before it can be considered complete. This includes meeting all acceptance criteria, passing tests, and adhering to compliance or regulatory requirements. The DoD ensures consistency and quality at the user story level. It also applies to product increments because they comprise multiple completed user stories. Each increment must meet the DoD to ensure it is fully functional, usable, and adds value to the product.
DoD for the “Registering an Account” User Story
“As a new visitor, I want to register an account so that I can securely save my payment and shipping information for future orders and track my purchase history.”
- Code Development: All registration code is complete, reviewed, and merged. The form includes fields for Name, Email, Password, Confirm Password, and Address.
- Testing: Unit, integration, and end-to-end tests are written and passed, covering all aspects of the registration process, including email confirmation.
- Security: Strong password policies are enforced, and all user data is encrypted. A security audit has been completed.
- Documentation: The registration process is documented for both users and developers.
- Confirmation Email: A confirmation email with a tested and accurate template is sent upon successful registration.
- User Experience: Users are redirected to their dashboard post-registration, and the interface is intuitive and accessible.
- Compliance: The process complies with relevant data protection regulations.
- Stakeholder Review: The feature is demonstrated and accepted during the Sprint Review with no critical issues.
By aligning the acceptance criteria with the DoD, we ensure that each product increment is complete and ready for release, contributing to the project’s overall success.
4. Story Point Estimation
The Product Owner in the Product Backlog indicates each story’s priority based on the feedback they received from the stakeholders. Therefore, the team works on estimating the points for each story most likely to be included in the upcoming sprint. However, the team doesn’t limit itself strictly to the stories for this sprint. The refinement process can involve looking ahead to ensure that stories for future sprints are also well-understood and properly sized. However, the primary focus is usually on top-priority stories that will most likely be tackled next.
The key aspects included in the story points are:
- Complexity: The team should consider the user story’s complexity, including the technical challenges and unknowns that might arise. Complex stories may require more time and resources to address potential risks and uncertainties.
- Time: The team should estimate the calendar time needed to complete the user story, considering the availability of team members, potential dependencies, and any potential delays.
- Labor and Skills: The team should evaluate the skill sets required to complete the story. If the story demands expertise that is scarce within the team or requires training, this could increase the estimate.
- Dependencies: The team should identify any dependencies on other teams, systems, or external factors affecting the ability to complete the story. Dependencies can introduce delays and should be factored into the estimate.
- Dependencies on Other Stories: The team should consider how the completion of a story might depend on or impact other stories in the backlog. This interdependence can affect the estimate.
- Resources: The team should consider the availability of resources such as software, hardware, or tools needed to complete the story. Limited resources can slow down progress and should be considered in the estimate.
- Risks: The team should assess any risks associated with the story, including technical risks, integration issues, or potential changes in requirements. Higher risks might lead to higher estimates to account for possible mitigation efforts.
- Team Experience: The team should factor in the team’s experience level with similar tasks. A team familiar with the technology and domain may complete the story faster than a less experienced team.
5. Story Point Estimation with “Planning Poker”
Once the key aspects of complexity, time, labor, and other factors have been considered, the team moves on to estimating the effort required for each user story. A common approach for the estimation process is Planning Poker, where team members individually assess the effort for a user story using a predefined scale. After discussing their estimates, the team converges on a consensus, often agreeing on a story point value that represents the story’s relative effort compared to others. For instance, if the team agrees that a user story requires medium effort and complexity, they might assign it ‘5’ story points.
a. Choosing an Estimation Scale:
- The team selects a scale for estimation, commonly using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc.) or a modified Fibonacci sequence (e.g., 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100). These scales account for increasing levels of uncertainty and complexity as the numbers grow larger. Figure 12.3.3 includes a card deck with a modified Fibonacci sequence.
- Alternatively, a T-shirt size scale (S, M, L, XL, XXL) can be used to categorize the size and effort of user stories in a more qualitative manner.
- Let’s consider that we selected the modified Fibonacci sequence.
- Cards:
- 0 (zero) indicates that a particular user story or task requires no effort or is negligible in terms of complexity. In other words, it suggests that the story is either already done, trivial to complete, or doesn’t require any additional development work.
- Infinity (∞) indicates that the story is too large or complex to estimate in its current form. This might prompt the team to break the story into smaller, more manageable parts.
- A question mark, “?”, is used when a team member feels uncertain about the estimate or believes more information is needed before an accurate estimate can be given.
- The Product Owner should supply the necessary information. If they cannot, the item should be shelved until enough information is available.
b. Creating a Baseline:
- Establishing a baseline helps in comparing other stories. The team can select two baselines:
- A simple baseline for low complexity
- This baseline represents a straightforward task or user story with minimal complexity and effort required.
-
The team should consider the simplest item in the business domain and technologies they are working in or a task often used in the team, project, and organization.
-
A user story like “As a registered user, I want to log in using my email and password to access my account” could be the simple baseline. This task might be estimated at two story points, assuming the login process is relatively standard and doesn’t involve significant complications.
- When the team encounters another story, they can ask, “Is this more or less complex than our simple baseline?” and adjust their estimate accordingly.
- The team can also select 1/2 or 1 for the simple baseline.
- A complex baseline for high complexity
- This baseline is for a more complex task that involves multiple steps, dependencies, or uncertainties.
- A user story like “As a user, I want to see recommended books on the homepage based on my previous purchases” could be used as the complex baseline. Given the need for personalized recommendations, data analysis, and integration with the user’s purchase history, this story might be estimated at 8 or 13 story points.
- For more challenging stories, the team can compare them to this complex baseline, asking, “Is this story more or less complex than our complex baseline?” This helps place the new story on the scale between the simple and complex baselines.
- A simple baseline for low complexity
Benefits of Using Two Baselines
- Relative Estimation: A simple and complex baseline provides a broader spectrum for relative estimation. It allows the team to gauge where new stories fall regarding effort and complexity.
- Improved Accuracy: Multiple baselines reduce the likelihood of overestimating or underestimating stories by providing concrete examples of different levels of complexity.
- Consistency: Using baselines helps maintain consistency in estimation across different sprints, ensuring that the same types of stories receive similar estimates.
c. Implement the Estimation Method “Planning Poker”:
- A deck of cards is allocated to each developer.
- The Product Owner reads an item from the Product Backlog with all the relevant details and contextual information.
- Each team member privately selects a card representing their estimate for the user story.
- They hide the cards and then reveal their estimate simultaneously, ensuring that no one is influenced by others’ opinions.
- Those with the lowest and highest estimate values should justify their estimates.
-
All of the team members are then called to give another estimate.
-
This process is repeated until a consensus has been reached.
-
The Product Owner reads the next item from the Product Backlog, and the process starts again.
-
Instead of reaching a consensus through iteration, the team may average the estimates to reach a single estimate value at the end.
Benefits of Revealing the Cards Simultaneously
- It avoids bias and peer pressure and ensures that all estimates are processed independently before a group discussion.
- It encourages honest and independent assessments, helping the team reach a consensus on the effort required for each user story.
d. Considering Edge Cases:
If a story appears too complex or the team struggles to estimate it within a reasonable range, symbols like “∞” and “?” can indicate uncertainty. This prompts further discussion or breaks the story into smaller, more manageable parts.
Table 12.3.2 provides the Product Backlog for the “Bookstore Website and Mobile App” Project with 12 user stories. The Product Owner ranked the priority for each story based on the feedback from the stakeholders. The developers in the Scrum team estimated the story points. It is important to remember that not all the story points are estimated before the first Sprint starts.
| User Story | Priority Rank | Story Points |
| As a new visitor, I want to register an account. | 1 | 5 |
| As a registered user, I want to log in using my email and password to access my account. | 2 | 3 |
| As a registered user, I want to reset my password if I forget it. | 3 | 2 |
| As a user, I want to search for books by title or author. | 4 | 5 |
| As a user, I want to view book details, including the synopsis, author, price, and ratings. | 5 | 3 |
| As a user, I want to see recommended books on the homepage based on my previous purchases. | 6 | 8 |
| As a shopper, I want to add books to my shopping cart. | 7 | 5 |
| As a shopper, I want to view the items in my cart, including quantity and total price. | 8 | 3 |
| As a shopper, I want to remove items from my cart if I change my mind. | 9 | 2 |
| As a buyer, I want to choose between different payment methods (e.g., credit card, PayPal). | 10 | 8 |
| As a buyer, I want to receive an email confirmation after placing an order. | 11 | 3 |
| As a buyer, I want to choose gift wrapping for paper books during checkout. | 12 | 5 |
12.3.2.6 Sprint Planning
Sprint Planning starts after Backlog Refinement (as detailed in 12.3.2.5), where the Product Owner and the development team review and estimate the Product Backlog items. This refinement ensures that user stories are well-understood, prioritized, and ready to be worked on during the Sprint. Once refinement is done, the Sprint Planning meeting takes place.
The Sprint Planning meeting is divided into two parts:
1. WHAT-Meeting: Deciding What Will Be Done in the Sprint
In this part of the meeting, the Scrum team defines the scope of the Sprint by selecting user stories from the Product Backlog. The team bases this selection on the priority the Product Owner sets, the estimated story points, and the team’s capacity (historical velocity or other metrics).
The Product Owner explains how the product can deliver value during this Sprint. Together, the team defines the Sprint Goal, which must be finalized by the end of this discussion. This Sprint Goal provides a clear focus and communicates the purpose of the Sprint to stakeholders.
Selecting User Stories for the First Sprint Backlog of the “Bookstore Website and Mobile App” Project
Prioritization by the Product Owner:
- The Product Owner is crucial in prioritizing the Product Backlog based on the business value, stakeholder needs, and overall product strategy. The most valuable and essential user stories are moved to the top of the backlog.
- Foundational features like “User Registration” and “Login” from the User Management epic might be prioritized first because they enable other application features.
Story Readiness:
- The team ensures that the selected user stories are well-defined, have clear acceptance criteria, and are small enough to be completed within a single sprint. If any stories are too large or unclear, they might be split or refined further.
Team Capacity and Velocity:
- The team’s capacity for the sprint (how much work they can handle) is considered. This is usually based on historical velocity (the amount of work completed in previous sprints) and team members’ availability.
- When it is the first sprint, the historical velocity is not available. Therefore, the factors to consider would be team member availability, team size, experience and expertise levels of team members, and reference projects. The team can monitor their progress against their estimates as the sprint progresses. This helps them to adjust their pace and recalibrate their expectations for future sprints.
Dependencies:
- The team considers any dependencies between stories. For example, completing “User Registration” before “Login” makes sense, as registration functionality is foundational to logging in.
Team Collaboration:
- The selection of user stories is a collaborative process between the Product Owner and the development team. The team might suggest adjustments to the priority based on technical insights or potential risks.
2. HOW-Meeting: Planning How the Work Will Be Accomplished
After the scope is set, the team plans how to deliver the selected user stories. This involves breaking down the stories into smaller, actionable tasks that can be completed during the Sprint. The Developers work together to determine how they will collaborate to achieve the Sprint Goal, refining the plan as needed.
Tasks of User Story 1
User Story 1: “As a new visitor, I want to register an account so that I can securely save my payment and shipping information for future orders and track my purchase history.”
- Create a user-friendly registration form with fields for email, password, and other necessary information.
- Implement server-side functionality to process user registration requests, validate inputs, and securely store user data in the database.
- Enable sending verification emails to confirm the user’s email address as part of the registration process.
- Add real-time validation for inputs and display clear error messages for invalid or duplicate registrations.
The result of Sprint Planning is a Sprint Backlog—a living document that contains the Sprint Goal, the selected user stories, and the task breakdown. The Developers continue updating the Sprint Backlog throughout the Sprint, ensuring transparency and tracking progress.
Scrum Master’s Facilitation Tips for Sprint Planning
- State the Sprint Goal clearly.
- Use visual tools like whiteboards or digital collaboration tools to map out tasks.
- Involve the whole team to encourage participation and collaboration.
Commitment to the Sprint Goal
Once the team has agreed on the Sprint Goal and the Sprint Backlog is set, the Scrum Team commits to completing the chosen user stories within the Sprint. The team uses their Sprint capacity and understanding of the work to ensure the scope is achievable. The Sprint Backlog becomes the main source for monitoring progress throughout the Sprint, with updates made continuously as the work evolves.
12.3.2.7 Daily Scrum
The Daily Scrum is a short, 15-minute meeting held every working day of the Sprint. Due to the typical practice of team members standing during the meeting, it is often referred to as the Daily Standup Meeting. Standing encourages brevity and keeps the meeting focused on its purpose: to inspect the team’s progress toward the Sprint Goal and adapt the Sprint Backlog if necessary. It helps the team stay aligned, adjust their work, and plan for the next day.
During this meeting, the Developers discuss what they did the previous day, what they plan to do today, and any blockers or challenges they face. While the meeting is timeboxed to 15 minutes, it is not the only time the Developers can adjust their plan. The team may continue detailed discussions throughout the day as needed.
Three Questions for the Daily Scrum Answered by Each Developer
-
What activities have I performed since the last Daily Scrum Meeting?
-
What activities am I planning to perform until the next Daily Scrum Meeting? What is my action plan?
-
Did I encounter or am I expecting any impediment that may slow down or block the progress of my work?
The Product Owner and Scrum Master may attend if they are actively working on items in the Sprint Backlog.
A Daily Scrum for the “Bookstore Website and Mobile App” Project
During a daily Scrum meeting for the bookstore project, the team reviewed their work on the User Management features.
Developers discussed the following:
- What they did yesterday: One developer shared that they completed the front-end design for the user registration form, while another mentioned working on validating password strength.
- What they plan to do today: The developers planned to work on connecting the registration form to the database and setting up the password reset feature.
- Any blockers: A developer mentioned running into an issue with testing the login functionality, where session handling needs further adjustment.
The Scrum Master ensured the team stayed on track, and any deeper discussions about challenges or blockers could be followed up later.
12.3.2.8 Sprint Review
The Sprint Review takes place at the end of the Sprint, where the Scrum Team presents the outcome of their work to key stakeholders. It is a working session to inspect the completed Product Increment and gather stakeholder feedback to determine future steps. The Scrum Team discusses what was accomplished, and stakeholders offer input on how the product should evolve. Based on stakeholder feedback, this event focuses on adaptations to the Product Backlog and is key to ensuring the product meets stakeholder expectations.
A Sprint Review for the “Bookstore Website and Mobile App” Project
At the end of the Sprint, the team held a Sprint Review to showcase the working user registration, login, and password reset features to stakeholders.
- What the team accomplished: The team demonstrated how new users can register, securely log in, and reset their passwords if they forget them.
- Stakeholder feedback: Stakeholders suggested enhancing the user interface for the login screen, such as improving visual feedback for incorrect passwords or streamlining the password reset process.
This feedback helped the team adapt the Product Backlog, potentially adding user interface improvements or new security measures to future Sprints.
12.3.2.9 Sprint Retrospective
The Sprint Retrospective concludes the Sprint and focuses on how the Scrum Team can improve its effectiveness and quality. The team reflects on how the last Sprint went regarding people, processes, tools, and their Definition of Done. They discuss what worked well, what issues were encountered, and how those issues were resolved—or not.
The Sprint Retrospective aims to identify improvements that can be applied in the next Sprint. Some of these improvements may even be added to the upcoming Sprint Backlog.
A Sprint Retrospective for the “Bookstore Website and Mobile App” Project
Following the Sprint Review, the team held a Sprint Retrospective to reflect on the process and discuss improvements.
- What worked well: The team highlighted that collaboration on the front-end design for the registration form went smoothly and that testing for the password reset feature was completed beforehand.
- What didn’t go well: Integrating the login functionality with the existing user database was challenging and led to delays.
- Improvements for the next Sprint: The team decided to allocate more time for database integration in the future or implement better tools for testing user authentication features.
The team then created action items to address these improvements and potentially add them to the next Sprint Backlog to ensure more efficient collaboration.
12.3.3 Moving to the Next Sprint: The Path to the Final Product
Once the Sprint Retrospective is completed, the Scrum Team moves on to the next Sprint, building on the work and learnings from the previous one. The team repeats the cycle of Backlog Refinement, Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective and continues to deliver valuable product increments at the end of each Sprint.
With each Sprint, the team adds new functionality or improvements to the product, working toward the Product Goal. After every Sprint, the Product Increment grows, becoming more complete and usable. The feedback gathered during the Sprint Review ensures that the product evolves based on stakeholder needs, while the Sprint Retrospective drives continuous improvement in team efficiency and quality.
The Scrum process continues until the team has delivered all the planned increments, ultimately resulting in the final product. This iterative approach allows for flexibility and adaptation and ensures that the team remains focused on delivering value to stakeholders at every stage of development.
Moving to the Next Sprint in the ‘Bookstore Website and Mobile App’ Project
After completing the first Sprint, which focused on enabling user registration, login, and password reset, the team reviewed feedback and reflected on the process in the Sprint Review and Retrospective. Now, the team is ready to move forward with the next Sprint.
In the second Sprint, the team focused on implementing the Book Catalogue features, allowing users to search for books and view detailed descriptions. During the Sprint Planning, the team selected user stories related to searching books by title and author and displaying book details (price, synopsis, ratings). The Sprint Goal for this Sprint was: “Enable users to search for books and view detailed information.”
The team followed the same process throughout the second Sprint—attending Daily Scrums, tracking progress toward the Sprint Goal, and adjusting tasks as needed. Once completed, they conducted a Sprint Review with stakeholders, who tested the book search functionality and provided feedback. The Sprint Retrospective allowed the team to reflect on what went well and identify any areas for improvement, such as improving search performance or refining the user interface for book details.
After this, the team moved to the next Sprint, building on the prior work and adding more functionality—such as a Shopping Cart feature—bringing the product closer to completion with each iteration.
This cycle continues, with each Sprint delivering a new, valuable Product Increment until the final product—a fully functioning bookstore website and mobile app—is complete and ready for release.
12.3.4 Key Scrum Metrics for Progress
12.3.4.1 Burndown Chart
A Burndown Chart tracks the remaining work in a sprint and compares it with time left. It helps the team see if they’re on track to complete all tasks within the sprint.
The vertical axis represents the total amount of work (story points, tasks, or tasks), while the horizontal axis represents the days in the sprint. Each day, the remaining work is updated, creating a downward curve.
In Figure 12.3.4, the Scrum Burndown Chart illustrates the information below:
- Vertical Axis (Work Remaining): It shows the total amount of work to be done in the Sprint. In this chart, the initial workload was 29 story points.
- Horizontal Axis (Timeline): It represents the time within the sprint, typically in days. This chart spans a 7-day Sprint.
- Ideal Timeline Comparison (Blue Line): It represents the ideal or projected progress. If the team worked at a steady pace, it would gradually complete the tasks until there was no work left by the end of the sprint (day 7).
- Actual Timeline Comparison (Yellow Line): It tracks the actual progress of the team. It shows fluctuations in the team’s progress, where they may have started slow, completed a significant chunk of work around day 3, and then steadily completed tasks as the sprint progressed.
12.3.4.2 Burnup Chart
A Burnup Chart shows the work completed and the total work or scope. It helps track scope changes. The vertical axis represents the amount of work, and the horizontal axis represents time. The chart has two lines—one for completed work and one for the required work.
In Figure 12.3.6, the burnup chart illustrates the information below:
- Horizontal Axis: This represents the Sprint Number (1 through 8).
- Vertical Axis: This measures the Story Points Delivered.
- Blue Line (Top Horizontal): It represents the total scope of the project in terms of story points and remains constant at 250 story points. The total work to be done has not changed, meaning that there has not been a scope creep or reduction.
- Green Line (Stepped Line): It represents the work completed (Story Points Delivered). The team gradually increases the number of completed story points as they progress through each sprint.
- Dashed Black Line: This is the ideal progress line, representing how the team would complete work if they delivered story points at a consistent rate across all sprints. The team is slightly behind the ideal pace but catches up as they move towards the later sprints.
Burndown Charts vs. Burnup Charts
- The Burndown Chart tracks the remaining work over time. It shows how much work is left to complete a sprint or project. The goal is for the line to trend downward to zero, indicating that work is being completed.
- The Burnup Chart tracks the completed work and the total scope over time. It shows how much work has been done and compares it against the total amount of work required, with the goal of the completed work line catching up to the total work line.
12.3.4.3 Velocity Chart
A Velocity Chart shows how many story points the team has completed across several sprints. It helps the team estimate how much work they can complete in future sprints. The vertical axis represents story points, and each bar represents a sprint. By tracking the velocity, the team can better predict future sprint capacity.
For example, after completing two sprints in which the team delivered 31 and 33 story points, respectively, the team knows they typically complete around 30-35 story points per sprint. This helps the team plan the next sprint, which might include building the shopping cart feature.
12.3.4.4 Cycle Time
Cycle Time is the amount of time it takes for a task to go from “in progress” to “done.” Shorter cycle times mean the team is delivering features faster. Cycle time is measured by tracking when a task starts and is completed.
For example, if the team begins working on the password reset feature on Monday and completes it on Wednesday, the cycle time for that task is 3 days. If cycle times start to lengthen, it may indicate bottlenecks that need to be addressed.
12.3.4.5 Lead Time
Lead Time measures the total time it takes to add a task to the backlog until it is completed. It includes both the time spent waiting and the time spent working.
For example, if the user registration feature is added to the backlog in Week 1 and completed in Week 3, the lead time is 2 weeks. Long lead times might indicate delays in starting work on important features.
- Digital.ai. (2024). 17th annual State of Agile report. https://digital.ai/resource-center/analyst-reports/state-of-agile-report/ ↵
- https://www.scrum.org/resources/what-scrum-module ↵
- https://scrumguides.org/ ↵
- Project Management Institute. (2017). Agile Practice Guide. Project Management Institute. ↵
- https://scrumguides.org/scrum-guide.html#scrum-master ↵
- https://www.scrum.org/learning-series/what-is-scrum/ ↵
- Retrieved from https://www.scrum.org/resources/blog/tips-agile-product-roadmaps-product-roadmap-examples ↵
- https://www.atlassian.com/agile/project-management/epics ↵
- https://scrumguides.org/scrum-guide.html#product-backlog ↵
- https://www.atlassian.com/software/jira/guides/issues/overview#what-are-issue-types ↵
- This Photo by Unknown Author is licensed under CC BY-SA. ↵
- Retrieved from https://www.villanovau.com/articles/agile/burndown-chart-explanation/ ↵
- Retrieved from https://www.villanovau.com/articles/agile/burndown-chart-explanation/ ↵
- Hayes, W., Miller, S., Lapham, M. A., Wrubel, E., & Chick, T. (2014). Agile metrics: Progress monitoring of agile contractors. Software Engineering Inst., Rept. CMU/SEI-2013-TN-029, Pittsburgh, PA. ↵
- Hayes, W., Miller, S., Lapham, M. A., Wrubel, E., & Chick, T. (2014). Agile metrics: Progress monitoring of agile contractors. Software Engineering Inst., Rept. CMU/SEI-2013-TN-029, Pittsburgh, PA. ↵
