Laura

Your use case experiences mirror my own. I find use cases are an important tool in my toolbox. I use them when we’re talking about interactive processes in our requirements sessions. We link them in closely with the wireframe development calling out to the wireframe in the use case at the appropriate step. Think lots of stickies and flip chart paper with taped lines to start with!

However, I feel the need to turn to other methods when we dive down into the “nitty gritty” of complex business rules, such as integrations with accounting systems. I struggle to find good tools to represent those rules (spreadsheets anyone?) and how to link those complexities into the one step that they pertain to without getting into too much system language for our end users. Would love to hear yours (and anyone elses) thoughts on those topics.

Thanks again – I really enjoy your blog!
Caroline

Thanks for sharing your story. Interesting how we can have different ways of accomplishing the same end goal.

In terms of how we can be sure that our discovery artifacts are correct if we only deliver a subset, I suppose I would say, concretely speaking, no, but we can make them good enough. As I’ve done iterative projects, there is sometimes a need to circle back to documents that you’ve already “completed” in an earlier iteration and make revisions. This works nicely in an agile process because you can just create a new story to hold and prioritize the change as opposed to a more rigorous change control process that might be necessary for a use case with sign-off. Regardless, what was defined in an earlier iteration was good enough to get started. And the information you have later in the process is much better because you might actually be reviewing something in a demo environment, so the change is more informed that if you were just working from your requirements documentation.