How does agile teams estimate the size of the project?

Agile teams separate estimates of size from estimates of duration. There are two measures of size:
1. Story points
2. Ideal time

Estimating Size with Story Points

- Story points are a relative measure of the size of a user story.
- A point value is assigned to each item when we estimate story points.
- Relative values are more important than raw values.
- A user story estimated as ten story points is twice as big, complex, or risky as a story estimated as five story points.
- A ten-point story is similarly half as big, complex or risky as a twenty-point story.
- The most important thing that matters are the relative values assigned to different stories.
- Velocity is a measure of a team's rate of progress per iteration.

- At the end of each iteration, a team can look at the stories they have completed and calculate their velocity by summing the story point estimates for each completed story.

- Story points are purely an estimate of the size of the work to be performed.
- The duration of a project is not estimated as much as it is derived by taking the total number of story points and dividing it by the velocity of the team.

There are two approaches to start with:
1. First Approach: Select a story that you think is one of the smallest story and say that story is estimated at one story point.
2. Second Approach: Select a story that seems somewhat medium and give it a number somewhere in the middle of the range you expect to use.

Estimating Size in Ideal Time

Ideal time and elapsed time are different. The reason for the difference, of course, is all the interruptions that may occur during any project.
- The amount of time a user story will take to develop can be more easily estimated in ideal days than in elapsed days.
- Estimating in elapsed days require us to consider all the interruptions that might occur while working on the story.
- If we instead estimate in ideal days, we consider only the amount of time the story will take.
- In this way, ideal days are an estimate of size, although less strictly so than story points.
- When estimating in ideal days, it is best to associate a single estimate with each user story.
- Rather than estimating that a user story will take 4 programmer days, 2 tester days, and 3 product owner days, it is better to sum those and say the story as a whole will take nine ideal days.

What is meant by the term system metaphor? What is its use?

System metaphor- well this is a term which is related to the extreme programming but less known of! What is the system metaphor and what is its use and what is the need? 

We shall be discussing all these aspects of the system metaphor in this article. 

"A system metaphor in the simplest words can be defined as a story that any one includes customers, programmers and managers) can tell reading how a system works".

Reasons why we need to use System Metaphor

There are several reasons for why we need to use the system metaphor.  They have been listed below:

1. Architecture: The metaphor is consider to shape the software system or application exactly as it is required by us with the help of identifying the key objects and giving suggestions regarding the aspects of their interfaces. The dynamic and the static models of the system are supported by the system.
2. Shared Vocabulary: A common system of names for the objects and relationships that exist between them are suggested by a system metaphor only and thus it provides a powerful vocabulary for the developers and programming experts. The vocabulary created is shorthand and specialized.
3. Common Vision: System metaphor comes in to as a very handy tool that helps in enabling all the stake holders to agree up on the working of the software system or application. The key structure of how the problem and the solution have been perceived is provided by the system metaphor itself. Overall, this helps in understanding the working of the system well.
4. Generativity: A system metaphor by the means of its analogies can get you new ideas regarding the problem and its solution and can further dig out many other important issues.

How to choose a System Metaphor?

- Even though choosing up a proper system metaphor for your system may take some time and efforts, it is the best option that you have for exploring several possibilities just by looking at the system through various views. 

- If by combining two metaphors you are getting the one that is fit for your then go for it. 

- Now what if you come to know that you could have got a better metaphor for your system than what you have already opted for? No need to worry, you can still develop your system in that direction. 

- Such a measure will also help you in achieving a greater understanding of your problems. 

- What if you are not able to think of any good metaphors? 

- There are some naive metaphors always available to your rescue. Below mentioned are some examples of the system metaphors:

1. Use of a pension tool as a spreadsheet.
2. Using desktop metaphor for graphical user interface.
3. Buckets, lines and bins in C3 payroll.
4. Bills of materials in VCAPS.
5. A double entry system being used as book keeping and spreadsheet.

More about System Metaphor

- Suppose you sign a contract with a client for developing some software system, what you do next? 

- You search for a good system metaphor that will guide the development of your software system or application.

- A metaphor very well guides the development process of a project. 

- Not any one can choose a good metaphor, it requires skills, practice and of course deep knowledge.

- A system metaphor is nothing but a metaphor having a simple design and some essential qualities that the original needs to have.