8 Ways Planning Poker Helps Agile Software Development Teams
What planning poker is, how it works, pitfalls to avoid, and why we recommend this approach to estimating work hours for programming tasks.
The first time our team here at Appresso Corporation approached an entire project using the values and principles of agile software development was summer 2016. We were kicking off working on the next version of our enterprise application integration middleware, DataSpider Servista, using the Scrum framework.
Until this point, we had tended to take a conventional approach to estimating work hours. We’d usually have the project manager (PM) review the tasks to be completed and then give their best guess.
However, for the latest version of our product, version 4.1, all user story estimates were made using Planning Poker, a method that has gained popularity within the agile community. This brought a lot of changes to the way we did things and below I’d like to share the benefits we experienced.
First, for those unfamiliar with planning poker, a brief definition is in order.
What is Planning Poker?
When we first started estimating working hours for programming tasks using planning poker, we found the technique confusing at times, but eventually became accustomed to it and got into a consistent flow.
Generally, we would have all project team members, including the PM and quality assurance (QA) manager, participate in each session. Those who wanted to add a task would tentatively assign points to the card of a user story and, after discussion among all members, the designated points would be fixed. The process was then repeated until all task cards had been assigned a point.
The card points use the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc.). This discourages becoming overly focused on the numerical value assigned and wasting time debating. It’s important to note that the points do not translate directly into work hours, but rather, represent the scale of the task relative to others. This took a while for us to get used to, but after sufficient iterations, we settled into it.
The Process
Roughly speaking, our planning poker sessions would look something like this:
- PM: “In this user story, ABC does DEF. This is the type of function I have in mind. However, I’m not sure about the details of GHI, so we need to consider it.”
- Members: “Is the specification policy decided for XX?”
- PM: [Describes various user stories.]
- PM: “Does everyone get it?”
- Members: “Ye — — s.”
- PM: “Ok, three… two… one!”
[Everyone submits cards]
- PM: “Well, ‘5’ is the most common, though some have chosen ‘3’ and ‘8.’ Member A, why did you choose ‘8’?”
- Member A: “Since this will require modifying the GUI, including the visual specifications for that part, I think it’s a larger task.”
- Member B: “Oh, I see. Well, in that case, I’ll guess I’ll change mine to an ‘8’.”
- Member C: “Mine is a ‘3,’ and I’m sticking with it because I think we can reuse some existing parts developed for other things so that it won’t be such a big job.”
- Member D: “Based on my experience and looking at it from a QA perspective, testing this type of component can be quite involved, so I think it’s better to look at it as a larger job and give it a higher rating.”
- Member E: “Makes sense. I guess I’ll raise my rating, then…”
[Various discussions ensue…]
- PM: “Ok, team, how about we assign this one an ‘8’?”
- Members: “OK!”
[Points are described…]
- PM: “Alright, now, the next story is ….”
And, the process is repeated until all stories have been assigned points.
Usually, during the course of reaching a consensus on awarding points, we’d have our members put out their cards and let them revise their ratings as the discussion progresses. It was our PM’s role to guide the exercise, facilitate discussion, and make a final decision based on group consensus.
However, we found that doing it this thoroughly took too much time. So, nowadays, we try to reduce the amount of discussion, and, if there are no strong objections, assign points to a task ASAP. We’re still experimenting with our approach and calibrating as we gain perspective and experience.
The Eight Benefits of Planning Poker
To be honest, I’m quite a skeptical person, dislike following instructions exactly, and tend to start out with any task believing I’ll somehow figure things out by myself. My nature is a bit willful and rebellious at times. So, my initial thoughts on the idea of using planning poker were along the lines of, “So, we all decide together? Well, that might be ideal, but is it really going to be worthwhile doing it that way? Is this just some kind of ‘love, peace, and unity’ nonsense?”
However, I was mistaken! I sincerely apologize to the Agile community for my disrespectful thoughts! I now understand that planning poker is a practical and effective method that is highly beneficial to the development process and its resulting products.
Below, I’ll describe the eight benefits we experienced.
1. Gamifying the Estimation Process Makes It Fun
While the conventional approach to planning has its merits, it can be lonely and arduous work for the developers. In contrast, with planning poker, the improved communications that result from a good-humored discussion of each story among the team are fun. I’d say this is the benefit that stands out to me the most.
Also, by having everyone in the team gather in the same place if anything is unclear, it can usually be resolved quickly. As we progress, we have unexpected insights such as, “Oh, that person assigned this number of points,” “Ah, everybody agrees,” “Hmmm, I hadn’t considered that,” which makes it a fun game.
I must confess, I look forward to planning poker sessions so much that I sometimes can’t sleep the night before. We feel free to express ourselves, and it’s never dull.
2. Having Everyone Come Together Feels Great
Every PM is familiar with holding traditional meetings to announce and explain a project’s specifications to the various stakeholders. We prepare, present our demonstration, and then ask, “Does anyone have any questions?” And, then, silence… It’s a familiar scene.
If I were in the position of receiving the explanation and didn’t understand something, since I wasn’t going to be the one doing the implementation, and nobody familiar with the details was saying anything about it, I’d feel reluctant to say anything. I’d just give up and hope the meeting would be over quickly so I could go out to lunch. Sound familiar?
I think the most valuable feature of planning poker is that all members must assign a point score to each task and explain their reasoning. This means that a decision isn’t made until there is sufficient information.
Once we actually tried planning poker, it led to interactions like this:
- PM: “This story is _____. Does anyone have questions?”
- Members: “Nope. We’re ok.”
- PM: “Alright then, take out your cards.”
- Members: “Ah, wait a minute. Is the specification decided?”
- Members: “Well, how detailed do you want to get?”
Exchanges like this made the value of planning poker clear. We had shifted from gatherings where the PM would give a one-way explanation of the specification to an interactive process where each member had to assign an estimated rating to each story. This stimulated deeper discussion, and we reached insights that we would have with the old way.
Thanks to introducing planning poker, our mindset changed, and there was a great feeling of us all coming together and cooperating as a team.
3. Deeper Sharing Occurs Naturally
At a social gathering, you can’t just walk up to someone and say, “Hey! Let’s have an in-depth discussion!” because they won’t feel inclined to reveal their thoughts. However, if there is already a general conversation underway, it’s possible to find a tipping point to dive deeper.
Having to gather and put forward our point estimates formally is like this “general conversation” situation. By focusing on topics in a specific direction, deeper sharing would occur spontaneously, in particular when everyone was discussing after each person assigned points.
We’d hear comments like these:
- “We’ve implemented a screen like that with similar specifications in the past. It was a heck of a job so it would be better to assign it more points.”
- “There is a similar implementation in module X, so it should be easier to implement if we make it standard and reuse it. So, I don’t think we need to assign so many points to this story.”
- “The modification itself seems easy, but since it’s a larger feature, we need to check how it’s going to work carefully. My guess is it’s probably going to require more testing than we expect.”
- “This part was implemented by person-A, so before we assign points to it, we’d better get them to explain properly first.”
And, so on. We’ve found that having a variety of perspectives like helps us get a more realistic view of each task’s scope and scale. This, in turn, benefits the project as a whole.
4. Everyone Is Informed Directly
When just one person is in charge of estimation, specification formulation, and implementation, it’s common to hear team members say, “That person is in charge, so I have no idea.” I guess many of you have experienced this.
Another issue is if that key person takes a day off, the project is delayed. Other times, it may not be until the project is completed that an issue is discovered with the specification the team had been basing its work on.
Among there various mechanisms to prevent this within the agile approach to development, planning poker is particularly useful. One crucial point is that during the planning poker stage, nobody has yet been assigned to actually perform the implementation and testing. Everybody is just focused on obtaining enough information to make a reasonable estimate and allocate points appropriately. At the end of the exercise, everyone should have sufficient information to perform the implementation and testing by themselves if they had to.
Getting everyone together like this is far more efficient than trying to document everything on a wiki for the team after the fact. Of course, documentation is essential and should be done properly, but nothing beats this kind of direct information sharing and dialogue.
Speaking of documenting things, our team has debated the merits of keeping meeting minutes for our planning poker sessions. However, so far, since everyone participates, if one person forgets something, then they can just ask another team member about it. And, if nobody remembers, then it probably wasn’t that important in the first place!
5. It’s Easy to Confirm if a Story Was Correct
During planning poker, we sometimes come across ones where we conclude that “We cannot assign points yet.” In most cases, it’s because the story does not follow the INVEST mnemonic, which stands for:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
It can be difficult to check whether a story is strictly consistent with this principle. However, you can do this check naturally within the flow of conversation in planning poker. For example, you’ll know that a story isn’t quite right if someone says something like, “This story is confusing. Perhaps it’s actually a combination of stories?”
Here are some examples of statements you might hear that will alert you to when a story doesn’t meet the INVEST standard.
- If it’s not independent: “This story is confusing. Perhaps it’s actually a combination of stories?”
- If it’s not negotiable: “The details of the functionality for this story have been decided, but perhaps there’s an easier way to implement it. Shall we reconsider it?”
- If it’s not valuable: “Would this really be of value to our users? Shouldn’t the PM review it one more time?”
- If it’s not estimable: “This story is too abstract and difficult to estimate. Wouldn’t it be better to first have a clearer specification?”
- If it’s not small: “This story is too large for everyone to assign points to. Shall we break it up into two or more smaller stories?”
- If it’s not testable: “This story would be difficult to test. Wouldn’t it be better to have a story like ____?” In such a case, we just suspend making an estimate.
If a story doesn’t pass through the INVEST mnemonic, we will take one of the following actions:
- Ask the product owner,
- Hold a separate meeting to review the specification, or,
- Split the story into two or more smaller stories and add them to the queue for estimation.
6. Estimates are Made with Code in Mind
We always make sure our QA staff joins the meeting. Thanks to them, we don’t get overly focused on development and ensure the perspective of maintaining high quality is included. However, they often contest estimates that were low because “It’ll just be a simple modification.” It’s important to include the perspectives of both development and testing members when seeking a consensus on how many points are to be assigned to a given story.
7. Educational for New Members
We make sure to have all members participate in planning poker, even if some lack knowledge of the project. New members struggle to come up with a number for points, but that’s only natural.
However, if they add a comment along with their guestimate of points such as, “I didn’t understand this part…,” then naturally, one of the more knowledgeable members can explain to them, “Oh, that part is ____.”
Of course, while people are engrossed in working on code it’s hard to just walk up to them and ask a question. But, when the whole team comes together for the express purpose of assigning points to stories in this way, it becomes an effective way of sharing information and knowledge.
8. More Understanding Among Team Members
I’ve covered various perspectives so far, but the most important thing is the communication and relationships between team members. However, you can’t just tell people, “Ok, let’s understand each other.” That doesn’t work for humans. We need to facilitate interactions that lead to honest communication and provide fertile ground for relationships to develop organically.
Of course, doing something like having drinks after work can be helpful. However, it can’t replace a focused activity where we can learn what each person is working on and what is necessary for the project as a whole.
Since planning poker requires everyone to make judgments and remarks, each member needs to understand what the other members know and see their viewpoints and values. This leads to increased synergy and mutual understanding within the team.
Closing Remarks
At first glance, the exercise of planning poker seemed like a lot of hassle to go through just to create development time estimates. However, after trying it, we found it to be most definitely worthwhile.
Planning poker is more than just another way to generate estimates. We found it improved communication and relationships within our team and code quality. It was also a great learning experience for newer members. We’re continuing to use planning poker and refine our use of this method.
If you found this article interesting, please try planning poker. I have no doubt it will change the way you think of creating development time estimates.
About the Author
Takumi Toki works in the team that builds DataSpider Servista, enterprise middleware which empowers IT teams to integrate a broad range of data sources without the need for coding.
