Fuzzy Logic

You can use an approach known as fuzzy logic to estimate a project's size in lines of code . Estimators are usually capable of classifying features as Very Small, Small, Medium, Large, and Very Large. We can then use historical data about how many lines of code the average Very Small feature requires, how many lines of code the average Small feature requires, and so on to compute the total lines of code.

Description

Fuzzy logic works best when the sizes are calibrated from your organization's historical data. As a rule of thumb, the differences in size between adjacent categories should be at least a factor of 2. Some experts recommend a factor of 4 difference.You should create the initial size averages by classifying completed work from one or more completed systems. Go through the past system and classify each feature as Very Small, Small, Medium, Large, or Very Large. Then count the total number of lines of code for the features in each classification and divide that by the number of features to arrive at the average lines of code for each feature classification.

When assigning new functionality to size categories, it's important that the assumptions about what constitutes a Very Small, Small, Medium, Large, or Very Large feature in the estimate are the same as the assumptions that went into creating the average sizes in the first place. You can accomplish this in any of three ways:

• Have the same people who are going to create the estimate create the original numbers for the sizes.
• Train the estimators so that they classify features accurately.
• Document the specific criteria for Very Small, Small, Medium, Large, and Very Large so that estimators can apply the size categories consistently.

Planning poker

Planning poker combines multiple expert opinions for estimating. Stories like [Story Points] are prepared for estimation. Each story is discussed. Afterwards each participant chooses from a deck a numbered card that represents his estimate of how much work is involved for a story. When all participants have chosen their estimates, they are revealed and discussed. Planning poker is suitable for initial estimations when the requirements are fixed.

How To

Participants in planning poker include all of the developers on the team. Since Planning Poker is suitable for small to medium-sized projects, the size of the team will typically not exceed ten people.Each estimator gets a deck of cards, for example the cards 0, 1, 2,3, 5, 8, 13, 20, 40 and 100. The moderate opens the discussion by presenting the first user story. The moderator shall be familiar with the project domain since he/she will have to answer any questions. After the discussion each participant selects a card from the deck that represents his/her estimate. When each estimator has selected a card, the cards are simultaneously presented. Each estimation may differ significantly. The participants that gave the highest and lowest estimate explain their selection. The participants discuss the estimations. After the discussion each estimator re-estimates by selecting a card. The activity is repeated until all estimations are nearly the same.

It often happens that the discussion takes too long and goes into the wrong direction. To prevent this it could be helpful to define a timelimit, for example 3 minutes, for discussion of the estimates of each story or only take a subset of the team by splitting the team into two or three smaller teams.

Story Points

Story points are units used to estimate software cost with relative units of size. These units are a measurement of complexity or size of a requirement compared to the duration to complete a requirement. The actual units of time can be assigned afterwards.

Description

No project can go very long before someone starts asking "When will you be done?" The best approach for estimating stories would be one that: 

• allows us to change our mind whenever we have new information about a story
• works for both epics and smaller stories
• doesn't take a lot of time
• provides useful information about our progress and the work remaining
• is tolerant of imprecision in the estimates
• can be used to plan releases

An approach that satisfies each of these goals is to estimate in story points. A nice feature of story points is that each team defines them as they see fit. One team may decide to define a story point as an ideal day of work (that is, a day without any interruptions whatsoever—no meetings, no email, no phone calls, and so on). Another team may define a story point as an ideal week of work.
The technique is similar to fuzzy logic, but there are some interesting and useful variations that make story points worth discussing separately.
Since story estimates are owned by the team it is important to have a reasonable portion of the team involved in coming up with the estimates. If the team is large (perhaps seven or more), not every developer needs to be involved, but generally the more developers involved the better. The customer participates while the programmers estimate, but she isn't allowed to contribute her personal estimates or editorialize when she hears an estimate she disapproves of. The goal is for the estimators to converge on a single estimate that can be used for the story. It rarely takes more than three rounds, but continue the process as long as estimates are moving closer together.
It is important to notice that:

• Estimate stories in story points, which are relative estimates of the complexity, effort or duration of a story.
• Estimating stories needs to be done by the team, and the estimates are owned by the team rather than individuals.
• Triangulate an estimate by comparing it to other estimates.
• Whether or not a team programs in pairs has no impact on story point estimates. Pair programming affects the team's velocity, not their estimates.

How To

When using story points, the team reviews the list of stories (or requirements or features) it is considering building\cite{McConnel_BlackArt05}. When the story cards are finished, gather together the customer and the developers who will participate in creating the estimates. Bring along the prepared story cards and a stack of additional blank note cards. Distribute a handful of blank cards to each participant. The customer selects a story at random from the collection and reads it to the developers. The developers ask as many questions as they need and the customer answers them to the best of her ability. If she doesn't know the answer, she takes a guess or asks the team to defer estimating that story.When there are no more questions about the story, each developer writes an estimate on a card.At this stage of their use, the story points are not terribly useful because they are a unitless measure—they don't translate into any specific number of lines of code, number of staff days, or calendar time. The critical idea behind story points is that the team has estimated all the stories at the same time, using the same scale, and in a way that is substantially free from bias.
Stories are normally assigned to a numeric value from one of the scales shown in the following table.

When everyone has finished writing an estimate, the estimators turn over their cards or hold them up so everyone can see them. It is very likely at this point that the estimates will differ significantly. This is actually good news. If estimates differ, the high and low estimators explain their estimates.Other estimators will undoubtedly have opinions on whatever reasons the high and low estimators were at the extremes. The customer clarifies issues as they come up. A note or two may be jotted on the story card. Perhaps a new story or two is written.
After the group has discussed the story, the developers again write their estimates on cards. When everyone has written a revised estimate, the cards are again displayed. In many cases the estimates will already converge by the second round. But, if they have not, repeat the process of having the high and low estimators explain the thinking behind their estimates. The goal is for the estimators to converge on a single estimate that can be used for the story.
After the first few estimates have been made, it becomes possible (and necessary) to triangulate the estimates. Triangulating an estimate refers to estimating a story based on its relationship to one or more other stories.\cite{Cohn_Agile04}
After the iteration has been completed, the team will be in a position to have some real estimation capability. The team can look at how many story points it delivered, how much effort it expended, and how much calendar time elapsed, and it can then make a preliminary calibration of how story points translate to effort and calendar time. This is often called velocity.