Ugly face of Software Sizing

For years I have been using Functional Point sizing as prerequisite for developing estimates during project planning.

Impact of sizing
Software size has been praised of being a non-decayable measure of the amount of software. The elements of uncertainty, complexity, new technology, new team and other risks are factored into the size estimate. This is great! Moreover, Software Sizing is driven based on collaborative process that improves learning and can increase trust.

This is very useful!

However, often I find that Sizing turns into an ugly face, as shown in the back boxes in the above diagram. The fact of having a Size as number appeals to management to practice their long dream of understanding the productivity of their developers, whatever contrary message we suggest. Hence, Sizing quickly becomes a management control.

This control mind-set almost always will lead us to the following consequences:

1. Can we increase the velocity so we deliver more using the same people allocation?

2. Let us reward team X for achieving marvellous velocity.

3. We will engage into contract based on our previous velocity figures.

For me the previous three points demolish all advantages of Sizing, because of one thing, they encourage manipulation of a “number” (software size) which after all is a virtual estimate. In-order to be useful, this virtual estimate requires  collaboration of developers with the right skills and “attitude”.

What about if we stop Sizing?
Well, team will commit on the backlog items which they can complete in the iteration. We should not ask for more because we respect the team.  Hence, developers are true when they tell us, “we can’t take more”.

How we can know our delivery capacity?
For me I like to understand the number of the customer’s valued features we can deliver, from every Class.

The Class can differ based on the kind of business engagement, for example:
– New product development
– Product development
– SDLC maintenance support
– Sustainment

By doing this we:
1. Measure our productivity in terms of what the customer values. If we tell the customer we can deliver 6 business features at the end of the release is much better than telling them we can deliver 100 story-points for the same release. The Class will take care of providing business context of the feature.
2. Provide leadership that serves the teams to self-organize to find solution that really works- without being  under the heat to meet a virtual target.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s