Scrum for Software Development: Notes on User Stories, Acceptance Criteria, and Estimation

Overview

  • Topic: Scrum for Software Development with a focus on User Stories and Acceptance Criteria
  • Also covers Estimating and Prioritizing User Stories

User Stories

  • Features the customer needs (wants?)
  • Written in the customer's business language — vocabularies from the application domain
  • Ideally authored by the customer, or the customer's representative
  • Typically, the Product Owner formulates user stories
  • A user story is a ticket to a conversation
  • Not a complete requirements specification

A User Story Template

  • Structure:
    • As a , I want [so that ]
  • : a type of user (e.g., game player, bank teller, …)
  • : what the user needs to accomplish
  • : how the story creates value for the user
  • Examples:
    • As a new user, I need to create an account so that I can log into the American Checkers App
    • As an existing user, I need to log in so that I can play the American Checkers game
    • As an undergraduate student, I need to search for the courses available so that I can complete my enrollment

# Bad Examples

  • As a tic-tac-toe player, I need to win the game so that I will be happy.
  • As a developer, I want to create a testable tic-tac-toe game.
    • These illustrate common misuses: stories that prescribe solutions or outcomes rather than the user goal and value, or are not focused on user needs.

Epics

  • An epic is a user story that is too big to be designed, coded, and tested within a single sprint
  • Example timescale:
    • ⚫ e.g., three months ((3) months)
  • Most requirements start out as epics
  • Epics break down into numerous child stories as more details are discussed

Group Exercise: User Stories (Tic-Tac-Toe)

  • Task: Create a list of User Stories for a Tic-Tac-Toe game
  • Then prioritize them: Which is most important? least important?
  • Visual: TicTacToe board representation (3×3)
  • Example prompts include: XOO and checkmarks for prioritization

TicTacToe User Stories (examples)

  1. As a player, I need an empty board of 3×3 grids so that I can start a game. 3imes33 imes 3 grids in the board
  2. As an X player, I need to place X on an empty cell so that I can make a move
  3. As an O player, I need to place O on an empty cell so that I can make a move
  4. As an X/O player, I need to know if the game is over after each move

INVEST in Good Stories — Bill Wake

  • Independent: User stories should be independent or only loosely coupled with one another
  • Negotiable: Stories are placeholders for the conversation where the details will be negotiated; Stories are not a written contract in the form of an up-front requirements document
  • Valuable: Valuable to a customer, user, or both
  • Estimable: Estimable by the Scrum team; consider size, effort, and cost
  • Sized Appropriately (Small): If we have a (2)-week sprint, we don't want a (2)-week story
  • Testable: Provides necessary information to make testing possible

Acceptance Criteria

  • Purpose: Confirm a user story is complete and working as the customer expects
  • The implementation works as intended and does not do what it is not supposed to do
  • Define the boundaries of user stories with precise details on the required functionality
  • The customer knows what is expected; the developers understand what behavior must be demonstrated precisely
  • Helps conceive development tasks
  • Used to estimate the sprint planning effort

Acceptance Criteria — cont'd

  • Often initiated by Product Owner or customer
  • Developed as a joint effort by the Scrum team, often aided by the customer
  • Can be hard to write in the business language; technical terms may appear (e.g., CAPTCHA)
  • Scrum team should engage the customer in discussions proactively

Details in Good Criteria

  • Close a divergence between the team's and the customers' product visions
  • Close a divergence between the various team members' product visions
  • Helps a new team member understand the product vision
  • Likely to be implemented incorrectly
  • "Need a test for this to ensure we get it right…" (quality and testability focus)

Example: Creating a New Account

  • User Story: As a new user, I need to create an account so that I can log into the American Checkers App
  • Question to consider: What details do we need?

Details We Need to Know (Account Creation)

  • User-name policy:
    • Can new users choose an arbitrary user-name?
    • Must a user-name be a valid email address?
    • If it's an email address, what happens if their address changes?
  • Password policy:
    • Minimum length?
    • Contain both upper- and lower-case letters?
    • Contain digits? Contain symbols?
  • Is a CAPTCHA required?
  • Note: Customers do not necessarily consider such decisions up-front

Acceptance Criteria Template (Given-When-Then)

  • D. North
  • AC#:
  • Given
  • When
  • Then

Sample Criteria: Happy Scenario

  • User Story: As a new user, I need to create an account so that I can login
  • AC 1.1: Successful creation of a valid user account
    • Given a non-existent valid user name
    • When I create an account with this user name
    • And a valid password matching the re-entered password
    • And a valid email address
    • Then the system should create a new account
    • And display a message that I have registered

Sample Criteria: Negative Scenario (Existence Conflict)

  • AC 1.2: Unsuccessful account creation with an existent user name
    • Given a user name that already exists
    • When I create an account with this user name
    • And a valid password matching the re-entered password
    • And a valid email address
    • Then the system should not create the new account
    • And should display an error message

Sample Criteria: Negative Scenario (Invalid Password)

  • AC 1.3: Unsuccessful registration with an invalid password
    • Given a non-existent valid user name
    • When a user creates an account with this user name
    • And an invalid password,
    • And the same confirmed password
    • And a valid email address
    • Then the new account is not created, …
  • Each error condition should be specified in isolation
  • Each should mention all relevant fields

Sample Criteria: Malicious Scenario

  • AC 1.4: Prevention of login with a malicious user name
    • Given a malicious invalid user name and a valid password
    • When I (the adversary) log in with the user name and password
    • Then the login attempt should fail

Group Exercise: Acceptance Criteria

  • 1. As a player, I need to know if the game is over after each move.
  • TicTacToe: XOO ☑

Tic Tac Toe Acceptance Criteria -1

  • AC1.1 Empty board
    • When a new game is started
    • Then there will be an empty (3 \times 3) board
    • And it is X's turn to play
  • AC1.2 invalid row index
    • Given a tic-tac-toe board
    • When a cell is referenced by a row index > 2
    • Then the cell reference is invalid
  • AC1.3 invalid column index
    • Given a tic-tac-toe board
    • When a cell is referenced by a column index > 2
    • Then the cell reference is invalid

Tic Tac Toe Acceptance Criteria -2

  • AC2.1 A valid X move
    • Given an ongoing game with X's turn
    • When the X player makes a valid move
    • Then X is placed in the cell And the turn is changed to O
  • AC2.2 An illegal X move on an occupied cell
    • Given an ongoing game with X's turn
    • When the X player makes an illegal move within the board
    • Then the cell is not changed And the turn is not changed
  • AC2.3 An illegal X move outside the board
    • Given an ongoing game with X's turn
    • When the X player makes an illegal move outside the board
    • Then the turn is not changed

Group Exercise: Acceptance Criteria (Group 2)

  • As an X/O player, I need to know if the game is over after each move.

Tic Tac Toe Acceptance Criteria -3

  • AC 4.1 A win by X
    • Given an ongoing game without XXX or OOO
    • And it is X's turn
    • When the X player makes a valid move to form XXX
    • Then the game is over
    • And X has won
  • AC 4.2 Continuing game after an X move
    • Given an ongoing game without XXX or OOO
    • And it is X's turn
    • When the X player makes a valid move that does not form XXX
    • Then the game continues
    • And it becomes O's turn

Tic Tac Toe Acceptance Criteria -4

  • AC 4.3 A win by O
    • Given an ongoing game without XXX or OOO
    • and it is O's turn
    • When the O player makes a valid move to form OOO
    • Then the game is over
    • And O has won
  • AC 4.4: similar to 4.2 (continuation rules after a non-winning move)
  • AC 4.5 A draw game
    • Given an ongoing game without XXX or OOO
    • And there is only one empty cell
    • When a player makes a valid move
    • And there is no XXX or OOO
    • Then the game is over
    • And it is a draw

Estimation of User Stories

  • Units: e.g., hours or days
  • Story point: a relative unit of measure for the amount of work needed to complete a story
    • Reduces dependency on individual developers
  • Velocity: average number of story points (or hours/days) completed per sprint
  • Estimates for epics are especially crude
  • Used to make broad business decisions
  • Too crude for Sprint Planning
  • Break epics into smaller stories for planning

Planning Poker (Scrum Poker)

  • A method for estimating using cards (Planning Poker)
  • Also called Scrum Poker
  • Visual, collaborative estimation technique

Estimating User Stories with Planning Poker

  • Estimate as a team
  • Wisdom of the Crowds (Delphi) approach
  • Primarily used during Initial planning (prior to the first sprint) and Backlog Grooming
  • Card Faces: (0, \tfrac{1}{2}, 1, 2, 3, 5, 8, 13, 20, 40, 100, \infty, ?)
  • (\?) means not sure; (\infty) means the task cannot be completed
  • Coffee cup: take a break and let the rest of the team continue

Planning Poker: How-To

  • Scrum Master moderates but does not play
  • Product Owner explains the story, answering questions from the team
  • Repeat
  • Each player lays a card face-down representing their estimate
  • Everyone simultaneously turns over their card
  • High and Low estimates explain their reasoning
  • Repeat until a consensus or timeout is reached
  • If consensus is unobtainable, write a task to investigate

Planning Poker: Group Exercise

  • Groups of about (5) students
  • Card faces: (0, \tfrac{1}{2}, 1, 2, 3, 5, 8, 13, 20, 40, 100, \infty, ?)
  • Estimate the effort (in hours):
    • "As a player, I need an empty board of 3×3 grids so as to play a Tic Tac Toe game."

Prioritizing User Stories

  • Priority ranking
  • Unique numerical scale (or qualitative): High, Medium, Low / essential, desirable, optional
  • Often represented as ABCDE
  • How to prioritize?
    • By knowledge value, dependency
    • By increased revenue
    • By reduced cost
    • By reduced risk