We have previously traced all types of estimates, and we introduced Planning Poker. Today, we finish that and do a summary of the entire series. As I have said, estimates are really important, almost as important as the management of human resources in Agile, and Planning Poker is so cool, because it combines most of the good old estimating practice. So let’s begin our fun.

Why does Planning Poker work? What makes it effective?

The answer to this question is very simple. Planning Poker combines all the best practices of most estimation techniques. The first of these is the lack of bias. Note that, in the case of Planning Poker, all participants show their cards at the same time. Thus no one is affected by the opinions of people considered to be experts in the field. This ensures that they do not duplicate any erroneous assumptions of one of the project participants. In Planning Poker, no one’s vote is more or less important, and they are all treated the same.

Planning Poker also has another important feature, namely an analogy for the data User Stories. User Stories are estimated relative to each other. This helps determine the size of the User Stories. It looks something like this: in the minds of the participants there is the thought, “This User Story is greater than 5 and less than 13. Let it be 8.”

Another feature is the speed of estimation. Believe me, 40 stories can be estimated in 2-3 hours. See how it saves time during the estimation? Don’t you think that’s pretty cool?

Another thing we need to bear in mind is that we can always take advantage of expert opinion. In fact, estimating the project is done by people who perform programming tasks assigned to them and best understand the complexity of each programming problem that arises. Thanks to this expertise, estimation can go smoothly and quickly.

Remember also that the team discussion improves the precision with which team memers understand the programming problem. Note that, for any decision, I should be able to support the arguments in its favor. To be able to support these arguments, we need to fully understand a particular story. So this is a fundamental plus.

With Planning Poker are also able to use the knowledge of the whole team. This is mainly due to discussing the stories. All members of the development team know the real scope of work in a given software project, and because of that, they are able to catch errors or remedy a partial or total lack in the approach. This allows them to suggest pretty good alternatives. Then comes the question, “What happens when?”

An additional advantage of Planning Poker is that it is fun. It is a great escape from other types of traditional, formal meetings. As a result, Planning Poker satisfies all the assumptions of each estimation session, since it really serves the purpose of the estimation meeting: to understand the scope of work involved in the project.

Okay, we already know the basic game; now, how to get the cards for Planning Poker?

Planning Poker cards are not usually a problem. There are plenty of options. The easiest way by is to cut them out of paper. Another option is to purchase a deck of playing cards for any card game and change their values. If you have an Android smartphone, you can also easily download the appropriate application and display the values on the phone’s screen.

Another possibility is to use a template for Planning Poker cards; a lot of them are available on the network. Just print them on rigid paper and cut them out. But if you really want quality of cards and a fabulous look, you can always order a deck of cards from one of the companies that makes them. There are a lot of professionally prepared decks available for Planning Poker.

How to use Planning Poker distributed teams?

The answer to this question is also relatively simple. As we all know, more and more people are now working remotely. We are talking here about the company’s future. Increasingly, it happens that the whole team is not in one location. This may make Planning Poker a little difficult, but it is never really impossible.

What should we do if such a situation arises? The right tools are available. Using teleconferencing equipment will allow the participants to see one another and to hear one another’s voices and it also allows users to see the selected cards. If, however, we have a limited budget, we can use the Planning Poker online version that can be found at http://planningpoker.com. Using this app is completely free.

Of course, the best solution is always to share at least some initial estimate for User Stories and then contue estimation through separate groups when the project is already in development. To achieve this, we need to create a groupthat has all the necessary skills to estimate projects. We need them both for the developer and for the tester or analyst. Of course, if you do not have access to the full team, you have to estimate only the values that are known by members of the team.

For example, a team devoid of graphics experts should never touch those features that require changes to graphic design. Of course, estimating User Stories in this way will be incomplete, so the next step must be to capture information that relates to project from the other experts so we can determine what we need to achieve during the course of the project.

Does this really work as described?

My own experience has shown me that this approach to estimation assisted by Planning Poker is perfectly suited to almost all projects. Perhaps you want an example? A little while ago I participated in a project that did not end on time, despite the use of estimation. What was the reason?

As previously mentioned, each new person in the project is a huge burden. For the project I am writing about, it took six months to a year to integrate a new person. At the beginning, when a new person came in, both developers and testers focused not only on their own work but also had to do a little extra, because the client was paying for 11 people and the one who was new to the project did not do anything. In addition, the experienced developers and testers had to train the new person.

A few weeks later, I again visited the same development team after they had been introduced to Planning Poker. It turned out that, through user stories and drawing cards, the process of integrating new people into the project had been drastically shortened. Practically from the beginning, even new employees were able to work on the project as soon as they came into it because they already knew what was going on in each project. And this is an advantage for Planning Poker projects.

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available

In addition, when it comes to Planning Poker, you have to have one thing in mind: Planning Poker works perfectly with all the estimation visuals. Why is this happening? Because Planning Poker allows the development team to fully identify all of the things that need to happen in developing the project. What else did I notice? That Planning Poker pulls the people together who are involved in the project.

The meaning of Planning Poker

Note that today I wrote mostly about interdisciplinary teams. Do those estimates have any meaning for other types of projects? A development team often has to write tests for the emerging software. Then Planning Poker will produce really different results. One QA group says it will take a whole team time of 10 hours, while other members suggest that this will require only an hour of time. In this case, does the sense of fun disappear from the estimation task? Is it not easier for the project manager to ask that it be estimated?

The answer to both these questions is NO. Why? Well, if we use the estimation group, the person who will perform the task will have to explain to the whole group how long it will last and why,so that all the teammates will be able to perfectly understand all the work to be done in the project. We can reduce the bottleneck effect through mutual learning. This improves the learning process, enhances team collaboration, and facilitates the acquisition of knowledge.

Team members become a lot better, wiser, and certainly more in tune with the knowledge of their colleagues. What does this give the contractor? The contractor, because the team has explained all the future work that needs to be done, can much better understand it. This really increases the level of communication within the team. So, thanks to all those linkages within the team, in the end we get much better estimates for projects. These estimates are much closer to the real thing, because usually they are backed by a team discussion, mutual translation of the various tasks, and solid arguments.

I have finished describing the process of Planning Poker, which I hope is now clear for all of you.

Summary

This is the end of the series of articles devoted to the estimation and evaluation of projects. Now it’s time to take stock of the entire series and what you have learned from it. I hope you liked these articles. I can return to the subject some time in the future, but this is not the time or place. I will quickly summarize the series here.

In the first part, I showed how to do a simple estimation of a project. In addition, you learned how to share the assessment of projects. The first part was, therefore, only the introduction to the topic of estimating projects. In addition, we learned about the concept of temporary barriers in projects. We introduced a little math. The second part reviewed the first part, but it also summarized all the theoretical skills and introduced the rules for ascending and descending estimation. A few examples were also presented. In the last two parts, you learned the rules of Planning Poker. Now you know that it’s not playing poker. In addition to the examples, you learned how to estimate projects and how fast to introduce new people to the project. Maybe Planning Poker’s many advantages outweigh its small disadvantages?