Estimation Blackjack and Other Games: a Comedic Compendium

Ruby on Ales 2015

Amy Unger

Estimation Blackjack and Other Games: a Comedic Compendium

by Amy Unger

The video titled "Estimation Blackjack and Other Games: a Comedic Compendium" featuring Amy Unger discusses the complexities and challenges of estimating work in software development. Unger draws from her extensive experience as a software engineer and consultant, highlighting the significance of accurate estimation for project success and effective communication within teams.

Key points discussed include:

- Importance of Estimation: Estimation is crucial for informing stakeholders about project timelines, which is essential for making decisions regarding resources, marketing campaigns, and business strategies. Accurate estimates can influence the success of a business and help teams avoid oversights.

- Challenges of Estimating: Despite the necessity of estimation, it is often fraught with inaccuracies. Estimation aims to move from uncertainty to reliability but can sometimes lead to pseudo-deadlines that misinform stakeholders.

- Human Element in Estimation: Estimating involves subjective human judgment and historical performance rather than precise prediction. Engaging the entire team in estimation discussions helps improve accuracy.

- Bad Estimating Games: Unger humorously outlines several "bad estimating games" that represent ineffective practices:
- Solitaire: Estimating in isolation without team input.
- Charades: Estimating based on unclear or incomplete information.
- Dummy Bridge: Making estimates without all relevant team members present.
- Slot Machines: Revealing estimates sequentially rather than simultaneously, which can influence results unduly.
- Estimation Blackjack: Pressuring team members to scale down estimates for fear of higher ones being unfavorable.
- Resistance: Group dynamics where more assertive voices drown out others, leading to less accurate estimates.

- Improving Estimation Practices: Unger suggests embracing uncertainty, using comparative estimates, and establishing an environment where open discussions about the estimation process are welcomed. Teams should prioritize learning from estimation inaccuracies to refine their processes without assigning blame. She emphasizes that meeting time for estimation is not wasted and that clear and honest communications about uncertainties can enhance teamwork and decision-making.

In conclusion, Unger’s talk encourages teams to approach estimation collaboratively, identify and mitigate ineffective practices, and use humor and new vocabulary to normalize discussions around improving estimation dynamics. Her insights aim to empower teams to make more informed decisions that benefit their projects and organizations.

00:00:22.310 Hello everyone!

00:00:29.230 So I want you all to meet my friend Amy. Amy is here to talk about something particularly interesting that will be up on the screen in just one moment. A little bit about Amy: she is actually descended from computers. I don't know anyone else who can say that. Her grandmother's job title was 'computer' in an MIT lab, and I want that job title desperately. I'm going to talk to my boss after this about changing my job title. You heard it, Tim—I'm the New Relic computer. That's me. Thank you for the introduction, Amy.

00:00:52.600 Amy is also a 'healbot' fond of role-playing games. So if you want to talk to her about some nerdy things in that realm, feel free to do so. I love a good healer, and we are about to hear something very interesting from her. Please give a round of applause for Amy.

00:01:17.910 Well, thank you, everyone! My name is Amy Unger, and I have done a lot of software estimation as an engineer. When I entered the field, I did not expect estimation to be part of my job, nor did I expect it to be a key metric of whether the work I did was considered a success.

00:01:26.289 As a consultant and staff member, I've worked with teams that produced accurate estimates and been on teams that produced estimates that were way off base. So today, I'm going to talk a little bit about some estimating games that we should all avoid playing.

00:01:38.920 Luckily, there are no names in this presentation, so I won't be calling anyone out. Along the way, I'm going to give a short introduction about why estimating helps our projects succeed. I'll talk about how we estimate and our existing vocabulary for discussing our process. Then I'll introduce a compendium of bad estimation games and wrap up with some thoughts on more accurate estimating.

00:01:58.450 So why do we estimate when it's so tough to get right? At best, estimating seems like an organization's process for being increasingly less wrong about how long work will take. We want our communication about the future to improve, ideally going from something uncertain to something more reliable.

00:02:07.630 These numbers would represent the comparative work needed to complete a chunk of work. For example, a two-point story would require twice as much effort as a one-point story. Ultimately, we want our estimates to be accurate, but the reality is that they can be so wrong sometimes. So what's the point? As programmers, we estimate to give enough information into the hands of the people we work with so that their business or organization can run successfully.

00:02:35.050 Put another way, we intend every piece of software we work on to be beneficial to our employer, our clients, and ultimately our users. Our success relies on our coworkers knowing enough to make those time-sensitive decisions that make our product work. The features we deliver that hold the most value to our users depend on how long they will take to implement.

00:03:04.030 For instance, a calendaring feature might be a great investment if it only takes a week to develop, but a really bad one if it takes a whole year. Additionally, decisions like when to hire a new developer or when to launch a marketing campaign cannot be made without knowledge of when we might finish our work. Just like programming takes time, marketing and promotion campaigns also have long lead times. That's why we often need to deliver something as valuable as this, which can turn into something problematic.

00:04:14.079 It's just one character difference here, but you wonder why it's such a big deal, right? Even if our estimates do turn into pseudo-deadlines, that's no reason to ignore the power of estimation. Without that estimate, those who shepherd our products to the users wouldn't be able to make decisions now that impact not only today but also into the future. Sometimes, this is the difference between the success and failure of an entire business.

00:05:01.040 In addition to providing a timeline, estimating improves communication about the work we do, allowing everybody to make better decisions. For example, imagine we're looking at the most beautifully written, most spectacular feature in all creation, with comps so clear they could make a programmer cry. From the feature requester's point of view, they might envision a lovely pink house with nice little red flowers, assuming it will look like all the others on the block. But it's only when we start estimating that it becomes clear that we're actually building something more akin to the Starship Enterprise.

00:05:55.560 The stakeholders' pink house with red flowers is going to fly because, of course, they're also planning to raise a family. But in the same way, if we're talking about a small story to restructure some payment forms for usability, we could really be discussing a massive feature requiring significant backend restructuring. Estimates serve as a signal for the scope of the required work, clearly indicating that if you want to build your whimsical pink house, then what we're building for you is the Starship Enterprise.

00:06:42.400 I've briefly discussed how valuable estimating is to the products we build, so let's talk about how we estimate and our vocabulary for speaking about estimating. The estimation process is different in every workplace I've encountered, and I know there are many different processes represented in this room today. All of my work has been done primarily in small agile workplaces, so this part reflects that frame of reference. Please pardon me if this doesn't mirror your experience.

00:07:09.449 On the teams I've worked on, we generally try to first discuss sizes and effort. It's much easier to have a constructive conversation about the amount of work to be done than to have a conversation about the precise time it will take. A corollary to this is that we want to use comparative estimates and not absolutes. For example, we might say that this story is a five-pointer because it's larger than the three-pointer we're working on right now, but it's also about the same size as the five-pointer someone else just completed.

00:08:06.360 As humans, we are far better at saying this thing looks like that other thing than at saying this thing is one hundred percent absolutely this size. Whether we have to determine whether something is absolutely small or absolutely massive presents its own challenges. Next, we want to emphasize historical performance rather than guess timelines.

00:08:16.500 We aim to be able to state that historically, this team has completed 45 points of work in two weeks, rather than say this chunk of work will be completed by the end of March. These two statements can yield the same consequences, yet the focus on historical data provides more reliability than mere guessing. Finally, we want our process to include time for discussing how to improve our estimates rather than laying blame for missed deadlines.

00:09:11.370 If a two-point story ends up taking as long as a thirteen-point story consistently, we should view this as an opportunity to learn about how to refine our estimates, rather than as a reason to demand everyone work eighty-hour weeks. When we talk about implementing these goals in reality, many of our processes derive from a game called Planning Poker.

00:09:40.000 Planning Poker may resonate as someone’s ideal way of estimating with rigid rules. A moderator runs the meeting, introducing each story, allowing everyone to ask clarifying questions before participants create their individual estimates. All of these estimates are revealed simultaneously, allowing for discussion where team members can ask why someone estimated high or low, followed by another round of estimation until reaching a semblance of consensus.

00:10:47.020 However, because this process tends to be fairly rigid, our actual practices often deviate from this ideal, despite looking similar. We've either added numerous house rules or stripped the process down considerably. Still, this game is a critical reference point for discussing what good estimating should look like.

00:11:54.790 But without the structured rules, teams don't necessarily have a way of checking in with themselves regarding how their processes are working. It’s not feasible to say, 'Hey, you just broke a rule,' so we must create a vocabulary for discussing those uncomfortable dynamics that can creep into our workplace.

00:12:17.380 This led me to compile a list of bad estimating games as a light-hearted way for a team I was part of to address how we estimate. Having discussed why and how we estimate, I'll introduce some of these bad estimating games that we may have all encountered at some point.

00:12:55.630 Solitaire is the first game. This involves one developer estimating work alone. It seems simple, yet it's common knowledge that we should involve a few people to review the requirements before establishing a formal team estimate. We've all experienced times when one person, whether during or outside the estimation process, brings up a critical challenge we had overlooked. This insight can lead to better estimates.

00:13:51.130 However, it can be tough when someone casually mentions a feature in passing, such as, 'That story about the form field won't take too long, right?' In that moment, we might affirm it’s an easy story and declare it officially a two or three-pointer. Let's play a little charades now. I will act out a business role, and at the end, you can estimate the story I'm presenting.

00:14:55.580 (Acting out task) How many of you want to estimate this story? Clearly, I just provided you with fantastic specs, right? Well, if someone in the audience estimates 50, that's probably a decent guess. Charades describes the situation where you lack enough information to provide a reliable estimate.

00:15:30.490 Your project manager isn't likely to specify, 'We'll just use Devise,' without clear guidelines. If you've been on a project for a while, it’s easy to assume everyone is on the same page. The more common perspective is that login for this app should align with most applications, needing to support some basic features.

00:16:59.600 The issue arises when prior discussions and assumptions about typical user experiences replace the actual story details. Often, we don't realize that what we're delivering doesn't meet expectations until the last minute, just when we're ready to launch. If acceptance criteria, specifications, or comps are absent or unclear, this story shouldn’t be estimated because no team can accurately predict what they don't understand.

00:17:57.580 Charades has a sibling called Dummy Bridge, where a four-person game plays with three individuals and one person’s hand is revealed. This comes into play when estimating proceeds without the right people present; we essentially speak on behalf of that missing person. If someone needs to be present for their insights but isn’t, that story shouldn’t be estimated.

00:18:38.480 Next we have Slot Machines, where your team’s estimates are not revealed simultaneously. Instead, the slot machine process builds suspense by stopping each wheel one by one. In estimation, this is detrimental. It may appear that we are all comfortable expressing dissatisfaction, yet when we decide to take shortcuts, valuable perspectives are lost.

00:19:28.580 For instance, if senior people reveal their estimates first or if more vocal members give their estimates before fully discussing the topic, it can skew the entire process. It’s common for a team to interpret the question, 'So what do we all think?' as a prompt to share estimates, leading to half the room prematurely supplying their contributions.

00:20:00.690 This can wear down quieter voices present, as they start to feel out of place compared to those with assured estimates who are speaking without sufficient information. Thus, slot machines emphasize the loss of crucial perspectives.

00:20:48.020 Next is Estimation Blackjack. This is where if your estimate is higher than everyone else's, you’re out. This common experience emerges when a manager inserts themselves into the estimation debate, making you feel isolated for estimating higher than expectations.

00:21:30.050 This results in unrealistic estimates, with employees fearing repercussions for overestimating and consequently feeling pressured to revise their estimates down. This is similarly true in consulting, where clients may express confusion when their internal teams assume a project is straightforward, leading to unrealistic client expectations.

00:22:14.040 Lastly, we have Resistance, a newer game compared to the others I’ve discussed. Resistance takes a group of people aiming to oppose an occupying force, with spies trying to undermine their success. If you’ve played Mafia, the premise is somewhat similar, but for our purpose, it transforms into discussions and convincing your teammates about estimates.

00:22:59.990 Some friends who enjoyed this game wished to enhance their skills, so one participant would sit out to observe and note how players interacted. This person identified behaviors that helped players improve communication and their responses, but ironically, despite everyone improving, the spies began winning consistently.

00:23:49.680 When asked how this occurred, the observer noted that the spies were simply more engaged. Every spy began with a clear aim to convince others they weren't spies. Meanwhile, the resistance members had the general interest in wanting the group to succeed; thus, the spies monopolized conversations, making it harder for quieter players.

00:24:59.150 Consider how challenging it is to justify why you believe a project will take longer to complete, versus espousing facts about aspects you can speak with assurance. Unfortunately, the estimators with concrete information tend to overpower those highlighting uncertainty, leading to less accurate final estimates.

00:26:08.180 As I've discussed:* Solitaire estimates by oneself; Charades estimates when you lack required information; Dummy Bridge estimates without the right team members; Slot Machines that bias each other’s estimates; Blackjack that minimizes estimates; and Resistance that suppresses uncertainty. Let’s consider paths toward better estimates.

00:27:18.710 First, we must see estimation as part of our job. Many in our workplaces view every minute not spent coding as wasted time, and I have felt my time wasted during long meetings too. However, unless you're the sole CEO, CFO, marketer, programmer, and project manager, estimation is about respecting the work needs of others.

00:27:36.610 Conversely, it's important organizations clarify their needs for estimates. As a consultant, detailed and accurate estimates were vital for clear communication with clients. That realization reinvigorated the importance of long meetings for estimation. My company today needs estimates that are accurate, if not precise; we categorize stories as big and small. Correctly categorizing sizes matters, but we don't dwell on overly meticulous details.

00:28:47.210 When the discussions digress into two-pint versus five-pint estimates, we recognize we’re off-track and redirect to programming. It's essential to respect uncertainty as well; as we noted from Resistance, it can be challenging to acknowledge uncertainty. In my friends' game, each discussion round was limited to two minutes, reducing the chance for confident spies to dominate conversations.

00:29:52.520 However, this strategy feels arbitrary in the workplace, so unless it's an ongoing challenge for your team, consider two guidelines: first, acknowledge uncertainty as valid information alongside other presented facts. Secondly, lean toward higher estimates during disagreements to foster better concrete conversations. Investing in detailed discussions on estimates has always proved valuable.

00:30:35.700 Don't hesitate to block stories when seeking clarity and try spiking prior to estimation, particularly in more relaxed settings. Sometimes, estimating may involve writing code that clarifies technical requirements. Knowing the necessary business requirements—including when and how error messages should appear—does not address the implementation details needed for coding, leading to false complexity.

00:31:38.590 Last, we occasionally require breaks from current communication patterns. Changing processes may help. Exploring alternative structured conversation techniques, including Planning Poker, could foster better dynamics in a team needing to reset their communication.

00:32:43.490 It’s also important to express feeling overwhelmed during conversations—this transparency may facilitate process adjustments. If it helps, try using some of these games as terminology, such as 'I feel like we're playing estimation blackjack right now,' providing a conversational foundation to describe issues in a less confrontational manner.

00:33:54.210 Thank you, and I hope this was useful. I would love to continue our discussion on Twitter. I'm @cdward, and I would love to hear from you. Thank you!

00:35:05.730 Goodbye!

Ruby on Ales 2015