I recently wrote an article for RIARockStars regarding my take on the CF ecosystem and my challenge as a manager to find talented CF developers – along with some our hiring strategies to work around that. I’ll follow up soon with a follow up post more focused on putting together a hiring strategy for managers of Flex and ColdFusion developers.

…read the full article

One of the problems with the traditional waterfall method is that it’s predicated on the notion that it’s possible with enough planning and requirements gathering to accurately estimate out the effort of a project.

If that were even possible, and your life depended on it, you wouldn’t feel comfortable until the team has spent an enormous amount of time putting together analysis and various levels of technical design.

In order for that possibility to exist you would have to be aiming for a fixed target, whereas developing software is a moving target where scope can change at an time (agile embraces and expects change).

So after weeks or even months of analysis you drop the bomb on the stakeholders of the project that what was asked for won’t fit the required timeline without a decrease in scope or change another project dimension (capacity, budget, resources, etc…).

Meanwhile, stakeholders want an estimation done immediately. There may be a constraint or deadline that needs to be hit, there may be a funding window to get approval, stakeholders might need time lining up shared resources and don’t want to reserve people if they’re going to end up vegging out on the bench waiting for the project to commence, etc…

So what’s the compromise? Story points!

Story points solve the problem

The problem is we need a quick and easy way to schedule out work. In the waterfall approach the business views estimates as commitments, but estimates are estimates – they’re not actuals. You’ll only ever know the actual once the work is completed.

In waterfall land your plan relies on as accurate as possible estimates because you build out your timeline based on that. With agile, your work is based off of fixed-length time boxes – so you know how long each iteration is going to be, the only question is what you fit inside each of those fixed sized buckets of time.

So imagine you’re filling up boxes with various household items, do you really need to know down to millimeter accuracy how big each object is in order to have a sense of how much you can fit in a box? More importantly would it be worth it to spend 2 weeks cataloging all your household items into Excel using a measuring tape in order to make a plan that fills each box to it’s maximum capacity – or is there more value in spending that time to just start filling the boxes by eyeballing roughly what will fit?

I know that some things are twice as big as others, I may not know their exact dimensions but I can guestimate that I can probably fit:

• 10 small things
• 5 small things, and 2 big things
• 4 small things, 2 medium things, and 1 big thing

In this case I’m working on filling a box, but on another project I could be working on buildings and I may not even need to change my point system much.

My buildings might fit into a 1 (small) to 5 (really big) range of categorization. The nice thing about using points is you get away from using time to estimate size. In theory you could use hours, such as 1hr for small things, 5hrs for medium, and 10hrs for large. But the problem is that when you start talking hours people start assuming you’re talking about duration or effort, so it’s best to use points or any term that signifies size.

Story points converted to time

These numbers initially can’t be converted into time, you have no data in order to base such a conversion on. But as you perform iterations over time you’ll be able to track how many story points are completed with each iteration and thus know what your velocity is. Knowing that an iteration was 60 man hours, and it was 6 story points, you could formulate that a story point is about 10hrs of effort.

Knowing actual hours might be an interesting tidbit, but one could argue they’re irrelevant. This is because when you’re planning out your next iteration you’re still using the story point technique to fill your boxes, but now you have historical data to improve your understanding of how many points fit into a box.

Recap

• Estimates are estimates, not actuals.
• Actuals are historical, you can never know them upfront.
• No developer in their right mind would commit to an estimate without heavy duty specs.
• Waterfall requires time consuming analysis in order to get specifications detailed enough for someone to commit effort and duration to. Knowing effort, waterfall then plans out the timeline.
• Agile is fixed-length timelines. You already know when an iteration/phase/sprint ends. You just need to fill up those iterations with work.
• Story points are a quick way to estimate out the relative size of one feature vs. another feature. Size is the keyword (vs. effort or duration).
• Using relative sizes, you’ll have a rough idea of how many points can be completed within an iteration.
• As iterations end, you’ll have a stronger understanding of how many points an iteration can fit.