Finish on Time by Managing Scale

"Based on the number of features we've completed over the past couple of iterations, we just don't have enough time to finish all this work," the project manager says nervously to the project sponsor. "Can we talk about what features you'd like to cut?"

The sponsor groans. "Cut more features! We've already been through this. We've cut to the bone already. We absolutely need all the features in this release!"

Does this situation sound familiar? Maybe a little too familiar? The next time you find yourself in a situation where scope cutting seems like the only way to deliver on time, consider looking for opportunities to rescale.
What do I mean by rescale?

I often see software requirements conveyed in terms of solutions to problems. By that, I mean a specific bundle of information including user interface design, expected application behavior, some business rules, etc. Together, those things make up the requirements for a feature.
But behind that description of the software solution is a person with a problem--an end-user with a task or series of tasks to perform to accomplish some goal.

To illustrate my point, let's take a very simple task having nothing to do with software, like "swing from tree," which may have many possible solutions.

Illustration courtesy of ThoughtWorks

The simplest solution might be a rope with a knot, or I can upgrade my swing by making a seat out of a piece of wood. Though two ropes and a nice wide board would really improve my swinging pleasure. But I can see how it would be a bit more expensive with the bigger board, two ropes, and all. All three solutions support a "swing from tree" task, but have different costs and comfort levels associated with each.

When deciding how a particular task is supported in our software, we go through a similar process of looking at possible design solutions and then selecting one that's both consistent with our product and advantageous to users. We use the description of this solution as our final requirements. Then we review, approve, and drop those requirements into the project plan.

Each one of the possible solutions represents a solution at a different scale. Understanding the scale of the chosen solution among the possible solutions gives us flexibility with scope later on. Instead of dropping a feature outright, consider reducing the scale of the solution. To begin to understand and manage solution scale as part of your requirements, you'll need a little more information than you had in the past.

A user model conveys our understanding of the users. Refer to user roles, profiles, or personas from the user-centered design community, or use actor-goal lists from the use case community. In either case, you will need some understanding of the priority of these users. For example, which users are most critical to the success of the software? You'll also need to know a bit about the users' knowledge. How skilled are they with using software? What level of domain expertise do they have?

A task or workflow model conveys the typical workflow of users as they use the software. Task models or use cases work well to describe workflow. No matter what sort of model you choose, you'll need to understand user tasks exclusive of the technological solution--just as a task like "swing from tree" implies but doesn't dictate a particular solution. To manage scale, you'll also need to understand how frequently those tasks are performed and how critical they are to the success of the users.

When searching for features that are good candidates for reducing scale, look