Feasibility? Picking Features For Your Alpha Release

In my last post, I provided some tools to help estimate the overhead in software development. The basic formula goes like this:

• The business plan should project a budget and desired time line for the alpha release.
• Subtract out some fixed costs for hardware, software systems, databases and components.
• Subtract out ramp up time needed to complete the software requirements, hire the development team, establish the development environment, and complete any prototypes.
• Allocate and subtract out time at the end of the project for revisions, testing, establishing a production environment and deployment.

Following these steps, and you should be left with a budget and duration to construct (budgeted construction time) your alpha release. If you've followed other recommendations in my Startup CTO postings, you should also have a list of high level product features in the business plan as well as a more detailed, prioritized list of features. Now the job is to figure which features can fit into your development cycle.

There are several Agile Development techniques for breaking a large set of features into short, manageable development cycles. The basic approach is to elicit developers to divide and group features into stories that can be fully developed in an iteration - a fixed, short development time line. I'm using language from Extreme Programming but there are other agile approaches such as SCRUM. There are also many software project managers, leaders, and architects that leverage tools from multiple approaches, for example, see 10 Key Principals of Agile Software Development.


The Key Question is Feasibility

The key question the Startup CTO needs to answer is whether developing the Alpha Release in the assigned budget and time line is feasible. The CTO can try to do this by following these steps:

1. Know the budgeted construction time.
2. Divide the Must features into stories. The main rule in doing this is that each story should be easy to describe in a few sentences and should be constructed with few or no unknown dependencies. In addition, it's good to construct stories with 'equal complexity' so that each story should be able to be completed in a development cycle of consistent duration.
   
3. Divide the budgeted construction time by the number of stories to determine the budgeted time for implementing each story.
   

I will elaborate on (2), the art of grouping features into stories in another post. But the point now is to eyeball feasibility. Let's say you only have a couple of days to implement each story. You can now look back at the description and features of a few key stories and ask, is this realistic? You can even go and dive into the technical design a bit to help with this estimate. How many database tables? How many functional elements? How many test cases? How many user input screens? How many user views?

If there isn't enough time allocated for each story, then you have a few options. You can cut down on the number of stories, simplify the requirements of the stories, increase the budgeted time for the alpha release, or to some extent, increase the person power (read The Mythical Man-Month for caveats!).

Give this exercise its proper diligence. If you can't get to Alpha in the allocated budget, you'll have to revisit the business plan. Better to know this before you get started....