Estimation as the name suggest is to find the approximate timeline. Estimating is one the hardest aspect of the software development. Estimating for traditional software development fundamentally different from estimating for Agile projects.

The traditional approach follows the "bottoms-up" approach which is to spend several weeks or months at the beginning of a project defining the detailed requirements for the project, once the requirement gathering is complete for the project, then project broken down into tasks and each task is estimated to find out the estimation for the complete project. By contrast, Agile projects use a "top-down" approach, using gross-level estimation techniques on feature sets, then employing progressive elaboration and rolling-wave planning methods to drill down to the task level on a just-in-time basis, iteratively uncovering more and more detail each level down.

Product Backlog

The Product Backlog is a feature list or a list of User Stories. It is a simple list of things that are of important  to a product owner - not technical tasks - and they are written in business language, so they can be prioritized by the Product Owner. There are no details about each feature until it is ready to be developed, just a basic description and maybe a few notes if applicable. Each item on the Product Backlog is given a points value to represent its size. Size is an intuitive mixture of effort and complexity. It's meant to represent how big it is.

Team up with the product owner

The product owner prioritizes the backlog (backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. Product owners has the understating of their requirement (requirement gathering) of their business capture requirements from the business, but they lack the understanding of the details of implementation.  The estimation of the backlog falls on the development team. The development team begins its estimation process, questions usually arise about requirements and user stories and these questions help the entire team understand the work absolutely. For product owners, specifically, breaking down work items into smaller pieces and estimates helps them prioritize all areas of work. 

We work very closely with the product owner for the product understanding, requirement gathering, estimation and development of the sprint. We encourage our product owners to actively involve for complete development cycle.

Story points 

For a traditional software development teams give estimates in a time format: days, weeks, months. But agile teams give estimation through transitioned to story points. Story points rate the relative effort of work in a Fibonacci format (Fibonacci goes 1, 2, 3, 5, 8, 13 - where each number is the sum of the previous two, this builds a natural distribution curve into the estimates.).

In short, story points are measurement units that help estimate the amount of effort needed to develop a feature. Each story point is assigned a relative value, and these values together give the size of the user story. 

The size of the user story is divided based on the team's velocity and the number of iteration would require for the project. By taking the number of iterations, and the number of weeks a normal iteration takes, to determine the relative length of a project. Story points, therefore, allows to estimate the length of the project.

How to Assign Story Points
As we know the size of story points are relative to one another, following are some of the ways to assign story points:

1. Give the smallest story a value of 1, and then rank the others in comparison to that. If the next story is five times the amount of work of the 1 valued story, give it a 5.

2. In this an averaged sized story identified, something which is not too small or too big, and can be assigned a ranking of 5. All other stories should be compared with story    assigned with rank 5, and ranking can be provided to these stories between 1 - 10. If a story point bigger than rank 5 but not the largest one either, then rank 8 can be provided to the story.

The greater the size, complexity, risk, time, difficulty, and uncertainty associated with a story, the greater it's value should be. The most important thing about assigning story point size is to remember that the values are relative to one another. A 2 story point story, for example, should be twice the effort of a 1 point story. Ranking of the story points should always is in comparison to another, in order to give it the right value.

For estimation, we at CodeFire provide story to all our team members, they provide the points (1 through 5. Estimators (team lead/Project Manager) then considers how much effort to include for dealing with the risk and uncertainty in the product backlog item.

Affinity Grouping
A faster way to estimate for Agile, which is used when the number of items are large to estimate is affinity grouping. In this, team members group items together that are like-sized items, creating separate group for the items of similar types. The method is simple and fast:

• The first item is read to the team members and placed on the wall.

• The second item is read and the team is asked if it is smaller or larger than the first item; placement on the wall corresponds to the team's response (larger is to the right, smaller is to the left).

• The third item is read and the team is asked if it is smaller or larger than the first and/or second items; the item is placed on the wall accordingly.

• Control is then turned over to the team to finish the affinity grouping for the remainder of the items.

Teams may choose to continue in the same fashion, placing one item at a time on the wall after group discussion. However, a faster way is to have each team member select an item and place it based on their own best understanding. This is done with all team members working in parallel until all items have been assessed and placed on the wall. Several hundred items can be estimated in a relatively short time. Once all items are on the wall, the team reviews the groupings. Items that a team member believes to be in the wrong group are discussed and moved if appropriate. Once the grouping is done then estimation value (points) can be assigned.

Ideal Days
Everyone go to the office, there are different things to do outside of the project they are working on - like responding to email, attending meeting, etc. The length of time required to complete a project, without worrying about all the additional things, are known as ideal days.  

This is an estimate in ideal days assumes that you're working on the project alone. For example, if working on a particular feature of the project would requires 40 hours, i.e. it would take five ideal days. It's important to remember that ideal days are not the same as elapsed, or real, days. If one spends 2 hours outside of the project, the real amount of time it would take complete the work would be close to seven real days.

When determining how long it will take a user story to be completed, at CodeFire an experienced project manager, who knows the capability of the developer determines the time duration (in conjunction with developer).

All the approaches and techniques above are designed to build trust in a team and to build confidence in clients' on how long and how much it will take to build a software product. Estimation is a practice, with time and experience team will be able to estimate better.

We at CodeFire, use all the above methodology as and when the need arises, however, we use our experience of the previous estimation as the benchmark for all our estimation.