Using a feature sheet to price software development projects

A feature sheet pulls together feature Risk, Priority, and Hours in a simple document so that scope decisions can be made on a project.

>> Open an example Feature Sheet <<

At minimum, a feature sheet has the following columns:

How do I name my features?

If you have a system that already works for your team (like stories), use that.

I follow a pattern: Action Thing Location

  • Action are verbs like Add, Remove, or Change.
  • Thing is a noun or a function.
  • Location is the developer shorthand for where in the project the change should happen. The shorthand changes depending on your platform. Because we use Ruby on Rails it is Namespace::Controller#action

For example:

  • Remove the fax number field from Admin::Users#edit
  • Add ability for clients with the bookkeeper role to export all transactions on Client::Orders#index

I have a post coming up about naming features, subscribe if you want to be notified when it comes out.

What categories should I use?

That's up to you. I prefer to group categories by datamodel (e.g. User, Order) and activities (e.g. Integrations, Setup). This is because:

  1. When the work starts it's nice to take things on in these groupings anyways.
  2. Following the consistent category naming makes it easy to talk about categories as large/encompassing features.

A typical feature sheet will have 10-20 categories.

What about meetings, project management, and administration?

This type of work will scale with the size of the project so I use simple rules to calculate the hours once all other features are done.

Meetings: I add a weekly meeting that is 30 minutes long. A 4 month project will then have (4 months * 4 weeks * 0.5 hour) = 8 hours of meetings.

Admin: Experience has taught me that about 10% of the development budget will be spent on administration.

I don’t care about trying to bill the hours if meetings run long—or if (when) we need to schedule another meeting.

What app should I create the feature sheet in?

Either Google Sheets or Office 365 Excel. This is because the feature sheet should be:

  • Available to everyone who needs it without going through email.
  • Treated as a collaborative working document.
  • Updated in real time during meetings and calls.

How many line items should a feature sheet have?

Anywhere from 10 to 300.

Less than 10? This work is small enough that you can ask an existing client for permission to proceed by email. It’s not worth the effort to put together a feature sheet and statement of work when a quick numbered list will do just as well.

More than 300? You’re dealing with more than one project. Cut scope!

How should I name my feature sheet?

I follow the pattern “Client Name - Features - YYYY-MM-DD - Project Title”.

An example is "C&E - Features - 2018-03-23 - Stripe Integration".

This name makes the sheet easy to find with search in email or shared drives, sorts by date when you sort by title, and lets you tick up the date for versioning instead of adding “(FINAL)” or “v3” to the name.

I have a post coming up about naming things, subscribe if you want to be notified when it comes out.

How should I reference a feature sheet in my quotes?

I don’t take all of the features and put them into the quote, I instead reference the feature sheet that is attached as a PDF. Here’s an example:

“The scope of the project includes all priority 1 features found in the attached document, Client - Features - YYYY-MM-DD - Project Title.pdf”.

How do I use these features once we have a signed contract?

One of two things, depending on how large your team is and how you operate:

  1. Copy/paste the features and notes into your project management app.
  2. Add a column before Priority for tracking 'DONE'.