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

The Domains

TCMS has Two Domains

1. Services Domain – The Info Services for Database and Cloud Service Data

2. 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

1. The Data DAL – An Object Relational Mapping (ORM) Data Abstraction Layer (DAL) of the Repository Data Model

2. 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

Showcase TCMS

…… Data Services