User Scenarios / User Story / Jobs to be done

User Scenario
A high level complete explanation of a user(s)’s actions in a journey to complete a goal that takes place in the real and system based world.

As Defined in Wikipedia

In computing, a scenario is a narrative of foreseeable interactions of user roles (known in the Unified Modeling Language as ‘actors’) and the technical system, which usually includes computer hardware and software.

A scenario has a goal, which is usually functional. A scenario describes one way that a system is or is envisaged to be used in the context of activity in a defined time-frame. The time-frame for a scenario could be (for example) a single transaction; a business operation; a day or other period; or the whole operational life of a system. Similarly the scope of a scenario could be (for example) a single system or piece of equipment; an equipped team or department; or an entire organization.

Scenarios are frequently used as part of the system development process. They are typically produced by usability or marketing specialists, often working in concert with end users and developers. Scenarios are written in plain language, with minimal technical details, so that stakeholders (designers, usability specialists, programmers, engineers, managers, marketing specialists, etc.) can have a common example which can focus their discussions.

Increasingly, scenarios are used directly to define the wanted behaviour of software: replacing or supplementing traditional functional requirements. Scenarios are often defined in use cases, which document alternative and overlapping ways of reaching a goal.[1]

User story
A user story is a lightweight document that can be written on a card. A User Story doesn’t capture all the details, it’s an informal support for the discussion.

A user story can be replaced with a ‘Jobs to be done’ methodology as explained:

View story at

A Use Case
A use case is an heavyweight document that needs a word document. It describes a “Normal Flow” of steps and/or actions and “Alternative Flows” which are detailed. A Use Case captures all the details, it’s a formal specification.

As Defined in Wikipedia

In software and systems engineering, a use case is a list of action or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as anactor) and a system, to achieve a goal. The actor can be a human, an external system, or time. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in the Systems Modeling Language (SysML) or as contractual statements.

Use Cases are documentation heavy and don’t follow a lean or agile approach. But you can find a detailed writeup here: