![]() If missing deadlines is a pattern, then we want to understand why. If we miss a deadline, we hold a post-mortem and learn from the experience. The team knows the deadline is important to hit. And from the firm estimate we can build a deadline. Now we switch to the terms “firm spec” and “firm estimate”. We’ll be expecting little change from this point. And at a certain point, we’ll be in agreement of what the spec is, and what the estimate is. What we get through this process of refining specs and estimates is a funneling process. We can say, “let’s change the rough estimate to reflect that.” So Product comes back with more information, “We figured this out, here are some bullet points of what we’re going to need.” We look at it and say, “Oh, we thought you were going to need this and it’s not there, so we can actually reduce the rough estimate a bit.” Product goes off and comes back with a more refined spec, now there’s an integration we weren’t anticipating. Dropping the word “rough” can get us into trouble - it might go to the marketing team or the executive team - but using the word “rough” gives us flexibility. If they give me a rough spec (which could be just a sentence), we can give them a rough estimate. Maybe they ask “Hey, what would it take to get this feature?” We want to partner and also to protect against misunderstandings. I want a low barrier for Product to ask Engineering for an estimate. One way teams can be more clear in their communication is to use the terms “rough estimate,” and “firm estimate.” Make sure everyone knows the definition of “complete.” 4. I’ve seen developers believe they are aiming for “code complete”, when stakeholders were expecting deployed features available in production. Is the project through testing, is it through production, does it mean we’re A/B testing with customers? Get on the same page about what will be complete at the deadline. Agree on what is “complete” at the deadline Which height best represents your project? What is the cost of failure? Is this a “bet the company” project? If so, you’ll want more certainty. Same thing with the plank at one hundred feet. Now let’s place the four-inch plank two feet off the ground and the eight-inch plank twenty feet off the ground. When I explain what the cost of failure is with teams, I use an analogy: Would you rather walk the length of a ten-foot plank that is four inches wide, or that is eight inches wide? Of course, we would all take the eight inches if we are trying to succeed. We can come to a specific level of confidence by considering the cost of failure for a given project. They should also reevaluate that level of confidence for “big” projects. Do you want 70% of your projects to be completed before the deadline? 80%? 90%? That’s a decision teams can agree on. Teams should decide what level of confidence they’re comfortable working with. (e.g., a 90% chance the work is completed before the deadline, 80% or 70%.) For deadlines, we take the estimate and slide it back to a point where there’s a higher probability of the work being completed “before” that date. Where with an estimate you’d expect 50% of your projects to be completed before and 50% after the date, with a deadline you’d slide that date back to a confidence level you’re comfortable with. And as soon as we’re talking about a deadline, we’re talking about a date where the work is ideally completed “ahead” of time rather than behind. The important thing to note is that “a little after” or “a little before” are both perfectly valid outcomes.īut oftentimes when people say “estimate” they’re actually talking about a “deadline”. If you picture a standard bell curve, where the top of the bell is your estimate, what you see is that most things get completed either a little before or a little after the estimate. ![]() There’s a difference between an estimate and a deadline:Īn estimate is your closest approximation of when something might get completed. We’ve gotten a lot better as a team about hitting deadlines. They “missed” the deadline because there wasn’t full clarity around what the deadline meant.Īt Divvy we’ve written these practices down and coach managers to follow these practices. I’ve seen it throughout my career: a team didn’t separate their “estimate” from the “deadline”, didn’t discuss the cost of failure, or didn’t agree on the definition of done. Missed deadlines are often the result of simple miscommunications. In this interview, Bruce Weller, VP of Engineering at Divvy (acquired by ), describes the practices he coaches teams on to help them set clear and realistic deadlines. This interview is part of our Fieldnotes series, where we share how industry leaders are improving different dimensions of the developer experience.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |