By Jason Fisher / 13 Oct 2020 / Topics: Agile Application development DevOps
Due to the level of uncertainty and complexity in software development, planning poker has been widely adopted in the Agile community — particularly on Scrum teams, although it’s not a formal part of Scrum.
The two most common variations are T-shirt sizing and card sizing. Both methods use relative weighting to communicate effort, with the former technique relying on the common American T-shirt sizes: Small (S), Medium (M), Large (L), Extra-Large (XL) and so forth. Card sizing, on the other hand, utilizes a specialized deck of playing cards which are primarily distinguished by closely following a Fibonacci sequence.
So why do we use cards? Why Fibonacci? Why gamify our planning in the first place?
In this post, I’ll introduce the basics of poker planning cards and share how they can be used with Agile development teams to make work more predictable over time. We’ll explore each of these in more detail below, but the general rules and processes of card sizing are as follows:
Before we dive any further into the use of the cards and the nature of estimation in Agile, we must first define our terms.
When a “size” is attached to a story, it’s just that: a relative metric. It’s not hours, it’s not days, it’s certainly not weeks. A size is a representation of several factors, not only effort, but also time, risk, dependencies and any other unknowns.
For example, if the size of the login form is deemed a “3,” how does that compare to the sales report? Is it less risk and effort or is it more? How much less or more? Maybe it’s a “2” because we haven’t written the authenticator yet for the login, but we know exactly what query will drive the sales report. Or maybe it’s a “13” because the login is simple and straightforward, but the sales report is going to be a monster with columns which can be hidden and shown — and we don’t even know if the data is all available yet.
It’s important to approach the planning process with this relativity in mind.
Clearly, helping ourselves and each other come to an agreement on the level of effort that will be required before we start doing work is extremely valuable in and of itself. So, what’s up with the cards? The single biggest reason is simply to derail or sidestep groupthink.
Employing the use of cards allows every person on the team a few moments to think through the details of the story — what’s known and what’s unknown — as well as what the risks might be before picking his or her own metric. Keeping this number to ourselves before the reveal prevents conscious or unconscious bias from affecting the results (i.e. “I thought this was a “2,” but the senior dev over there has an “8,” so I better change my number.”).
The best remedy for groupthink is creating free space within which conversation must happen. Just because the junior dev dropped a “13” doesn’t mean she was wrong. It could very well be that she worked on the last iteration of this feature. The senior dev only thinks the new story is a “5” because he doesn’t know what she knows. If the junior teammate quietly accepts the “5,” then the true level of effort becomes obscured and deliveries will be incomplete, late and/or invalid as a result.
The Fibonacci sequence is a set of numbers that mathematically describe the Golden Ratio which occurs throughout so much of the natural world. It’s derived by starting with two “1”s, then generating the next number by adding the previous two together. So 1+1=2, 1+2=3, 2+3=5, 3+5=8 and so on. As we can see, the numbers quickly develop larger and larger gaps — and this is where the magic happens with card sizing.
We don’t use an infinite scale of course because we are, after all, trying to reach consensus. Instead, some rough standards have arisen over the past few years.
A standard Fibonacci deck:
0, ½, 1, 2, 3, 5, 8, 13, 21, 34, 100, “?”
No, the “?” is not a typo. Often a teammate simply doesn’t have the information to help provide an estimate on a piece of work. That’s okay.
Our current deck:
½, 1, 2, 3, 5, 8, 13, “?”
The development team for which I’m currently the Scrum Master has been together for more than three years and is quite mature in their practice of Scrum. We don’t use the widest range of cards possible in the deck, but the net effect is still similar. Our team used to use “0” occasionally, but after realizing that QA and integration tests always require some amount of reconfiguration, “½” is now the lowest we’ll go.
So why don’t we simply use standard numerical increments? It’s a valid question and there’s a good reason for it. Most developers can identify quite quickly when a simple story is a “1” or a “2” or maybe a “3”, and these numbers tend to have fairly broad agreement. The work in this range is similar and the risks are probably minimal.
But the more unknowns there are, the more external dependencies on other teams, or the more sheer effort involved, the less likely it is that a team will have immediate agreement. Do you really know the difference between a “4” and “3?” Or a “4” and a “5?” The further away from certain you are, the less you know, and that “cone of uncertainty” expands.
We use the Fibonacci sequence to better represent this phenomenon. “I think that might take me about a week to finish,” is a much less certain estimate than, “I’ll have that to you 10 minutes after we get off this phone call.”
As I mentioned earlier, as humans we all have the ability and tendency to rapidly change opinions — or at least the expression of our opinions — in social groups. Development teams are no exception and the effect can be exacerbated by perceived differences in rank or title.
The gamification of estimation takes this largely out of the equation, so long as the team demonstrates courage and encourages everyone to speak up and participate. The conversations which result for widely differing sizes are usually where the most important refinement of requirements happens.
The following scenario isn’t uncommon during weekly meetings with my team:
Frontend developer: “13”
UI designer: “3”
QA tester: “8”
Frontend developer: “Wait, what? This is a huge page with all these icons and drop-downs on it.”
UI designer: “Yes, but I’ve checked the story and the mockup carefully and we have every one of these design elements already in the application. It will be easy to drop them all in.”
Frontend developer: “Oh, okay, that definitely makes it easier. QA, why were you thinking it should be an ‘8?’”
QA tester: “Well, really I just thought this was going to be a huge amount of work for the UI folks, but if that’s the easy part, I think the testing might come down to a ‘5.’ I think I can reuse one of the other big test scripts to cover this new screen.”
Frontend developer: “I’m starting to think it might only be a ‘5’ as well. Hey, Product Owner and business analyst, are you sure there’s nothing missing on the mockup? No surprises or gotchas or missing dependencies?”
Business analyst: “Nope, we have all this data in other parts of the app already, so we don’t have to wait on anything external here, and the mockup does cover everything the users want.”
Backend developer: “I was already at a ‘5,’ but I was a little worried it should maybe be an ‘8’ for QA and UI. But if they’re happy, I think we can call it a ‘5.’”
This type of conversation is vital, and at the end of it, everyone’s understanding of the work to be done is vastly improved. Everyone is now also in agreement about what the level of effort means when it comes time to plan the next Sprint.
Product Owners (POs) have a tendency to want to inject themselves into the work. Which is precisely why one of the main focal points of Scrum is to encourage the PO to leave the dev team alone during the Sprint so that they can get the work done.
For the PO to trust the team, however, there must be some mutual understanding of what’s expected in the next two weeks. During Sprint planning, the dev team takes mutual responsibility for helping each other accomplish everything they’ve agreed to tackle during the Sprint. In order for each individual to agree to the effort and risk of a story, however, the team must reach a mutual decision.
Over time, as a team matures, the accuracy of their estimates and the amount of work they can plan for in a given timeframe will get better and better. When members of a dev team trust each other, their ability to complete everything they’ve agreed to improves and this leads to greater trust from the PO. A PO who trusts the team starts to prioritize and define work in ways that make it easier for the dev team to complete. It’s a win-win-win that ultimately provides users with more valuable and less buggy software.
Reducing that specific complexity is the reason we use Agile — and planning poker cards can be an integral part of that process, both at the outset and ongoing.
Scrum Master & Business Analyst, Insight Digital Innovation
Jason has been in the software business for more than 20 years, from database design and full stack development to working as a team lead, a business analyst and an IT director. As a Scrum Master, he exercises his passion for building up and working with great teams to solve business problems with technology.
