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!
