Communicating A Release Schedule With Use Cases

We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases.

Background

We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.

Scheduling

There are many books written about how to manage software development, and about project management in general. The Art of Project Management, by Scott Berkun, is an excellent one. In addition to those great works, we’ve written a few articles of our own:

1. How To Use Timeboxes For Scheduling Software Delivery
2. Scheduling Requirements Changes (part 1)
3. Scheduling Requirements Changes (part 2)
4. Managing Scope Creep is Not a Zero-Sum Game
5. Communicating a Delivery Schedule With Use Cases

The Main Idea

The first three posts give us primers on how to manage our team’s capacity, and how to use some rigor when accepting inevitable change requests without jeopardizing our projects. The fourth article shows how we can turn scope-creep into an opportunity.

In the fifth article, we presented our initial thoughts on how to use use cases to communicate delivery schedules.

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.

That article goes into more detail, proposing a grid layout for showing when particular user personas will perform a particular use case.

Conclusion

Critics might argue that we’re recycling old content for this post, but we feel its important enough to say twice. Besides, how many of you were reading Tyner Blain in Dec 2005? Leave a comment if you were – we would love to hear from anyone who was reading way back then. [hint: our avg daily subscriptions are up about 5000% since then.]