When deciding how a user's task is to be supported in our software, we often look at possible design solutions and select one that's best for the product and the user. As the project deadline approaches, however, we might choose to dismiss some features outright. In this column, Jeff Patton suggests we try keeping more features by adjusting their 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 for lower frequency tasks performed by lower priority users with strong computer or domain skills. Simply put, a feature can be a little rough around the edges if it's used infrequently by a smart user who isn't one of the user types we really cater to. A feature like this may be a candidate for a "knot on the end of a rope," as opposed to the "two-roped seated swing" we initially put into scope and estimated.
Yes, I know it's usually not that cut and dry. But, knowing users, tasks, the frequency of each task, and its importance sure helps find opportunities to scale. To act on scaling opportunities, you'll need to be good at proposing alternative and cheaper solutions that help those users accomplish their tasks and meet their goals.
While this helps to cut scope as a release draws near, these are important details to consider when initially scoping the project. For each proposed feature of the product, consider the user and task supported. Consider the possible range of design solutions for that user. Is the solution chosen in line with the user and task supported? Are we spending more time building better solutions for our most important users engaged in their most frequent and critical tasks? Consider deferring detail designs until closer to implementation time. Trap user tasks as requirements. To estimate, discuss the range of possible solutions, then give a rough estimate on the most likely solution. Plan your project around those estimates, and consider keeping notes regarding the range of solutions with your estimates as a reference. Resolve detail design when development time draws near—by then you should have good information about other features, time constraints, and development capacity.
Leave room to rescale. Although being alert to appropriate scale is important, slicing feature scale too thin and too early leaves little room for rescaling in the future. If you postpone choosing detail design solutions for user tasks until later, keep your initial estimates on the high side of moderate. This will allow you flexibility to raise and lower scale as time allows, based on user and task priority.
The next time you feel cornered and compelled to drop a feature from scope in order to reach a delivery, go back to the users, goals, and problems that motivated the particular solution in scope. Look at other alternatives that might allow you to still solve the problems at a lower cost. Rescale the feature, don't de-scope it.
