Estimating Projects Part III

In previous articles on planning and estimating projects, we explored the basic principle of estimates. Estimating cannot really determine precisely what we will provide to the client or what the exact date will be. To do this accurately, and to provide the client with the correct information about the possible end date of each of our projects, we need to determine the exact time that we need to perform all possible tasks that fall within the scope of the project.

However, we can never estimate the finish date for any of our projects by measuring the amount of work in calendar units, such as hours, days, weeks, or months. If we try, we'll give overly optimistic and completely unrealistic values. This is the easiest way to lose customers, because every project will run overtime and will exceed the client's budget. As you know, having one dissatisfied customer can lead to many more dissatisfied customers, and that would be a major problem. Fortunately, we have some tools that can help us.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

A little magic from the multiplication table

In most projects with which I was involved, we used no such thing as a magic multiplication table. I learned later that a very large number of managers use the same multiplier in estimating projects. What is the magical factor in this case? Certainly, it is usually somewhere between 1.0 and 3.0, although sometimes the magic multiplier is greater. It is the number by which estimates provided by the team are usually multiplied. Choosing the number is the task of the project manager, who thus builds a buffer for his own safety. This technique protects every good project manager against excessive optimism of the programmers. But in most companies there are a dozen or so managers at various levels, so there are a dozen or so levels of project management and each of the managers might apply a multiplier to the case. And you know what? This use of multipliers can make the estimate for each project expand. Sometimes, however, the extra time will all be used, so the project is completed well after the deadline. In that event, each project manager will increase the value of the multiplier, creating an extra reserve of time for future projects.

A similar but somewhat different method that can give much better results is to estimate the complexity of the issues to determine the time it will take to complete the project. The complexity of the project can be converted in a variety of ways, which we mentioned earlier. For example, a calculation based on a line of code is usually very inefficient. The complexity of the problem can also be calculated by the number of interfaces or components, as well as other methods already mentioned. In addition, it can be calculated using the number of operations on the data, but this method is usually not recommended by anyone. The story point method is frequently used for counting the complexity of projects. This is the method most often used in projects that are created using Agile methodologies.

Scaling story points

The story point is something we can estimate, and it is very efficient. We estimate the relative value by setting the size of the story in relation to other stories that we have used. In other words, we determine if the project is a story more or less complex than other stories. Thus we avoid estimating the size of the stories in hours, days, or weeks, and use points instead. These points are called story points (SP). For example, we might determine that a project with 3 SP is one and a half times greater than a project with 2 SP However, this estimate really does not say anything about the actual time it takes to deliver a story to the customer.

Now, let's scale stories. It really is very easy to distinguish, even by moving the complexity scale. However, sometimes this is a sensitive issue for beginners in the subject. For example, a story with a level of 11 is quite similar to one in which the scale is 12. Therefore, I used only a few numbers to estimate the individual stories. Most common are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100. But note also one of the patterns. When we are dealing with a very large number of stories, which does not happen in most of the projects, where there are approximately 30 to 35, a full-scale failure actually does not matter. Why? Because estimation errors will average out over the entire range of design work. In addition, stories that have the greatest value will not be so huge, because during the project I will have to break them into smaller and smaller tasks, resulting in a much more accurate estimate.

And now we come to the crux of this section. If we know the complexity of the project and the total story points for all stories that occur in the project, we can easily estimate how long the project will take. For this purpose, simply multiply the total Story Points by the velocity; that is, how many stories the user is able to provide the team during the iteration. But pay attention to one thing: if you carefully read the previous articles, it appears that we begin to have the historical data after the first iteration, that is, in less than two weeks. And one more thing is worth noting: namely, after a month or two, the accuracy of the estimates that we make is definitely much higher and better than with traditional methods of planning projects.

Time to play Planning Poker

Usually, when I start talking about Planning Poker, people laugh because they imagine the card game. Sometimes the audience asks how a card game can help with professional IT project planning? Well, a lot. Planning Poker is a very unprofessional name, but it is a very common phrase in the vocabulary of the Agile, and Scrum in particular. In fact, Planning Poker is one of the most effective techniques for estimating projects. Not only that, this method is very fast and very accurate and it also provides a lot of fun. So why not try it when planning projects?

Planning Poker is used primarily to estimate how much value to assign to each user story. Making an estimate using Planning Poker involves the whole team, so everyone can freely express their opinions. In addition, we require the presence of the product owner, whose task is to explain the details of each of the user stories. Every member of the team is given a set of cards with the values ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100. These cards are used to determine the story points needed to value the user story. In addition, the deck of cards used in Planning Poker should include a card with a picture of coffee, meaning "Time for a break, I need to think about it," and a card with a question mark, meaning "Hey, guy, I do not know what you mean, I do not know the project, and I have to think about it."

After gathering the entire project team and the product owner, the estimation meeting can begin. It usually runs like this:

• The moderator, who is usually the product owner, reads the full description of the user story and answers any questions.
• The product owner then counts out loud to three, and each member of the project team chooses a card representing the how many story points he or she believes should be assigned to the user story.
• Sometimes, estimates vary greatly after the first ballot, but you should not worry about it. The next section tells you what to do if this happens.
• Those who proposed the lowest and highest values are asked why they made those estimates for the user story. They are not asked to defend the value, but to present logical arguments for the number.
• The vote is then repeated.

After two to three ballots, the project team usually comes to an agreement. This takes you to the next user story. How does Planning Poker work when we do not have any user story? You usually have to choose one of two approaches: write a simple user story and specify that the story point is 1, or select the medium user story value and say that it is a 5-point story. Why do you think?

Summary

Perhaps you wonder why Planning Poker is used? Perhaps, after reading today's article, you still don't have a clue, but slowly all the techniques for estimating projects are coming together in one particular unit. Why use Planning Poker? Because it really works. Why does it work?

As you may recall, in all the previous articles I talked about managing risk and human resources in an Agile software development project. I mentioned a few other methods of evaluation besides Planning Poker. I did it because I think that tor years, schools and developers and project managers have implemented techniques that work for their immediate benefit but which I know will not work for larger projects. I use mostly their own experience, gained from working with hundreds of projects. All who are engaged in software development in your company have their own techniques. So why do I recommend Planning Poker?

Planning Poker has one major advantage: it enhances communication between people who participate in the project. I have also noticed that Planning Poker works very fast indeed for people familiar with the project. In particular, I have in mind new team members, whose first estimation will certainly be strongly inflated. After a few sessions of Planning Poker, each member of the team, even novices to programming, becomes more knowledgeable about the project than during all regular project meetings.

I have now shown you all the most important factors on this topic, and we are approaching the end of this short series on the estimation of Agile projects by a team. In the last article, I will return for a moment to our Planning Poker games and will present a summary of the series. In addition, I would like to mention that I am preparing a series of training courses in Silesia on these very issues. I would like you all to be aware of them and I thank you for reading all the articles that have so far appeared. I wish you all good luck in future estimation projects.