Straw-Man Agile Project Sizing: Part 1

Annual budgeting is in progress and the leadership team want to know how much it will cost to deliver on the planned objectives for the coming year. The problem is, the engineering team hasn’t spent more than ten minutes discussing those products or features, and therefore have only a superficial understanding of functionality, or in some cases, no understanding at all.

 

You’ve probably seen the Dilbert comic(s) of this scenario.

 

Yet, whether we like it or not, we are responsible for making educated guesses to support decision makers. We work for organizations that burn money in pursuit of specific goals and objectives: product launches, revenue growth, cost reduction, scientific discovery, landing a Mars rover, etc. Which slams us straight into the engineer’s dilemma: How can we know how much work is needed until we know exactly what we’re building?

 

If the goal is to lock down cost, we can’t. It’s simply unreasonable and risky to expect a spot-on estimate based on fuzzy, simplified, or incomplete requirements. However, we can provide guidance sufficient to inform business planning.

 

The least helpful thing we can do is make completely wild guesses, which are almost always wrong, and lead either to complete failure, or to cost and schedule blowouts and burned out staff. So-called t-shirt sizing, in sizes small, medium, and large, isn’t much better. What we need is a systematic method for sizing a nascent project, less detailed but analogous to the detailed design and estimating we’ll do once the project is chartered.

 

Complexity Scoring

In Scrum we assign complexity with Story Points. Stories, however, are meant to represent specific actions to be performed by the user (technically the ‘actor’). The value of Story Points for course-grained estimating depends on the degree to which the requested feature or application has been decomposed. However, we typically don’t begin defining Stories until the Product Owner(s) have spelled out relatively detailed requirements.

 

One way to size a software development project without a detailed drill-down is to apply a non-story-based complexity scoring system. This is something you can invent within your team. Like Story Points, your scores don’t need to be universally calibrated to some arbitrary — and noexistent — global standard. They only need to be measured against projects previously accomplished by your own team.

 

If you can’t begin with Stories, you’ll need to decompose the proposed application into some other elements to which you can assign complexity. Any particular application comprises some combination of familiar components:

 

  • Data Inputs .
  • Data elements/data model.
  • Data quantity/velocity.
  • Breadth and depth of state changes.
    • Transformations required.
  • Outputs
    • Including reporting, document printing.
  • User Interfaces.
  • Interfaces to external systems (API).
  • Security/Access Control.

 

Other complexity factors include:

 

  • Novelty: Is this a new application or an extension to existing one?
  • Architecture: Web/SAS, Client/Server, Desktop, Mobile App.
  • Usage scale.
  • Regulatory compliance.

 

It’s a pretty basic list. No big revelations here. However, no matter what solution we may be building, we can use these landmarks to pace out the trails and boundaries of a proposed application. Notice that I’m hiding architectural analysis behind the mask of pre-design. That’s why I consider early costing not only necessary for business planning, but also a useful step toward implementation. Is this ‘waterfall?’ Only if you lock down the design before implementation, which is not only a bad idea, it’s also futile. Things change — hence Agile.

 

In Part 2 we’ll discuss some specific tactics we can use to identify an application’s defining characteristics, which we’ll then use to assign complexity metrics suitable for costing.