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.