Velocity converts to time, not story points

Suppose for a moment that you have a collection of features you want to build into a product. 

You sit down with your team, brainstorm some user stories and then score them.  When you are done you total up the story points and there are 100 story points.

Suppose then that I tell you this project is scheduled to be delivered in 3 months.   Hmm, that's interesting.

Now suppose that you are also consulting on another project.  You have a collection of features you want to add to this other product.  This project has an entirely different team.  Like the first team these folks have been working together for a while and many of the team members go back to version 1.0 when the product was launched.

You sit down with this team, brainstorm some user stories and score them.  When you are done you total up the story points and there are 100 story points.

You look at the project plan and see that the project is scheduled to be delivered in 9 months.

Both are 100 points but one is a 3 month forecast and the other a 9 month forecast.  Is one team's assessment of the user stories right and the other wrong?

It's likely that both are correct.

Estimates with Risk Assessments, sounds boring, do it anyway...

So Ed sent an email which explained the math around calculating variance.  That's useful, but probably overkill for our purposes but it's worth going over why.

In fact, what we are trying to do is well understood via "Standard Deviation."  Everyone is familiar with Standard Deviation.  In charts it looks like this:



If we take this bell curve and put the earliest date a task could possibly be completed as the point 3 standard deviations to the left and the longest a task could possibly take as the point 3 standard deviations to the right, we would have a risk assessment showing a range of likely completion dates for our task assuming it's risk follows a natural bell curve (as we'll see in a moment that the hump for most software tasks is to the right of center).

All things being equal, if you estimated a completion date for a task as right in the middle, you would have 50% chance of being right and a 34.1% to 84.1% chance of finishing within 1 standard deviation of the middle (median) date.   How many days or hours is that?  Well, that depends on the width of the graph which is found by estimating the earliest possible start date and putting it on the left of the graph and the longest possible completion date on the right.  Then draw your bell curve between the two.  Simple.

Of course you should consume feeds, but I can't get there fast enough...

It's really hard for me to separate data from view on the first go around. 

I grew up on the web during the heady days of server side MVC.  Server side MVC is still heavily used in the way that steam engines were used into the 1900.   Still, I find it very challenging to create a useful feed and a useful browser side view all in one go.

Agile needs front-end planning model to move away from the current back-end reactionary model...

Here is an (edited) conversation I had over chat with a friend today.

The point of this conversation is that I'm exploring the idea that what Agile is missing is front loaded change feedback.  Something along the lines of, "Ok, we can do that but it'll cost you $5."  The current model works like this, "OK, we did the work, that was days/weeks ago, and it cost you $5."

This is not about controlling change or costs.  It's about visibility.   

Try.Catch.Crap! Getting a string safely without repeating yourself

One thing that comes up a lot is when/where to write try/catch blocks.

When trying to follow DRY, it's often frustrating when you need exactly the same value but in scenario 1 you want the getter to throw if the value is not available, but in scenario 2 you want a default value if the value is not available. I had just such a situation yesterday.

Are Your Activities Making You Smart in a Google World?

KQED recently did a show: Is Google Making Us Stupid? This interview got me thinking... Whether you agree or disagree, there is little doubt that heavy use of the internet changes how you think. You can feel it happening.

Cost of GUIDs as PK...greatly exaggerated

The cost of using GUIDs as a primary key in your DB can be quite high if your DB grows to tens of millions of records, especially if you use random GUIDs. However, the dangers of these practices have been greatly exaggerated and fear mongering from some respected DBAs has caused concern among some developers. So much so that many would NEVER use a GUID as a primary key.

Below, you’ll see that, if use properly, the performance difference between integers and GUIDCOMBs is less than 10%.