How do you estimate projects with fixed dead line and must have features using Agile.

This is a scenario where no project manager would like to be. It is in fact a bad dream. At the beginning you can’t predict the rate of bugs and rework together with the change requests. These critical items that have dramatic effects on the estimates you give. In this article I am going to discuss the best practices that Agile estimation provides for us to effectively deal with this type of projects. I will take an example application to describe this scenario.

The Project: Migrating all the manual work done by a legal firm to Office 365. Basically you need to move all the operations to the Office Cloud, because the particular firm doesn’t like to maintain hardware and the staff want to access to the critical information when they are in and out of the office. All the clerks uses laptops and the legal offices and lawyers use hand held mobile devices such as IPads and Android devices. The firm handles many clients daily and they need an effective way to collaborate and communicate. Technical consultant team provided the best solution with office 365 because it provide all the needs that the user wanted. They also wants to share information with all the legal officers and lawyers. According to the agreement there is a fine if we fail to deliver the project on time, there is a fine for each delayed date. Let’s say it is $1000.00 per day. So if we delay the project by 10 days, the fine would be $10000.00.

After doing initial analysis and the workshop your BA team came up with 100 user stories and you have about 7 months to complete the project. So how do you start? Give a blind dead line and work extra hours and days to deliver. The effective way of dealing with this type of scenario is as follows.

First you need to start recording the following information during the execution of sprints.

  1. Number of backlog items at the start of each sprints.
  2. Sprint backlog committed at the beginning of the sprint.
  3. Backlog items completed during the sprint.
  4. Mean velocity of the team.
  5. New work items added to the back log.
  6. Work items removed from the back log.
  7. Number of bugs reported during the sprint.
  8. Time allocated for bug fixing.
  9. Total number of sprints required for the completion.

At the beginning, even you use agile methods your estimations are not accurate, But as planned the team start to go ahead with the project.
You need to record these statistics at least for 4 sprints (5 would be ideal) to get an accurate estimate. So if we would record the data for the items it will look like bellow (remember, the values are totally assumptions)

table

Let see what happened at the end of couple of sprints.
Sprint 01: At the beginning of the sprint there were 100 user stories and the team committed 10, but completed only 6. At the end of the sprint there were 4 new items added to the backlog and the team contributed 1 bug to the backlog. So the number of items at the end of the sprint is 98. Your team velocity is 6.5 and you have allocated 5% of your team’s capacity to fix the bugs. So you need to multiply team velocity by time allocated for bug fixing, here 0.95. Then divide the remainder of the bugs from the new velocity and you will get the total number of sprints required to complete the project.
Remember you are still at sprint 01. So your estimate is not accurate.

Sprint 02: When starting the sprint 02, the items on the backlog was 98 and the sprint backlog was 10. Team managed to complete 7 items, but they introduced 2 bugs and the Product owner added 3 new items to the product backlog. Also 2 items have been removed from the backlog. So total number of BIs at the end of the sprint is 96. When you do the calculation mentioned on sprint 01, at this stage you will get 14.8 sprints to complete the project. Almost 15 sprints.

As mentioned above you record this data and do the calculation accordingly and your estimates get better at each sprint if the team is performing. There are scenarios where these numbers will go up at first two or three sprints.So by the end of sprint 05 you can come to a value of 12.5 sprints. If you are doing 2 weeks sprints then it will take 25 weeks to complete. So far you have completed 5 sprints that is about 10 weeks. So all together about 35 weeks to complete and it will take about 9 months to complete. According to the agreement there will be a big fine the company has to pay.

Now this information is really valuable to the senior managers to take critical decisions. The management will have following options.

  • The recorded data indicates that how many new items are added to the backlog and the management can negotiate deadline the fine that the company has to pay on these. Because it can be used to convince the client on how the new changes affecting the triple constraints (cost, time and budget).
  • The management can take necessary actions to get new people in to increase the velocity and get the job completed on time.
  • Or else the company can go ahead and complete the project as per the estimation, i.e. within 9 months and pay the fine to save the reputation of the company.

So the conclusion is, with these agile estimation techniques you have the ability to take critical decisions with accurate statistics. Also if you have recorded these data for few different projects over time, you can even use the historical data to predict the estimates of upcoming similar projects, which will eliminate this type of tight scenarios even before start of the project.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s