Agile Requirements - System Sequence Diagram (SSD)

In the Previous Post I talked about the System Context Diagram. It provides a high level view of a system and it's interfaces that make up the overall ecosystem for the product under development. The system context diagram is a static model, meaning it doesn't show interactions/changes over time. From a context diagram, we can create another model, the System Sequence Diagram (SSD) that will show interactions over time.

Why have we forgotten about requirements analysis in our agile world?

As I coach teams, inevitably the discussion about requirements comes up. Some of the things I've heard from team members:

• We don't write any requirements
• A user story is all we need for requirements
• We don't have time to write requirements, we just talk with our Product Owner
• Since we don't write requirements, we just figure out the features on our own and show the completed work to our product owner
• ... 

When I think of requirements, I think about who consumes them and the value that the consumers get from them. Many teams have lost their way when it comes to agile requirements and requirements related artifacts.

Data centric projects & user stories

I've been able to work on a couple of types of data centric projects. One was creating an ODS based on consolidating customer data from multiple source systems. This involved finding the data, extracting, transforming, & loading, as well as matching customer records, de-dupping, address matching and data cleansing. Now I've been working with some teams who are focused on moving data into a data warehouse. When first working with data teams a typical reaction is that we can't do user stories. Or we have to complete the whole data model done up front. Or we have to load all the data at once otherwise we're duplicating work, ... Basically I get a reasonably long list of why we can't do incremental development for data centric projects.