Scenario 1: Team’s Progress Presented on Burndown Charts

Task 1: Explain how you created the ideal burndown

• Top Point of the Ideal Burndown Chart:

The initial total number of story points in the product backlog is 137.

• Calculating Working Days:

▪ Sprint 1: March 4 - March 15 (10 working days minus 1 public holiday on March 11)
= 9 working days.
▪ Sprint 2: March 18 - March 29 (10 working days minus 1 public holiday on March 29)
= 9 working days.

Total working days for both sprints: 9 (Sprint 1) + 9 (Sprint 2) = 18 working days.

• Ideal Daily Velocity:

Ideal Daily Velocity = Total Story Points / Total Working Days = 137 / 18 ≈ 7.61 story points per
day.

• Product Owner's Decisions Impact:

▪ Added PBIs (PBI-42, PBI-43) with 5 story points each: Total Story Points increased
by 10.
▪ Removed PBIs (PBI-24, PBI-25) with 3 and 1 story points respectively: Total Story
Points decreased by 4.
▪ Updated Total Story Points = 137 + 6 = 143.

New Ideal Daily Velocity = 143 / 18 ≈ 7.94 story points per day.

Task 2: Explain how your real burndown was evolving day by day
throughout sprints

Sprint 1:
• Week 1:
▪ Completed PBI-1 (8 story points)
▪ Completed PBI-2 (2 story points)
▪ Started PBI-3 (5 story points)
• Week 2:
▪ Completed PBI-3 (5 story points)
▪ Fixed and completed PBI-2 (2 story points)
▪ Completed PBI-4 (3 story points)
▪ Completed PBI-5 (1 story point)
▪ Total story points completed in Sprint 1: 8 + 2 + 5 + 3 + 1 = 19 story points.
Sprint 2:
• Week 1:
▪ Completed PBI-6 (8 story points)
▪ Completed PBI-7 (3 story points)
▪ Completed PBI-8 (2 story points)
▪ Started PBI-9 (8 story points), PBI-10 (3 story points), PBI-11 (2 story points)
• Week 2:
▪ Fixed and completed PBI-8 (2 story points)
▪ Completed PBI-9 (8 story points)
▪ Completed PBI-10 (3 story points)
▪ Completed PBI-11 (2 story points)
▪ Started PBI-12 (8 story points)
▪ Total story points completed in Sprint 2: 8 + 3 + 2 + 8 + 3 + 2 = 26 story points.

The real burndown chart would show the completion of 19 story points by the end of Sprint 1
and 26 story points by the end of Sprint 2.

Task 3 (Bachelor students): Calculate ideal, acceptable, and real

velocities

Ideal Velocity:
Ideal Velocity = New Total Story Points / Total Working Days = 143 / 18 ≈ 7.94 story points per
day.

Acceptable Velocity:
An acceptable velocity could be 80% of the ideal velocity.
Acceptable Velocity = 0.8 Ideal Velocity = 0.8 * 7.94 ≈ 6.35 story points per day.

Real Velocity:
▪ Sprint 1: 19 story points / 9 working days ≈ 2.11 story points per day.
▪ Sprint 2: 26 story points / 9 working days ≈ 2.89 story points per day.
▪ Average Real Velocity = (19 + 26) story points / 18 working days ≈ 2.5 story points per
day.

Conclusion:
The team's real velocity (2.5 story points per day) is significantly lower than the ideal (7.94) and
acceptable (6.35) velocities. This indicates that the team is underperforming and may face
challenges in completing the project on time if they continue at the same pace. The team must
identify and address any bottlenecks or inefficiencies to improve their velocity.
- Ideal Burndown Line (dashed): Represents the planned reduction in story points over time.
- Real Burndown Line (solid with markers): Reflects the actual progress of the team, adjusted
for holidays (Laboure Day on March 11 and Good Friday on March 29).

This chart helps visualize the team's progress in completing story points compared to the
planned ideal progress, showing deviations and the impact of holidays on the schedule.

Scenario 2: Quality Assurance Analysis

Task 1: Analysis of the Specified Acceptance Criteria

The Acceptance Criteria (AC) provided for PBI 15 are as follows:

1. AC13.1: Given the customer is on the cart page of the application

- When the customer selects the option “payment with credit card”,
- Then the payment option for this order will be stored as “CreditCard” and the application will
present to the customer a screen “Please enter details of your credit card” with fields to enter
the credit card number, name on the card, and the expiration date of the card.

Identified Issues:
- Ambiguity: The criteria do not specify what happens if the credit card information is invalid or
what kind of validation needs to be performed on the credit card details.
- Usability: It does not mention what should happen if the user decides to switch payment
methods after initially selecting "CreditCard".
- Error Handling: There is no detail on how errors should be communicated to the user (e.g., if
the card is declined).

Corrected Version:

1. AC13.1: Given the customer is on the cart page of the application

- When the customer selects the option “payment with credit card”,
- Then the payment option for this order will be stored as “CreditCard” and the application will
present to the customer a screen “Please enter details of your credit card” with fields to enter:
- Credit card number
- Name on the card
- Expiration date of the card
- CVV code
- The application will validate the entered credit card details.
- If the credit card details are valid, the order will proceed to the next step.
- If the credit card details are invalid, an appropriate error message will be displayed to the
user, and they will be prompted to re-enter their details.
- The user should have the option to switch to another payment method at any point before
confirming the payment.

Task 2: Analysis and Correction of Sprint Tasks

The sprint tasks provided in the Trello card for PBI 15:

- Task 1: Create UI for payment selection

- Task 2: Implement functionality for storing payment option
- Task 3: Create UI for entering credit card details
- Task 4: Implement functionality for storing credit card details
- Task 5: Validate credit card details
- Task 6: Display error messages for invalid credit card details
- Task 7: Allow switching of payment methods
- Task 8: Conduct unit testing for payment selection
- Task 9: Conduct functional testing based on ACs

Issues Identified:
- The tasks do not mention the need for usability and regression testing.
- There is no specific task for handling edge cases like invalid input formats or network failures.

Corrected Version:

-Task 1: Create UI for payment selection

-Task 2: Implement functionality for storing payment option
-Task 3: Create UI for entering credit card details
-Task 4: Implement functionality for storing credit card details
-Task 5: Validate credit card details
- Sub-task 5.1: Implement client-side validation
- Sub-task 5.2: Implement server-side validation
-Task 6: Display error messages for invalid credit card details
-Task 7: Allow switching of payment methods
-Task 8: Conduct unit testing for payment selection
-Task 9: Conduct functional testing based on ACs
-Task 10: Conduct usability testing (Chrome 123.0, Safari 17.4.1)
-Task 11: Conduct regression testing
-Task 12: Handle edge cases (e.g., invalid input formats, network failures)

Task 3 (Bachelor Student): Specification of Test Cases and Discussion

Test Case Specification for Functional Testing Based on ACs (Manual Testing):

1. Test Case 1: Payment Method Selection

- Pre-condition: The user is on the cart page.
- Steps:
1. Select "Credit Card" as the payment method.
2. Verify that the payment option is stored as "CreditCard".
3. Verify that the screen for entering credit card details is displayed.

2. Test Case 2: Entering Valid Credit Card Details

- Pre-condition: The user has selected "Credit Card" as the payment method.
- Steps:
1. Enter valid credit card number, name on the card, expiration date, and CVV code.
2. Verify that the details are stored correctly.
3. Verify that the order proceeds to the next step.

3. Test Case 3: Entering Invalid Credit Card Details

- Pre-condition: The user has selected "Credit Card" as the payment method.
- Steps:
1. Enter an invalid credit card number or expiration date.
2. Verify that an appropriate error message is displayed.
3. Verify that the user is prompted to re-enter their details.

4. Test Case 4: Switching Payment Methods

- Pre-condition: The user has selected "Credit Card" as the payment method.
- Steps:
1. Switch to "PayPal" as the payment method.
2. Verify that the payment option is updated to "PayPal".
3. Verify that the relevant PayPal payment screen is displayed.
Scenario 3:

Task 1: Analysis of PBI Priorities, User Stories, PBI Statuses, PBI Owners, and Efforts

Issues Identified:

1. PBI Priorities:
- Inconsistencies: I noticed that some PBIs have the same priority but vary significantly in their
importance to the project. This suggests a lack of alignment in prioritizing tasks.
- Solution: To fix this, I will re-evaluate the priorities by consulting with the product owner and
stakeholders to ensure that the highest priority items reflect the most critical tasks that need
immediate attention.

2. User Stories:
- Clarity: Some user stories are vague or lack sufficient detail, making it difficult to understand
the user’s needs and the acceptance criteria.
- Solution: I will refine these user stories by adding more detail and ensuring they follow the
format "As a [type of user], I want [an action] so that [a benefit/value]." This will make them
clearer and more testable.

3. PBI Statuses:
- Progress Tracking: I found that some PBIs marked as "To-Do" may have already progressed
further in development, leading to inaccurate tracking of progress.
- Solution: I will update the statuses of these PBIs to accurately reflect their current state, such
as changing them to "In Progress" or "Done" as appropriate.

4. PBI Owners:
- Ownership Distribution: The distribution of PBIs among team members is uneven, with some
team members overloaded while others have fewer tasks.
- Solution: I will reassign PBIs to balance the workload more evenly across the team, ensuring
that each team member has a manageable number of tasks.

5. Efforts:
- Effort Estimation: Some PBIs have effort estimations that do not correspond with their
complexity, either overestimating or underestimating the required effort.
- Solution: I will review these estimations with the team to adjust them for accuracy, ensuring
that each PBI’s effort estimation realistically reflects the work involved.

Task 2: Analysis of PBI IDs and Sorting

Issues Identified:
1. PBI IDs:
- Non-Sequential IDs: The PBI IDs are not in a logical or sequential order, making it difficult to
track and manage tasks efficiently.
 - Solution: I will re-number the PBIs in a sequential manner that reflects the order of tasks and
their importance. This will streamline the tracking process.

2. Sorting:
- Sorting by Priority and Status: The PBIs are not sorted by priority or current status, making it
challenging to identify the most critical tasks and their progress quickly.
- Solution: I will sort the product backlog first by priority to ensure the most important tasks are
addressed first, and then by status (e.g., To-Do, In Progress, Done) to provide a clear view of
the progress.

Task 3(For Bachelor Students): Analysis of the DoD Column

Issues Identified:

1. DoD Adherence:
- Inconsistencies: Some PBIs do not fully meet all the criteria specified in their respective
Definitions of Done (DoD), indicating incomplete tasks.
- Solution: I will ensure that all PBIs are re-evaluated against their DoD criteria before they are
marked as done. This involves checking each PBI to ensure all specified conditions are met.

2. DoD Clarity:
- Ambiguity: Some of the DoD criteria are ambiguous and open to interpretation, which can
lead to inconsistencies in how tasks are marked as complete.
- Solution: I will clarify and refine the DoD criteria to make them specific, measurable, and
achievable. This might involve adding more detailed descriptions or examples to remove any
ambiguity.