I've been back on the Use Cases recently after a bit of a time away from them doing some fairly deep techie stuff. Every time I work with Use Cases I find myself wondering why people aren't using them more (or similar methods) because they are just such a logical way of doing things. Let's face it - who really wants to bounce around a 100 page requirements document between inboxes ad infinitum with no-one really understanding or owning it? And what IT department wants to get a document like that landing on their desks?

One of the real beauties of Use Cases is how they feed into the Project Plan. Traditionally project plans have been geared around 'modules' of work, but these modules have normally been things like 'homepage' or 'data layer'. That's fine as far as it goes, but if you estimate around that and build your plan on it then how do you work out what each module actually adds to the value of the project, and how much effort within each 'module' is for core functionality and how much is for wishlist items? You often end up manipulating the project plan by having umpteen round-table meetings with project managers and techies to work out what can and can't get pulled in or pushed out and what impact that has on estimates and the plan.

With Use Cases, all that changes. If each Use Case is estimated then you have a statement of what goal is being achieved at what cost. This, to the project plan, is pure gold. It now becomes relatively trivial to work out how things need to be shuffled in and out of the project plan and, crucially, this can now be a business driven exercise rather than requiring techies to get involved. They don't enjoy that shuffling anyway.

In practice there are three key types of project constraint that affect the 'shuffling'; Functionality, Cost and Time.

• Functionality driven projects: In this type of project, functionality is king. Use Cases help by identifying priorities. All high priority Use Cases need to be put in the plan and this will give a cost and, when resources are factored in too, time. As Use Cases are flagged with changing priorities they can be put in and out of the project plan and the effect is immediately visible.
• Cost driven projects: All Use Cases have an estimation assigned to them. The beauty of this is that the ROI of each Use Case is much more visible. You pay this, you get this for it. The project plan can be built within a cost including the Use Cases that give the best ROI.
• Time driven projects: Some projects have a hard deadline. That's fine - with Use Cases you can fit as much in within the timeline and you can easily see what you will or won't get in before the deadline.

If you have good or bad experiences with using Use Cases for project planning do drop me a comment or a mail and let me know. Always interesting to see how theory turns into practice in different scenarios.