Technologist Career Management System
The Agile User Stories and Scenario Feature Stories
Wisdom obtained through the successes and failures of six decades of Software Development has taught us that we must comply with Steve McConnell statement:
“Software’s Primary Technical Imperative is Managing Complexity”
In-depth studies have shown that if the complexity of the business requirements exceeds the capability of human beings to grasp then the success of the project is compromised.
Agile User Stories are effective devices for creating simple, high level, descriptions of the complexities in Software Architecture.
Behavior Driven Design (BDD) Feature Stories are a slight variation to the Agile User Story format that is used to create the Scenarios that map to the Agile User Story Acceptance Criteria.
Complex business case can be defined in an Epic User Story that acts as a container for all of the related Software Elements defined as Child Stories.
Child Stories that are too complex to get your “Arms Around” can create their own collection of Child Stories that are related to the Epic Story as Grandchildren Stories.
Wisdom Pearl #129 – The Architect’s Sandwich
How do you Eat an Elephant … One Sandwich at a Time
The Epic User Story is your Elephant
… The Related Child User Stories
…… And their Grandchildren Stories are your Sandwiches
TCMS has Two Domains
Services Domain – The Info Services for Database and Cloud Service Data
The Application Domain – The MVC Design Pattern that Consumes Info Services
The Application Domain is an MVC 4 Web Application. It Uses the MVC Architecture to manage Interactive State Data.
Epic and Child User Stories for that Domain will be Detailed in a Future Post
The Info Services Epic User Story
The TCMS Services Domain is “Info Services”:
The Info Service Epic User Story:
As a Web Application
I want to access Repository and Cloud Service Information
So that my Web Visitors can access their Personal Profile and Assessment Information along with the ability Purchase Training and Career Information Material from the Technology eStore
This Epic User Story defines the “What” that it’s consuming “Client” requires.
It does not contain any “How” information regarding the process to accomplish the stated goal.
Business User Stories are Agnostic to the Solution
Agnostic Business User Stories prevents Preconceived Ideas from Contaminating the Architecture Solution Process.
The Data Services Child User Stories
Data Services has Two Child User Stories
The Data DAL – An Object Relational Mapping (ORM) Data Abstraction Layer (DAL) of the Repository Data Model
The Data Ops Layer – The Anticorruption Data Operations Layer (DOL) that provides all the Information Data Transfer Objects (DTOs) for Client Consumption with their Error and Exception Handling Object
The Data Abstraction Layer Business User Story (Agile):
As a Repository Information Service Provider
I want to provide a Business Domain Class Mapping Service
So that the Repository Data will Represent the Business Domain Objects
The Data Abstraction Layer Feature User Story (BDD):
Given I Have to Provide a Business Domain Class Mapping Service
When I Receive a Repository Information Service Provider Request
Then I will provide Repository Data that will Represent the Business Domain Objects
The Child User Story defines the intent of the Services Component but not any actual defined process to accomplish the goal.
This opens all the Technological possibilities for exploration by the Architecture team. It does not even define the “Repository” type.
All this User Story states is that a Class Representation is required to access the Repository Objects.
The Data Ops Layer Business User Story:
As a Repository Data Object Request Service
I want to provide Formatted Repository Data Objects
So that Business Services can Service Data Object Requests from Calling Clients
The Data Ops Layer Feature User Story (BDD):
Given I Have to Provide Formatted Repository Data Objects
When I Receive a Repository Data Object Request
Then I will provide Business Services a Service Data Object for the Calling Client
This User Story states the intent of servicing requests for information and return of formatted repository Data Objects for consumption.
It does not define any “How” requirements. It only defines the stated outcome from an incoming request.
The Next Installment of the TCMS Solution
…… Data Services
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