SCRUM / Sprint Sequencing

Data and application processing evolve. Each of these application components starts at a certain stage in their life cycle and change as the rest of the application’s capabilities mature.

Putting order to the Sequence of Sprints in an Application Development project could take advantage of these evolutionary cycles in order to implement a scope of control over each SPRINT.

For example:

When Data is first discovered to be useful to an organization a Data Collection process becomes necessary so that the organization can collect these data. So, a Sprint could be conducted for the single purpose of allowing a User to enter new data related to each instance of the Data’s topic: Person, Place, Thing, etc.

Depending on the nature of these new Data, this SPRINT might be focused on an automated Integration instead of or in addition to New Data manual entry.

This SPRINT need not spend its energies on validating the collected data beyond the point where Alphabetic or Numeric content is assured and some Data can be null or left blank. Therefore initial Collection need not be comprehensive Editing or Validation.

If we follow this type of thinking, we can prepare a SPRINT Schedule for new Data to use the following logic:

• Data Collection and Minimal Editing Rules
  • Alpha, Numeric, or Blank
  • Each New Data Row would be marked with a “State” indication showing that these records have Not Been Data and Relationship Validated (DNValid, RNValid)
• Data Validation
  • For all Collected Data AND
  • For newly entered Data
  • Building tables of Valid Values for each Data Attribute
  • The Processing could then be arranged so that on a regular schedule:
    • One pass of the “Collected” Data would be reviewed for compliance to the current Data Validation rules (marked as “DNValid”)
    • Each new Data Collection process would apply the current Data Validation rules and either mark each new record as “DValid” or “DNValid”
• Row Validation
  • Verifying that each Relationship Field(s) has the appropriate existence of Related Rows
    • According to the Business Rules found in the Entity Relationships included in the Data Model (Entity Relationship Diagram – ERD)
    • The potential Processing cycle could be similar to the Data Validation application sequence looking for Rows marked as “RValid” or RNValid”
• Validation Reporting
  • Another SPRINT can then be conducted to regularly report all “xNValid” Data rows to their appropriate Business Owners (Users) to allow them to:
    • Be aware of the extent of Non Validated Rows
    • Conduct research to make appropriate updates to these “xNV” rows so that they join the ranks of Validated data rows

With a SPRINT Schedule focused on these capabilities, and a readiness to Re-Factor between each of the above SPRINTs, a team can deliver rapid and growing capabilities for a new collection of data in a relatively brief time span.

So, following this pattern, our Business Sponsors / Business Analysts could put their Story Boards in sequence to match this evolution of Data Captured, Data Valid Value Confirmation, Data Relationship Confirmation, Data Row State Review to highlight those rows that are NOT YET in their usable, validated states.