Software Project Estimation Part 7: Story Points

This post is part of my series on Software Project Estimation:

Story Point Estimation is the most popular form of estimation on projects using Agile methodologies. Using this technique, you begin with all of the User Stories, or Use Cases, for the project. Then a number is assigned to each of those stories to indicate their relative size. Normally, this number is from the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.) or a power of 2 (2, 4, 6, 8, 16, etc.).

When the numbers are first assigned, they are not given a unit of measure. That is, a User Story that is assigned a “2” does not necessarily take 2 hours or 2 days to complete. The numbers are assigned based on the estimated size relationship between the User Stories. That is, if User Story 1 is assigned a “2”, and the team decides that User Story 2 is around 50% larger that User Story 1, User Story 2 will be assigned a “3”.

Once all of the User Stories have been assigned a number, the team will decide what they thing their starting velocity will be. They may decide that they can complete work on 20 Story Points per 2 week iteration. The User Stories to be completed during the first iteration will be determined based on this Velocity. Project Management can also use this velocity to project when the entire project will be completed.

After each iteration, the actual velocity will be computed to determine if the number of Story Points per iteration needs to be adjusted up or down. Based on this adjusted velocity, management can determine if they need to push out the end date of the project or remove User Stories from the scope.

Story Points is a great estimation technique to use in Agile development where you aren’t expect an precise estimate.  It gives you a tool to measure how the work is progressing and to project when the work will be complete.

What’s New?

Emma and Caleb

It’s been way too long since I have posted updates to this site.  So, what’s new??

Well, for one thing there is a new member of the Peters household.  Caleb Reed Peters was born on April 18th.  The “big kids” are very excited about their little brother.  But, as you can imagine, things are pretty crazy lately.  So, not quite so much time for blog posts.  The above picture is Emma holding her new baby brother.  For more baby pictures, head on over to our family blog.

And work has been pretty busy as well.  Never mind the fact that Hertz announced that they were going to acquire us.  Then, only a week later Avis announced that they would pay even more.  Day to day work hasn’t really changed at all since then, it’s all business as usual.  But I have been in the middle of several big projects that have been keeping me very busy.

So, things are crazy right now, but more blog posts are coming.  I’m working on at least one more post in my Software Estimation series, and I have posts started on several other subjects.

Outsourced

Last night I was sure that FlashForward was starting back.  So, after a long day at work and after getting the kids down to bed, I crashed on the couch ready to watch.  But it was not on my TiVo.   Come to find out, we have a couple more weeks before it starts again.

So I found myself browsing Netflix’s Watch Instantly library looking for something to watch.  Outsourced caught my eye.  Having worked in the IT industry for a long time, I have a lot of friends and coworkers from India.

Outsourced tells the story of Todd Anderson, a call center manager whose job gets outsourced to a call center in India.  He is then sent to India to train his replacement and help improve the call center there.

One of the most memorable scenes shows him trying to explain cow branding to the call center workers, in an effort to explain some of the products they are selling.  He’s trying so hard to teach them about Americans so they can talk effectively to Americans on the phone.  One of the workers looks at him and says, “You really need to learn about India.”

The rest of the movie shows him learning more about India, their religion, and culture.  I was struck by the fact that I have worked with Indians for so long, but I also have learned very little about their country.

It was a very funny and eye-opening movie.  I would recommend it to anyone that also works with people from India.

Software Project Estimation Part 6: Function Point Analysis

This post is part of my series on Software Project Estimation:

Function Point Analysis is one of the estimation techniques I have been most excited about over the past few years.  It’s actually a specific implementation of the “Count” methodology that I talked about prevoiusly.  But, I figured it was important enough to give it it’s own post.

In Function Point Analysis you count the number of Function Points in a project.  To get there, you first have draw a boundary representing the scope of your project.  You then make an inventory of all of the interfaces (data in motion) and files (data at rest) associated with the project.

There are 2 different types of files that have to be identified:

  • Internal Logical File (ILF): A file whose data is created and maintained by this application.
  • External Interface File (EIF): A file whose data is referenced by this application, but not maintained by it.

For each one of the file types you have to count the number of record element types (tables) and data element types (columns within the tables).  Based on these counts, each file is assigned a number of Function Points.  The important thing with these files is to keep in mind that they might not actually be a database or a file.  They could be something like another system that is interfaced with.

There are 3 different types of iterfaces that have to be identified:

  • External Inputs (EI): Data coming into the system from outside the system.  An example would be a user’s login form.
  • External Outputs (EO): Data coming out of the system from inside the system. An example would be a report.
  • External Inquiries (EQ): An interface where some data comes in which causing processing and then some data coming out.  An example would be a search form.

For each of these interfaces, you have to identify the number of record file types that are interfaced with and data element types that are carried along the interface.  Based on those counts, each interface is assigned a number of Function Points.

Once you have identified the interfaces and files and assigned a number of Function Points to each, you can add up those counts and come up with your Unadjusted Function Point count.

The Global System Characteristics can then be used to adjust this Function Point Count.  The Global System Characteristics are attributes used to assess the complexity of an application.  Once you assign a rating to each characteristic, you come up with an adjustment factor.  It may be something like 1.1.  You then muliply your Unadjusted Function Point Count by this adjustment factor to get your Adjusted Function Point Count.

At this point you just have a number which is pretty meaningless on its own.  However, industry standards exist showing, on average, how long it takes application development teams to complete projects of different Function Point counts.  In my experience doing .Net projects, I know that it takes about 15 hours per Function Point for coding and unit testing.

This will give you the hours for development.  The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.

It’s very easy to learn the basics of counting Function Points.  Becoming an expert, however, takes lots of study and practice.  If you give the same project requirements to two different expert counters, their counts will come out almost identical.  This makes Function Point Analysis a very useful methodology for estimating the size of a project.

foursquare vs. Gowalla vs. brightkite: The Location Based Social Networking War

Ok, so for the last couple weeks I have been using three location-based social networking tools, trying to determine which I like best.  The contendors are foursqure, Gowalla, and brightkite.

First, let’s talk about the concept.  Using these tools you “check in” at locations you visit.  Seems like a neat way to see what your friends are doing and find interesting places to go and things to see.  Each of these tools will post to Facebook and Twitter so all of your followers on those services will see updates.  And each of these tools have great iPhone apps.  The problem is that they each of great features, and several shortcomings.  So, I’m having trouble picking one.

foursqure

Foursqure is the most popular of the three.  I love the concept of becoming a Mayor of a location and collecting Badges.  But, it doesn’t give you an easy way to see on a page what your friends are doing, or who is currently near you.  Both of these seem obvious features that I just cannot find on their website.  Actually, on the home screen of the iPhone app you see where your friends currently are, but I cannot find it anywhere on the website.  However, the majority of my friends using one of these tools is using foursqure, so that is a plus for it.

Gowalla

Gowalla is the next most popular.  Unlike foursqure, on the Gowalla home page you can easily see what your friends are doing.  It also has the concept of Creators and Founders, which seems very similar to the Mayors on foursquare.  I love the large locaiton icons it uses and the stamps you earn and items you can drop.  Gowalla was really looking like it would come out in first place for me, but it does something strange with the Twitter posts.  When it posts to twitter it seems to insert a random “@” username in for the location name.  I can’t find on the locations where these twitter usernames are set.  Seems like a pretty major bug to me, so I don’t think this is going to be the one I end up using.

brightkite

Brightkite is the least popular of the three, but surprisingly the most feature rich.  You can easily see people near you at any radius you select.  You can also easily see what your friends are doing.  It also gives you the ability to upload a picture when you checkin.  You can set it up to automatically push that picture to Flick or your Facebook photo album.  It doesn’t seem to have any concept like a Mayor or Founder.  But that’s not a huge deal.  Really, the biggest downside for me on brightkite is the fact that I only have a few friends on it, and almost all of them have switched exclusively to foursqure or Gowalla.

So, in my personal opinion, brightkite should win the war of the location based social networking tools.  Do I think it will?  Probably not.  Foursqure and Gowalla are currently much more popular.  But brightkite is the most feature rich and seems the most stable.  So, everyone out there who is looking at these tools, let’s all switch to brightkite and call this war over!

If you are using any of these three, add me as a friend.  Here are the links to my profiles:

My thoughts on Lost Season 6 Episodes 1 & 2: LA X

Ok, so I’ve been thinking a lot over night about what’s going on in Lost, and here are my current thoughts.  Do not read if you haven’t seen last night’s episodes yet, there ars spoilers below.

What’s with the Alternate Timeline?

When Juliet set off the Nuke in 1977, the alternate timeline was created.  Why?  Because it had to be.  If you think about cause and effect, a paradox would have been created otherwise.  If the alternate timeline were not created, then setting off the nuke would have caused the plane never to crash in 2004.  If they plane never crashed in 2004, then Jack and team never went back in time to set off the nuke that caused the plane to not crash.  You have a paradox.

So, instead of creating a paradox, the alternate timeline was created.  The whole Infinite Universes theory.  The effect of them setting off the nuke in the main timeline was the nuke going off in the alternate timeline.  Though in the main timeline the nuke did not go off because it couldn’t.

So, in the main timeline, the group jumps back to where they are supposed to be in time: 2007.  This catches them back up to where the rest of their group was.  And now everyone is back together in the main timeline.

In the alternate timeline, the island has now sunk in 1977 because of the nuke.  This causes the plane never to crash in 2004.  But, it also causes a series of effects beginning in 1977 which ultimately cause the little differences we see on the plane in 2004.  Differences such as Shannon not getting on the plane with Boone to go home, Hurley having good luck instead of bad, Michael and Walt not being on the plane, etc.  However, everyone on the plane is going to have a strange sense of deja-vu because of what has happened in the main timeline.  Jack experienced this when he saw Desmond.

What’s up with Jacob, his Nemesis, and the Other Others?

First of all, the Other Others.  These are simply part of the Others who live at the Temple.  We’ve seen Cindy, Zach, and Emma (who were from the tail section) before with the Others. They are preparing for an attack by Jacob’s Nemesis, as the Smoke Monster, now that they have heard Jacob (thier spiritual leader) is dead.

Jacob and his Nemesis represent the battle between good and evil.  Jacob has his Nemesis somehow trapped at the island so he cannot leave.  The Nemesis wants desperately to leave and the only way he can is by killing Jacob.  So, he arranges the series of events we saw last season with Jacob ultimately being killed by Ben.

Jacob and his Nemesis are disputing over the ultimate good or evil in man.  Jacob keeps bringing people to the island trying to show that a good, peaceful civilization can live there.  This results in the Others.  The Nemesis keeps corrupting groups of people causing the endless fighting that is occurring there over the years.

So, in both timelines, Jacob is dead.  Evil has won.  What we’re going to see this season is Jacob, speaking through Hurley, arranging events to send Jack and team back in time to stop Ben from killing Jacob.  I think Sayid will ultimately be the one to stop Ben.  When this happens, it will create another alternate timeline where the balance between good and evil, Jacob and his Nemesis, is restored.

So, that’s my current thoughts on what’s going on.  I’ve excited to see what happens over the rest of the season.

Software Project Estimation Part 5: Count

This post is part of my series on Software Project Estimation: 

Today’s I’d like to dive into another software estimation methodology.  I’ll refer to this only simply as Counting.  Using this technique you find something to count and base your estimation upon that count.

So, the first step is to find something to count.  What should this be?  Here are some examples of things you could count:

  1. Requirements
  2. User Screens or Web Pages
  3. Function Points
  4. Use Cases or User Stories
  5. Database Tables

Whatever you decide to count needs to satisfy a couple requirements:

  1. It must be available early on in the project (preferably at the Requirements stage, not the Technical Design one).
  2. It should be highly correlated to the actual effort invovled to execute the project.
  3. You should have historical data available telling you how long it will take for you to construct it.

Let’s say, for instance, you are creating a web site and you decide that you are going to count the web pages to try to get an estimate for the project.  Looking at your historical data, you determine that the web pages you have created have fallen into three categories: 1. Simple (static text), 2. Avarage (simple data input / retrieve), and 3. Complex (more difficult data input or retrieve).  Your historical data reveals the following average construction times for these web pages:

  1. Simple: 4 hours
  2. Average: 16 hours
  3. Complex: 40 hours

To come up with your estimat, you simply have to inventory the web pages you are going to create as part of this project, and assign them to those categories.  Using these counts, you can come up with the total amount of time for coding and unit testing.  Based on your project breakdown percentages you can then derive the time for the other phases and get your complete estimate for the project.

This technique can be further refined by breaking your components into those that are being Created or just Modified and getting afterage times for Simple, Average, and Complex components in those two categories.

An additional factor can be added to this estimate to take into account the skill level of the developer doing the construction.  Say, for instance, you estimate what it would take for an Average developer to do the coding.  From your historical data it my be clear that it takes a Novice 50% longer to do the construction and an Expert only 3/4 the time.  So, you could break your components down by the skill level of the person doing the development, muliply the Novice ones by 1.5 and the Expert by 0.75.

So far I have been describing this estimation technique in a way that relies heavily on having your own historical data available.  But, what if you do not have this information?  In that case I would recommend using an industry standard metric to count that has associated industry historical data avaiable.  Function Point Analysis is a perfect example of a very refined Counting technique.  I will explore this in detail in a later post.

Software Project Estimation Part 4: Expert Judgement

This post is part of my series on Software Project Estimation:

Expert Judgement is the first estimation technique I’m going to explore. Normally when a team is trying to come up with an estimate for a project, they do something very similar. Someone will sit down with a list of features and guess how long it will take for the team to do the development. Most of the time these estimates vary widely from actuality. But, there are things that can be done to make them more accurate. 

The first step is to be carefull when picking your expert to do the estimate. The export should satisfy the following qualifications:

  1. They must be an expert in the problem domain. That is, they should understand the business and technical side of the problem.
  2. They must be an expert in the technical domain. They should have a deep understand of the systems that this project will integrate with. They should have been invovled with several projects in the past in this domain.
  3. They must be an expert in the tools and technologies being used in the construction of the project.

The next step is to not just take a single estimate from the expert for each feature. The export should give the following estimates:

  1. Best Case: If everything goes just right, how quickly could the feature be built.
  2. Worst Case: Assuming everything goes wrong and road blocks are encountered at every turn, how long with the feature take.
  3. Most Likely Case: Based on the previous two estimates and his past experience, how long does the expert really think the feature will take.

Based on these three numbers, an industry-standard “Program Evaluation Review Technique” (PERT) can be used to calculate the Expected Case. PERT does this by putting a different weight on each of the three numbers with the following formula:

  • Expected Case = (Best Case + (3 x Most Likely Case) + (2 x Worst Case)) / 6

By adding up the Expected Case for each feature, the total amount of time for coding and unit testing can be determined. The percentages assigned to each phase of the project can then be used to determine how long the entire project will take.

Using this technique, you are still dependent on one person’s opinion. Often times you can’t find a single person that meets all of the qualifications of the expert that you need to do the estimate. This technique can be improved by having several experts independently use the above technique to come up with their own estimates. Then, have all of the experts come together an discuss each of their estimates. By talking about the reasons for the differences, the experts should work together to come up with a consensus estimate. The numbers from this consensus are then applied to the above formulas to determine an estimate for the project.

Expert and Group Expert Judgement are great methodologies to use early on in the project when the required features are known, but little about exactly how the solution will be constructed.

In the next post, I’ll investigate another estimation technique that works early on but does not require experts in the domain to do the estimate.

Software Project Estimation Part 3: The Cone of Uncertainty

This post is part of my series on Software Project Estimation:

The Cone of Uncertainty is another point that is very important to understand when trying to come up with an estimate for the execution of a software development project.  I originally planned on going pretty deep into the topic, but I found an article online that does a better job at it.  So, I’m going to cover it at a high level and then point you to that other article.

Early on in the project, very little is known about the detailed functional requirements and exactly how the solution is going to be constructed. Because of this lack of information, you need to understand that your estimate could be off by a certain percentage. As the project progresses, more is known about it so estimates get more accurate.

The following shows the amount of variance in estimates in different phases of the project:

  1. Scoping: -50% to +100%
  2. Requirements: 20% -33% to +50%
  3. Design: 20% to +25%

There are, however, techniques that can be utilized while putting together your esitimate that can help to make it more accourate.  In the following posts I’ll be addressing several different estimation techniques.  Each have their pluses and minues and are more appropriate at different phases of the project.

A very good article on the Cone of Uncertainty can be found on the Construx website here.

Many people have been emailing me asking about the estimation techniques that I am going to cover.  I’ll begin diving into those in the next post.  The first one will be ‘Expert Judgement’.