A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Scrum: Being asked to do an estimate for a big project

This is one of the biggest confusions that teams end up facing, and this is the same question that we had when we started work on using Scrum as the development methodology. When you start getting into estimating and processing per Sprint cycle, how can you actually prepare the estimates for a project for a client. What is the kind of buffer you give for such a project ? This depends to some degree on whether this is a internal client or a large client. It is not easy to do this kind of analysis so easily, but it can be done.
Now consider that you are asked to do this kind of analysis for a large potential client ? Consider that a lot of clients do not want to really deal with the uncertainty involved with having a project where the total amount can be variable. They already have some kind of overall cost in mind (in most cases, their own internal IT teams would have a big say in determining the total cost of such a project) and they would expect ballpark estimates from the vendor near around this value. There is some buffer involved and some variability, but not too high, and if your estimate is not very different from this estimate, then you are in a good position. Keep in mind that they would want to ensure that you have good processes but in most cases they would not care whether you are using Scrum or waterfall or some other processes, just that you have some good processes in place, and have a good track record.
Now, when you want to start doing these estimates, there are some variables you have to keep in mind, the most important of whether you have an existing team with a track record and for which you already have a good idea of velocity. There are organizations I know which will agree to the client committed fee and setup new teams, together which can create huge problems. You can go through an estimation process, and divide the feature into the User stories, and then do the estimation of these features. However, there is a huge dependency in terms of the team velocity that can make or break the overall project. For this purpose, since the velocity is such an unknown, what you would need to do is to add a fair amount of buffer to your estimate, maybe upto 50% and then make a bid for the same. If you have an existing team that can be transitioned onto this project, then you will have a much better idea of the team velocity, how productive they are, and how well they work together. Based on this, the estimate you can make will be a much more accurate estimate, but it is never necessary that you will have this kind of experienced team available to do this project.
Trying to compress the schedule in order to win the project, but without having an experienced team can be problematic. I have the experience of working in a ISO and many other such standards compliant company which had a number of processes for working out a Waterfall kind of schedule, but the company had to compress the schedule, and the main result of that was that the project became unworkable and ultimately failed. When projects are compressed, the chances of failure increases significantly.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>