Skip to main content

How to Start Planning and Estimating Projects in Agile by : Ramesh Kartik




AGILE1.jpg
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

AGILE2.jpg

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

AGILE3.jpg

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.


Reference: http://www.c-sharpcorner.com/UploadFile/rkartikcsharp/how-to-start-planning-and-estimating-projects-in-agile/

Comments

Popular posts from this blog

User Story In Agile Scrum - By Ankur Mistry

In this article, we will learn what User Story is and how to write one. User Story plays a major role here. It is the part of the Agile process where instead of writing comprehensive requirements, we write a short description of a feature. As the  Agile Manifesto  says 'Working Software' Over 'Comprehensive Documents'. What is User Story? User Story is a short and simple description of the feature or requirements of the project. Generally, user stories are written on sticky notes or index cards as a user or role-based perspective. User Story Template As a < type of user or role >, I want < some goal > so that < some reason >. The template identifies 3 questions - "Who", "What", and "Why". If the team doesn't know these three answers, it means they don't understand the story, and if they don't understand the story, then it's difficult to split it well.   Reference:https://mazoea.wordpres

Visual Studio Team Services - Agile - Scrum Project Management Tools

Before starting this article let's understand what is Agile and Scrum.  What is Agile Agile is a  Method  of project management that is characterized by dividing module in to tasks and t asks into short phases of work and frequent reassessment and adaptation of plans. In other words, Agile is a Time Boxed incremental software development method.  What is Scrum Scrum is an incremental agile software development framework  (Agile Framework).   Agile Scrum Process in Short. Product Backlog:  A product owner creates a customer’s wish list and prioritized it and create backlog, called Product Backlog. Sprint Planning:  In this meeting team select small part or module from the Top Priority Wish List of Product Backlog and prepare a small task list. Setting Capacity and Sprint:  Team has to deliver the tasks in 2 weeks or 4 weeks sprint, here Scrum Master bind tasks with Time and User. Scrum Master’s role:  Is to make sure team focused on its goal. End of the sprint:  

The Burn Up Charts In Scrum By: Namrata Parik

I would like to propose a less-taken path in my maiden article to track the progress in scrum. We usually do it using the burn down chart which is relatively easier to understand as compared to the burn up chart. These charts help the team and stakeholders to see and track the progress at any point in the release process or sprint. Burn-down chart provides us the information showing the progress based on the remaining hours or story points from top to bottom. (The burn-down chart can be plotted using story points, task count or the remaining effort) This chart is a plot of expected remaining and actual remaining, this is the most used chart in scrum and since it has only two lines it is considered to be a simple chart. It does not cover the scope creep. So sometimes what might look like ‘no work ‘ done by the team may actually be a result of scope creep. The chart below reflects that the team has not done any progress in Sprint 5 and 6 as the story points remain the same. Image