What is a Business User Story?
The Agile Business Technology Development Process begins and ends with the Business.
Agile exists to support the ever-growing requirements for Technology to manage all aspects of the modern business daily processes.
Business Drives Technology
… Technology Does Not Drive Business
…… Technology Supports Business Drivers
The Agile Business User Story helps Business Stakeholders and Analysts to define complicated requirements.
By breaking the concepts into manageable statements, that can be defined in various levels of detail, the Business User Story helps bring clarity to complicated ideas.
The User Story process
aids greatly in understanding the complexities
of modern business daily requirements
The Agile User Story
The simple format above allows even the most complicated of ideas to be defined in very simple terms:
As a compassionate human being
I want to solve world hunger
So that people will not go to sleep hungry
This is a monumental undertaking but the “Epic Story” stated above clearly defines the goal.
An Epic User Story defines a Complicated Concept
The Epic Story becomes the Parent of smaller “Child User Stories“
Child User Stories can have Child Stories as well
The Business User Story hierarchy creates the model to break down complicated concepts into manageable pieces.
It goes to the adage:
How Do You Eat an Elephant
… One Sandwich at a Time
Business User Stories are added to the Agile “Backlog” to create what is referred to as “The Christmas List“.
User Stories and the Business Case
The User Story follows an established format to express the desires of a specific Business Case.
User Stories must be written by the Client’s Business Stakeholders, as they have the most knowledge about the request.
The User Story is the Client’s definition of success for the development of the Business Case requirements.
A User Story is a Simple Statement
… Of a Design Requirement
…… Instead of a Large Requirement Document
The Business User Story communicates to the team the “What” and does not specifically address anything about the “How”.
The “How” is the responsibility of the Architects, Designers and Developers.
The real intention of a User Story is to provide the team with the ability respond quickly to User wants and needs.
It creates less overhead in the face of rapidly changing real-world requirements or discovery of new requirements based upon the work in progress.
It is not specifically a description of a feature in a program, but the underlying real world problem that the software component is designed to solve for the business user.
The Business User Story
is the Bridge of Understanding
between the Client
and the Solution Providers
Wisdom Pearl # 123 – Organize Your Creations
A Place for Everything
… And Everything in its Place
…… Organize Your Creations By Their Behaviors and Responsibilities
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016