How to Start Planning and Estimating Projects in Agile

Introduction

Earlier we saw more software failures simply because of planning or estimating. When Agile is used, failures have been reduced significantly since it gives iterative releases based on the changing customer's needs with an approach of frequent planning and estimating.

So here we see the article called "How to start planning and estimating projects in AGILE". This is an overview of what measure the project estimate can be done and how to we measure it. In what way we can measure the velocity of a TEAM.

With the foundation I am creating in this article, I shall tell you the various techniques for estimating and re-estimating strategies in my next article.

The Size of ESTIMATION

Agile Teams separates estimates of size from estimates of duration. The size of the work should be estimated first before deriving the duration of it.

Let us discuss this with a day to day life example. In your house suppose you are assigned the task to move the location of a sofa set from the hall to the master bedroom in the first floor. You could just not look at the sofa and directly estimate the job at 4 hours. Doing so, you are bypassing any estimate of size and went directly to an estimate of duration.

So you need to first see the dimensions of the sofa, parts of the sofa and estimate it about 800 cubic feet. This is your estimate of the size of your project. But an estimate of size alone is not useful in this case. Now you want to know how long it will take to move the 800 cubic feet sofa that has 4 parts to move into the first floor. Each part is 200 cubic feet.

Assume you have a trolley with the capacity of 200 cubic feet. Dividing 800 cubic feet by 200 cubic feet (trolley capacity), you need 4 trips to load the entire sofa to the first floor. Also you estimate that each trip will take 10 minutes to load into the trolley, 5 minutes to unload it and 10 minutes to move into the first floor. The total time per trip is 25 minutes. For the entire sofa you need 4 x 25 minutes = 100 minutes. Around 2 hours to complete this project.

As this picture depicts, the estimation of the duration of the project begins with estimating its size.

Estimating Size in terms of STORY POINTS

Story Point

Story point is an arbitrary measure used by scrum teams to measure the effort required to implement a story. It is a measure that tells the team a combination of amount of effort involved in developing a feature, the complexity of developing it and the risk inherent in it.

Mindset one should have about Story Point OR Background of story point

"You are entering a restaurant opened newly in your locality and asking for a soft drink since you are so thirsty at the moment. You've probably been to many restaurants like this, so you know the soft drink bottle sizes that are available everywhere, At the max you will ask the server how size the bottle is rather than how many ml of soft drink will be in that bottle. The server will likely respond by holding his hands apart to illustrate the size. In these cases you are ordering by relative rather than the measured size. Here all you need to know is that a large bottle is larger than the medium sized or small sized one, without thinking about how many ml of soft drink there is. So as like it is possible to estimate an agile project's user stories or features in the same way. All you need to know is whether a particular story or feature is larger or smaller than other stories".

Relative Comparison

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A Story that is assigned a two should be twice as much as a story that is assigned a one.

The raw values shall be a numerical or according to a T-Shirt size range from X-S (extra small) to X-L (extra large) or the height of animals. Everyone knows very well about the height of animals or sizes of the T-shirts. Or the team can define new values for story points, whichever is comfortable for them.

One common approach is to select a story that is somewhat medium and give it a number somewhat in the middle of the range, say five story points. Once you have assigned a story point value to the first story, each additional story is estimated by comparing it with the first story or with any others that have been estimated.

Velocity

Velocity can be calculated by summing up the number of story points assigned to each user story that the team completed during the iteration. If the team completes 3 user stories, each estimated at 5 story points then their velocity is fifteen. If the team completes two five point stories their velocity is ten.

If the team completes 10 story points of work in the last iteration then the velocity of the team is 10 story points. Because the team will do the 10 story points in the current iteration.

VELOCITY = Summing up of story points completed during iteration

If the team completed ten story points of work the last iteration, our best guess is that the team will complete ten story points this iteration. If we sum the story points estimates for all the features we come up with the total size estimate or the project. Say for example: 300 story points.

We should divide it by the team velocity to get the number of iterations, 300/30 = 10 iterations. We can turn this duration into a schedule by mapping it onto a calendar.

ITERATION = Total story points estimated for the project/Team velocity

Why NOT Estimate in IDEAL DAYS?

Because of the natural interruptions we see everyday in the office, on any working day in addition to the planned activity we may get unplanned activities in the project like checking and replying emails, making an urgent support to the customer, Town Hall meetings, some clarifications we need to clarify other team members, personal urgent phone calls, like wise the list keeps going.

With this the problems arise when the manager asks a team member, how long to finish this task? The developer simply says that it requires 5 days to finish it. The manager checks his calendar and marks the day when it will be completed.

We may choose user stories estimate in ideal days, but you should assume:

The story being estimated is the only thing you will work on
Everything you need will be on hand when you start
There will be no interruptions

But the preceding environment is highly impossible. So we should always try to estimate in story points.

Why are Story Points not better than Development Hour Estimates?

The Estimating process is much faster because we are not bogged down in technical implementation details
Over the sprints, the same process can be re-used for future efforts by the team. Used to predict the future easily estimating in hours is more difficult to obtain and also a detailed discussion is necessary

Summary

Story points are a relative measure of the size of the story. The relative values are assigned to various stories. no matter what the values are. In the next article we shall see the various techniques for estimation.