Communicating a delivery schedule with use cases

Use cases are a great tool for establishing the scope of a project. They provide a framework for defining what needs to be implemented (if it doesn’t support a use case, we don’t need to implement it). They also set expectations with stakeholders (here’s what you can do with the system).

Many teams fail to leverage use cases to communicate a delivery schedule.

Quick tangent on why incremental delivery is good

When we deliver a project incrementally, we have to think about it in terms of delivering the features needed to support atomic use cases. If we deliver three of the four features required for a particular use case, then users can’t perform the use case. If users don’t perform the use case, then we won’t generate the return on the investment. Use cases are the key to scheduling incremental delivery.Note that a product release roadmap may be driving a high level schedule of functionality, and that roadmap will be driving the schedule of completed (enabled) use cases.

Communicating schedule with use cases

Setting expectations with users and other stakeholders requires that we communicate the schedule of delivery for our software. Stakeholders don’t think or care directly about when feature X is enabled. Feature X is implicitly worthless. When a user can perform a particular use case, which depends upon feature X – that’s what they care about. The executive who funded the project cares about when the business will see a financial benefit from using the software, which is achieved through a set of use cases, which in turn depend upon feature X. Why do so many project, product, and program managers try and communicate scheduling to this audience in terms of features? We should speak the language of the listener.

When talking about the schedule to a user, we should talk about the schedule of particular use cases.

On a large project last year, we were managing requirements using Caliber RM, where we maintained use cases and functional specs with tracing between them. This project was for a very large enterprise software deployment, and it had over 50 use cases with about a dozen different primary actors (classes of users of the system, like regional salespeople, financial accounting people, etc). We were also managing the project across multiple quarterly releases. We needed to set expectations with multiple stakeholders at different levels of the organization, and we had a global development team working on the project from multiple locations.

We needed to present a clear and concise report that would show which use cases were enabled in each release of the software. We were maintaining all of the data in Caliber RM, and the dynamics of the project were such that we were regularly reprioritizing and rescheduling features for upcoming releases. We also wanted to spend our time managing the project, not the reporting on the project, so I built some automation to generate a table showing the schedule for use cases.

The information you want to show in the report is easily understood in a matrix, where each row represents a use case, each column represents a particular actor, and each cell represents the release in which the actor can begin performing a particular use case. This view of the information also helped us in planning rollout and user training schedules. A table of this information could look something like this:

With the schedule, we were able to easily reconcile interdependence of use cases in particular workflows (for example, creating an order is valueless without the ability to approve an order). We were able to plan the rollout to users (corporate accounting would not use the system before Q3). Our development managers were able to view a high level schedule when planning deliveries and our consultants were able to plan for anticipated loading of the servers.

Best of all, we were able to set expectations and provide a roadmap for our stakeholders, who needed a simple way to grasp the very complex product roadmap for delivery. Our communication with executives was at a higher level – reviewing schedules at the goal level, but interacting with different subject matter experts and other mid-level managers often included this view, which was very helpful.

When creating packaged software for consumers or businesses, the same approach is invaluable for planning and can be used to generate excitement in the users. While developed for enterprise software delivery, it is easily applied to shrink-wrapped and hosted software deployments with multiple customers.