You write use cases to define the scope of your project. Use cases describe what people are using your product to accomplish. Use cases provide a framework for defining the details of the product. You can estimate your project effort with use cases. But you have to write the use cases at the right level of detail.
Three Levels of Use Cases
Use cases can be described at any level of detail.
To keep your requirements consistent, you need to write them at the same level of detail.
It can be impossible to organize all of your use cases without creating a notion of subordinate use cases – use cases that provide more detail about other use cases. To have this structure, you have to have multiple levels of detail.
These are not mutually exclusive ideas.
You can provide structure by having high level use cases, that serve to organize your working use cases. The challenge is to not drill down too far and create overly detailed use cases. There’s a “thousand foot” view, a “ten foot” view, and the “one inch” view. Each view provides progressively more detail about the use cases.
Only one of them is effective for estimating the amount of work that needs to be done. Luckily, it is the same level of detail that you should use for managing requirements anyway.
Use Cases That Are Too Abstract
At the thousand foot view of a use case, there isn’t enough information to drive the definition of supporting requirements. At best, you will write incomplete requirements – because the details aren’t there for you. This level of detail is valuable for organizing use cases written at the next level of detail – but you can’t stop here.
Some examples:
- User Purchases Product
- User Updates Insurance Agent Licensing Information
Use Cases That Are Too Detailed
At the one-inch view of a use case, there is too much information. Either you will overlook relavant information (think of the data just outside of the picture), or you will provide all the information, and saturate your readers – who will retain only a small percentage of the “but everything is important” details.
Some Examples:
- User Adds Product To “Cart” After Reviewing Cross-Sell Merchandise From … That Is Related To The Product.
- If the State is FL, Then Update Record With “X” Else, If the State is TN, Then …
Use Cases At The Right Level
At the ten-foot view, you are documenting useful information. Not too much to be remembered, and not to vague to be actionable. Note that these use case title examples are illustrative – read our other article for details on how to name use cases.
Some Examples:
- User ValidatesTransaction
- User Records Transaction
You Need The Ten Foot View
With the images above as your data, which one best provides the best information about how long it would take for me to get from the couch to the jet ski? [You can assume that the couch is featured in each image.] With the first image, it could take anywhere from a couple minutes to a couple hours. The second image completely lacks the context to answer the question. The third image narrows the possibilities down to a ten minute window.
The right level of detail in a use case is just as effective when estimating the size of a project.
Rebecca Wirfs-Brock questions the ability of teams to estimate with use cases, because the use cases are written at the wrong level. She takes an agile-centric perspective on the issue – noting the problem that happens when people try to “document less” and only focus on insufficiently defined use cases. It is a good read, and she talks about how people can mis-apply Alistair Cockburn’s advice. He even adds the following in a comment on her article:
Also, sadly, I have recently seen (for the first time, but that only shows my limited travel circles) a project at a /full stop/ because they had written the essential use cases exactly as I recommended, without UI details, without data descriptions, without detailed (and complicated) business rules … and then never gathered those! So the programmers and UI designers were all sitting around, wondering what on earth the application was really supposed to do / look like !
Alister Cockburn, in response to Rebecca’s article
[Now you’re definitely going away to read her article. :) Please come back.]
Use Case Points
You can estimate the size of a project with use case points. This estimation technique is designed to identify how much work must be done based upon the activities that the product must enable. It is essential when using use case points, to write use cases at an actionable level of detail. If you write at too high of a level, the complexity of the system will be obscured. Also, the “number of steps” elements of the calculation will be wrong at too high or too low of a level of detail.
Impact of Bad Estimation
Bad estimates make it impossible to effectively track and report project progress. And with bad planning, you risk driving your team into the ground with a bad project schedule.
Conclusion
If your estimates are wrong, your planning is wrong – and you may not deliver your product. You certainly aren’t doing the developers any favors by asking them to cover for your mistake with heroic efforts throughout the project.
