User Story

All features are described in the form of user stories

As a {role} i want {function} because {benefit}

Acceptance criterias:

  • ac 1
  • ac 2
  • ac 3

The user story describes the state and behavior of the increment after implementation of the requirements and no (technical) solution path (except technical framework)

INVEST criteria

Independent– independent. The stories should be implementable independently of each other.

Negotiable– negotiable. Changes to the story can be made (in consultation).

Valuable– useful. The implementation of the story increases the utility value of the product for the end customer.

Estimable– quantifiable. It must be possible to estimate the effort required for implementation. (All necessary information must be available for this)

Small– small. The effort for the implementation should be manageable. Can be implemented within one sprint.

Testable– verifiable. It should be possible to check the successful implementation of the story on the basis of criteria. Meaningful measurable acceptance criteria

Story example

Onboarding, Login and User- management


As a user I want to register into the app, so that I am able to book machines and can use the service

Acceptance criterias:

  • when showing the login screen, there is an option to register as a new user
  • if the user presses the register button, the registration process starts
  • The user will go through an onboarding process step by step, the user can only go to the next step, when he fulfill all requirements of the current step
    • Step 1 – The user has to enter his email address and a password (2 times for validation) for the initial registration.
      • Exception e-mail already exists -> show message to user
      • Exception Password rules are not fulfilled -> show message to user
    • Step 2 – after that, an email is send to the user with a 4 digit code for email validation (confirmation code should be part of the email subject). The user can enter the 4 digit code to validate his email. there is also an option to resend the email
      • Exception Digit Code is wrong -> show message to user
    • Step 3 – The user has to enter his address data (street, number, postal code, city) all fields are mandatory
      • Exception Mandatory fields -> next step is only possible, when all mandatory fields are filled
    • Step 4 – The user has to upload a photo of his id document (id card, driving license or passport) After taking a photo, the user has the option to redo or confirm it. Show upload progress after taking the photo
      • Exception upload failed -> show message, user can initialize reupload
  • after the user gone through all steps an overview screen is shown where he can finally confirm
  • on the confirmation screen there are checkboxes for data policy and product information consents
  • when a user aborts after the second step of the registration the questionnaire will always start direct after login
  • the layout and interactions should be implemented according to the design and the common usage and interactions pattern of the respective mobile platform

User Story Writing Tips

  • Keep the story as simple as possible
  • Clearly describe in the story the expected flow and the defined states
  • Do not focus only on the “Happy Path” and try to define the exceptions as well
  • Add to the story all the information that is directly related to the implementation
  • A user story is not a fixed contract – keep communication open with the team to define the best way of implementation together with the team .

Story Estimation at Elasticbrains

Rating of the USER STORY according to

  • Complexity
  • Risk
  • Dependencies

Estimate in Planning Poker

  • Each developer appreciates the user story for itself
  • All show your estimate at the same time
  • The developers with the highest and lowest estimation explain their positions
  • The team discusses and agrees on a value
  • The developer with the higher estimate can insist on the estimate in case of doubt and then it is taken.
  • If necessary The product owner can change the story to reduce complexity, risk or dependencies.

Storypoints at Elasticbrains -> Fibonacci without 2

Scrum Storypoints Fibonacci

if the estimate is more than 13 storypoints, the story must be split