Do you have some experience with this kind of topic?

It is awesome that you’re concerned about overall consistency and quality of the application! It is very easy for teams to immediately dive deep and myopically focus on the “first” user story (or use case). This can result in a disjointed collection of locally-optimized user experiences, as you point out.

What I suggest in How to Start the Use Case Process for Agile Development is that you want to start with a breadth-first approach.

1. Get a shallow but comprehensive view of the scope of your problems / solutions.
2. Use this perspective to establish and communicate context with your teams – so that the individual experiences are cohesive and not disjointed.
3. Prioritize the stories/UCs in the context of this big picture view.
4. Implement iteratively.

Thanks again for the insight, I’m sure folks will be helped by this!

In the past I saw a project with more than 100 UC and in average has 3 scenarios. In this environment probably I should have more than 300 US. The number of iterations depends of the project manager and its compromises with stakeholders and other facts, although when I think about how to apply agile in this kind of project, I will provide functionality to users at incrementally style (sprint in scrum), although I’m concerned about overall consistent design. When the team is going to begin with one US, the team must validate with the user the test case, make a design, develop, and test. All of this will be done under the pressure of time. What about the quality of whole system not only how well each US be accomplished.

Thanks for your comments.

And thanks for the props on Test Smarter, Not Harder, was a fun article to write – mainly because the concepts are so esoteric, but the benefits so significant. I think we all have more work to do to get this stuff more approachable, and therefore more widespread in usage.

Fantastic post. Outstanding. I’m tweeting about it now and intend to include in an upcoming blog post. You’re exceptionally good at presenting information in a clear manner that makes it relevant to readers. Incidentally, your article about pairwise and combinatorial testing is extremely good as well.

- Justin Hunter
Twitter: http://www.twitter.com/hexawise
Blog: http://www.hexawise.wordpress.com

Our team is in the process of adopting scrum (hence the User Stories) and I’m in the middle of preparing our business partners to use Use Cases as part of the requirements. I found your illustration will be very helpful. May I have your permission to use it when I do my presentation ?

Thank you.

One of the benefits of working with a lot of different companies, large and small, is that you get exposed to a lot of methodologies. It presents an opportunity to learn what works (and doesn’t) and why it does (or doesn’t). I tend to encourage a pragmatic approach, when working with clients that have some process flexibility. And to your point – “mixing” good ideas from different methodological camps does tend to avoid many of the trade-offs that come from zealously using only the tools and techniques of a single approach.

I feel that these are all the marketing stunts for the various software processes that are required. To build a robust marketable product, one has to have a sound architecture most of which come in as a part of the non-functional requirements and the basic features driving the usability features. I have seen people dispute and argue over methodologies, formats of documentation, models and other aspects. But this is about the comfort level of the manager and team to approach the product and most important, the kind of documents the users wants to see about the product they are requesting. So even though there may be many methodologies, an ideal way will be a combination of documents derived from various methodologies that best suit the needs of the development in consideration.

I chuckled when I read Patrick’s response – been there done that. On past projects, I’ve successfully been able to get the bare minimum amount of monitoring implemented, but only a couple times. Teams I’ve been on have found they can get 80% of the value by doing manual analysis of website stats “on demand” when trying to get the feedback. Anecdotally, it seems like when I’ve been on products that are mature enough that building monitoring/feedback systems is “the most important thing” the development teams have been cut back to “milk” the product for higher margins – so it couldn’t happen then, either.

That’s one of those things we always talk about but never really find the time to go do it :) Recently, we’ve been doing a better job of looking at available functional data (analyzing user data looking for patterns), but we haven’t ramped that up to looking at website statistics as well.

I agree, though, it would be interesting to find out what our users actually do most often.

That sounds like a really smart move.

Do you also track how often features get used once live and compare back? Interesting to see how well predicted usage matches real usage.

EVERY [SO OFTEN], as a [person in a role] I want to [perform some activity] so that [some goal is achieved].

Our development team usually needs to know how often a story is executed so they get a better idea of how much emphasis to put on the usability of the design. In our world, a feature that will be used 100 times a day by every user usually deserves more design attention than an admin task that is performed once every few years.

So for a waterfall style requirements proces, I have started using User Stories as the beginning point of the process after developing some simple User Roles. This helps to drive the real goal of the user, independent of solution and technology you think you want to use.

The next step is the development of a story-based Usage Scenario (your Use Case Scenario) to tie together the user goal with an envisioned solution. From there is an easy step to informal use case and interative versions of more detailed use cases follow. The intent I try to get across is to iterate ONLY TO THE LEVEL REQUIRED FOR YOUR DEVELOPERS TO UNDERSTAND. This is exactly how I read your article.

So, while your discussion is starting from an Agile viewpoint, you can also start from a Waterfall viewpoint with exactly the same conclusion: User Stories capture the user goal, Scenarios bridge the goal to solution, and Use Cases detail the solution.

Thanks for the posting.

I’m currently developing a few related to one of the products I’m responsible for to see if I can demonstrate improved productivity, so your points here about writing requirements for the audience ring true. I have also been known to suggest that additional models should be created as needed to visually represent some requirements, depending on the nature and complexity of those requirements.

So, I don’t really have a question, but thanks for helping me think this through!