Agile requirements - setting the context

Still in the series of posts about requirements related artifacts - previous post. When I say requirements related, I mean something that assists us in understanding the system under development. As in past posts, the user story, scenarios & tests are all part of the requirements package. What else is there? What other kinds of things can we produce that add value & enhance understanding. As a coach many times when working with a new team, I'm listening to the conversation and I get lost. There are too many applications, acronyms, systems for me to understand what's going on. When I'm lost I almost always ask the team to allow me to draw a system context diagram.

Agile Requirements - what's beyond the user story?

In the my Previous blog I talked about a metaphor to illustrate requirements evolving from a 1-liner, to a paragraph, to a 1-pager, and then to multiple pages. In the process of building systems using agile approaches many teams have forgotten, or worse have never known how to document details around requirements. There's that pesky agile value - "working software over comprehensive documentation." Too many teams take this to mean we no longer have to write anything down. Not so fast cowboys.

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.