Planning poker: notes on the first impression of the developer
I, like some other programmers, are not a big fan of rallies. At times, all these sprint refinement, sprint review, retrospective sessions are annoying.
The teams where I worked never had planning poker rallies, but recently I participated in such a true alien team. I am familiar with all of this team (with the exception of the new architect), but I never personally saw the full composition of the team in action, so I watched with interest their approaches to teamwork. In addition to being quite fun, I was able to learn something new and useful for myself. In this article I want to share my impressions of participating in a planning poker rally.
I didn’t even know that some of our teams practice Planning Poker. The fact is that in our projects, team members from two offices: the Dutch front office and the Russian back office. Using Planning Poker for sprint content in our environment is simply unrealistic. For such sessions, you need to assemble a whole team in one place and it is difficult to organize it on a regular basis. Therefore, the team conducts such sessions only for the backlog of tasks for several years, some of which seem crazy and unrealistic for implementation, well, tasks that require more time than managers are ready to give at the current time. For these purposes, Planning poker is just perfect, in my opinion. If you have experience using Planning poker for distributed teams without gathering the entire team in one room, it will be interesting to read
The team under consideration is developing both the software part of the software for medical equipment, and the software for the corresponding hardware part - firmware. Therefore, such sessions will be informative for most members of the team, since someone works with only one part and does not know the details and difficulties encountered in other parts of the software. During the rally, many discussions between the people with the lowest and highest ratings began: “It's easy to do this.” Yes, sometimes experienced programmers make a low rating, and in some cases a low rating is given by inexperience, because this is “ sarcasm” of firmware for a regular piece of hardware, and why bother with it for so long .
Most tasks contained at least 3 parts, based on the specifics of the project: software, firmware, and actually the tests. For complex systems from the group of constituent elements, an assessment was made for one element.
When assessing the complexity of a task, additional questions from beginners can be very helpful. As you understand, they invited me for this sacred mission. The fact is that an ignorant person can ask questions that will also be useful in accounting for the ratings of team members. I myself noticed a couple of times how, after my question, some people immediately started looking for another card, although I had already decided on the rating.
Such sessions require a lot of time. The discussion time for each issue depends on the completeness of the requirements and understanding of the solution to the problem. The time for discussion of the issue can vary from 5 to 30 minutes. So I took part to discuss the last third of the backlog part of the tasks. It took an hour and a half.
So to summarize.
Everything is good in moderation. Planning poker sessions are useful activities, but they take a lot of time, so I don’t think it is wise to have them very often, unless you have free time. By gathering such meetings from time to time, you will maintain general awareness of the team in different parts of the project, which will help improve the process of solving problems. And for someone it may be a good opportunity to get acquainted with other parts of the project in case you get bored with working with your own.
The teams where I worked never had planning poker rallies, but recently I participated in such a true alien team. I am familiar with all of this team (with the exception of the new architect), but I never personally saw the full composition of the team in action, so I watched with interest their approaches to teamwork. In addition to being quite fun, I was able to learn something new and useful for myself. In this article I want to share my impressions of participating in a planning poker rally.
Frequency of Planning Poker Meetings
I didn’t even know that some of our teams practice Planning Poker. The fact is that in our projects, team members from two offices: the Dutch front office and the Russian back office. Using Planning Poker for sprint content in our environment is simply unrealistic. For such sessions, you need to assemble a whole team in one place and it is difficult to organize it on a regular basis. Therefore, the team conducts such sessions only for the backlog of tasks for several years, some of which seem crazy and unrealistic for implementation, well, tasks that require more time than managers are ready to give at the current time. For these purposes, Planning poker is just perfect, in my opinion. If you have experience using Planning poker for distributed teams without gathering the entire team in one room, it will be interesting to read
For which teams would it be beneficial to use Planning Poker
The team under consideration is developing both the software part of the software for medical equipment, and the software for the corresponding hardware part - firmware. Therefore, such sessions will be informative for most members of the team, since someone works with only one part and does not know the details and difficulties encountered in other parts of the software. During the rally, many discussions between the people with the lowest and highest ratings began: “It's easy to do this.” Yes, sometimes experienced programmers make a low rating, and in some cases a low rating is given by inexperience, because this is “ sarcasm” of firmware for a regular piece of hardware, and why bother with it for so long .
Big tasks are broken down and evaluated individually
Most tasks contained at least 3 parts, based on the specifics of the project: software, firmware, and actually the tests. For complex systems from the group of constituent elements, an assessment was made for one element.
You can invite someone from another project to participate
When assessing the complexity of a task, additional questions from beginners can be very helpful. As you understand, they invited me for this sacred mission. The fact is that an ignorant person can ask questions that will also be useful in accounting for the ratings of team members. I myself noticed a couple of times how, after my question, some people immediately started looking for another card, although I had already decided on the rating.
Required time for planning poker sessions
Such sessions require a lot of time. The discussion time for each issue depends on the completeness of the requirements and understanding of the solution to the problem. The time for discussion of the issue can vary from 5 to 30 minutes. So I took part to discuss the last third of the backlog part of the tasks. It took an hour and a half.
So to summarize.
Everything is good in moderation. Planning poker sessions are useful activities, but they take a lot of time, so I don’t think it is wise to have them very often, unless you have free time. By gathering such meetings from time to time, you will maintain general awareness of the team in different parts of the project, which will help improve the process of solving problems. And for someone it may be a good opportunity to get acquainted with other parts of the project in case you get bored with working with your own.