Decomposing by Functionality

Rather than dividing the work by the development activities being performed, or the software architectural components used, you can divide it by the functionality being implemented. This is called a functional slice both because it’s thin and because it cuts through the different components of the system. It even tends to cut through the different development activities if you’re practicing evolutionary design.

What’s a functional slice? It’s a chunk of work defined by what it does rather than how it’s built. “Getting to the train station” indicates functionality. It doesn’t mention the “how” of driving a car or any alternate means. It concentrates on the “what” of the desired outcome. You could satisfy “getting to the train station” with a low-budget solution like walking, and then replace that strategy later when higher performance was required.

Estimating by functional slices has a lot of advantages. First, these slices are things that those asking for the software can understand. They can verify whether they’re done or not by trying out the system. The functionality cuts through the component boundaries, ensuring that they’ve been integrated. There’s still opportunity for unnoticed failures to meet performance or other -ility goals. And if the limits of the functionality are not well understood, it’s likely that the scope will grow a bit. Overall, though, working by functional slices has the least risk of all the ways I know to decompose the scope of work.