[Sprint 4] User Stories - paynem/AcesUpProject GitHub Wiki

1: Card: "As a player, I want to be able to switch to a Spanish mode, so that I'm able to play the game using a Spanish deck”

Conversation:

  • A button/drop-down to select version (Regular or Spanish)
  • If "Spanish" is selected, the deck will be changed to 50 cards, different suites, and all other applicable changes

Confirmation:

  • The deck changes to the Spanish version (and can also be changed back to regular). GetSpanDealPile() will be used to test this. If it returns an okay, then the Spanish game is actually being started.

2: Card: "As a developer, I want there to be a button that the User can click on to switch between a Spanish and Regular game mode, so that the user can do so intuitively.”

Conversation:

  • A button (that matches the current styling) to switch versions
  • When clicked, the versions change.

Confirmation:

  • GetSpanDeal() tests for the Spanish Game to be started, but that's only through the Java. When we have a button that starts the Spanish game in the actual UI, that will be confirmation of this user story.

3: Card: "As a user, I want there to be a Spanish deck version of the game, so that I can enjoy playing AcesUp in multiple ways”

Conversation:

  • A second version of the game that has the following suits: bastos (clubs), oros (golden coins), copas (cups), and espadas (swords).
  • 50 cards: nine ranked cards per suit (1-9), three face cards per suit (10-12), and 2 comodines cards (Jokers).

Confirmation:

  • Tests in SpanDealTest.java will confirm this.

4: Card: "As a developer, I want there to be a Spanish child class of the Card class that incorporates all the elements of a Spanish deck, so that inheritance can be implemented into this Sprint.”

Conversation:

  • Creation of a Spanish deck child class with appropriate elements (as listed above)

Confirmation:

  • SpanGameTest.java will verify the functionality of this class.

5: Card: "As a developer, I want a deal method that is able to deal with the 50 cards (the last deal is only going to have 2 cards instead of 4) of the Spanish deck, so that the user can play the game without any problems.”

Conversation:

  • Instead of 4 cards for every deal, the Spanish deck will have 2 cards for the final deal.

  • The deal function needs to be able to handle this without the game breaking down.

Confirmation:

  • testFinalDeal() in SpanDealTest verifies the functionality of this.

6: Card: "As a developer, I want jokers to be able to match up with any suit, so users can properly play with Spanish rules.”

Conversation:

  • Jokers should match up with any suit.

Confirmation:

  • The test methods jokerDiscard() and noJokerDiscard() in ColumnTest.java confirm the functionality of this feature.

7: Card: "As a developer, I want the both the joker and the card discarded off the joker to be moved to the success pile, so that the user can properly play with Spanish rules.”

Conversation:

  • Any card can be discarded off of a joker

*When a card is discarded off of a joker, both the card and the joker are moved to the success pile.

Confirmation:

  • The test method jokerDiscard() tests and verifies the functionality of this.

8: Card: "As a developer, I want there to be a SpanGame.java class that inherits from the regular Game.java class, so that we have a separate class managing the Spanish game."

Conversation:

  • SpanGame will inherit from Game.

  • Some methods will change via polymorphism

  • ApplicationController will start a game through SpanGame instead of Game when the user chooses to play the Spanish version of Aces up

Confirmation:

  • When the generated JSON reflects which class is being used (if game is chosen, the JSON will be filled with cards with regular suits, if Spangame is chosen, the JSON will be filled with cards with Spanish Suits). Also, the test class SpanGameTest.java tests the functionality of this class.

9: Card: "As a developer, I want there to be a SpanDeal.java class that inherits from GroupOfCards.java, so that we have a separate class that manages the deal pile for the Spanish version of Aces Up.

Conversation:

  • SpanDeal will inherit from GroupOfCards.

  • Some methods will change via polymorphism

  • SpanGame will create a deal pile through SpanDeal instead of DealPile when the user chooses to play the Spanish Version of the game.

Confirmation:

  • When DealPile (we'll use the same name in the JSON for the dealpile object) is filled with Spanish playing cards instead of regular playing cards in the JSON. Additionally, SpanDealTest.java tests the functionality of this class.

10: Card: "As a user, I want there to be separate and clear rules written down for each version of the game, so that I know how to play both the regular version of Aces Up and the Spanish version of Aces Up."

Conversation:

  • The rules button will generate spanish rules when the Spanish version of the game is being played and regular rules when the regular version of the game is being played.

  • This will be done via bootstrap modals (each set of rules will have a separate modal)

Confirmation:

  • When a popup window with regular rules pops up when the user clicks on the rules button when the regular version of the game is selected, and when a popup window with spanish rules pops up when the user clicks on the rules button when the Spanish version of the game is selected.

T-Shirt Sizing Estimation Technique:

T-shirt Sizes of User Stories: User Story 1: Medium = 2 User Story 2: Small = 1 User Story 3: Extra Large = 4 User Story 4: Medium = 2 User Story 5: Medium = 2 User Story 6: Small = 1 User Story 7: Medium = 2 User Story 8: Medium = 2 User Story 9: Medium = 2 User Story 10: Small = 1

We used a modified version of the steps listed on the site that the professor provided:

  • Make sure everyone understands that we’re voting to decide whether a user story should have a small, medium, large, or extra-large size.
  • User Story is linked in the discord chat
  • Each developer gives each story a t-shirt size.
  • All in the Development team will vote in the chat at approximately the same time
  • The development team will discuss the differences.
  • The product owner explains the story further or clarifies misunderstandings if any.
  • The team will Go back to Step 3-Step 5 until all are agree with one size.
  • Add the user story with its attached size and level of complexity to the Sprint 4 Planning Meeting document.

We decided to forgo attaching the time to complete each user story because it was ultimately something that seemed like too much of an unknown to us. We just attached sizes and estimated complexities (the numbers) to all of the user stories.

The team leader (Zeyad) would link a user story in chat, and we would all vote on it. We then discussed our votes and repeated the process until we came to a consensus.