We began this month with a Build episode where we exposed all the aftershocks of using current product management methodologies to estimate user stories. Then in last week’s episode, we dove into Hiten Shah’s new EAT approach which boils down to doing hourly estimates.
Don’t worry if you thought Hiten was crazy, you aren’t alone!
We received a lot of questions, concerns, and objections, so in today’s episode we’re going to dive into the top 3 we heard again and again:
Objection #1: My team is still healing from our previous approach.
“My team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" — Product Manager from Palo Alto
Objection #2: This won’t for our customers who want quick fixes!
“I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?" — New Product Manager from NYC
Objection #3: My team is eager to adopt a new process but how will this help them follow through?
"Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?" — Team Lead from Tulsa
Do any of these sound familiar?
Listen to the episode to hear Hiten's response to each!
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Check out these additional resources on estimating stories for your product:
## Why Hourly Estimates For User Stories And Technical Tasks May Seem Crazy But You Need To Do Them Anyway Transcript
Poornima Vijayashanker: Hiten, last week we instigated our audience by telling them your EAT approach on how they're going to get rid of their old methods and instead embrace doing hourly estimates. A lot of them have written in with their questions, their concerns, one even said you're totally crazy. I hope you're ready to deal with this pushback and address our audience's concerns.
Hiten Shah: Yeah, it's not the first time I've been called crazy. It's because I just want everyone to do better. I've heard everything from “there's no way I'm going to be able to get my team to do this, there's no way I can use this approach,” all the way to, “the approach I'm using today, whatever it is, works just fine.” Yet, those same people say they can't ship on time. Also, “we just can't estimate accurately, we've tried it before, and it's impossible.” I've heard everything.
Poornima Vijayashanker: Awesome. I hope you're ready. Let's just dive right into it.
Hiten Shah: Let's do it.
Poornima Vijayashanker: Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.
Hourly Engineering Estimates Is Crazy
Over the last couple episodes, we've been talking about estimates, and you'll recall in the last episode we unveiled the EAT method and talked about how this is all about hourly estimates. I'm sure, for those of you out there, you were thinking, "This is crazy, people will never adopt this on my team." In today's episode, we're going to address a number of these concerns. To help us out, I have invited back Hiten Shah who is the founder of multiple products, and his most recent project is called Product Habits.
Hiten, we put out your EAT approach, your EAT method, and we got a lot of feedback. I want to start by throwing some questions out there from our audience and, hopefully, you'll be able to answer them.
Hiten Shah: Rock and roll.
Adopting A New Product Management Process Is A Big Investment For A Modern Software Team
Poornima Vijayashanker: Awesome. Here's the first question, this is from a product manager and they wrote in saying, "Hiten, my team adopted agile five years ago and experienced a number of problems that you talked about in the first episode. So, six months ago we took the plunge and decided on no estimates and, of course you can imagine, we're still recovering from it. The wounds are raw. So, how am I going to get my team to try something new especially since this is going to be another investment in terms of time?" What are your thoughts?
Hiten Shah: Every time you do a process improvement and it involves product people and engineers, they do like process; if they don't then they're probably working at a really early stage startup and spending a lot of time just probably working 18 hours a day just coding and things like that. That's a whole different story, but in this case it sounds like a larger organization to some extent and a bigger team. In those teams, the best advice I have is don't think it's going to take time. I'm not saying you rush into anything or anything like that, but you can start with the E part of the EAT method and really focus in on understanding how to have your team as engineers and the product team learn to explore and learn to really figure out what the communication differences are between the teams. That technical research outline really helps you do that.
If you were to implement one piece, start at the top and start with creating that technical outline on the next project you do. This isn't a whole big process improvement, system changes, and take everybody and regroup them, and all this stuff—
Explore: Before You Do Product Estimates Do Your Technical Research
Poornima Vijayashanker: Call in change management.
Hiten Shah: Yeah, none of that. No, we don't like that. I don't like that. Anything I suggest wouldn't fall in line with that. Can you just start with starting with the explore aspect of it? Then, playing it out on the next initiative you're going to do, however small or large you think it is? You'll already start seeing improvements.
Again, seen that happen, heard this objection. Part of it is because of exactly what the person was saying, "I've done this before. It didn't work. The thing we went to is still causing us all these problems, hence why we started with the problems and most of the states people are in." I kept hearing that over and over again. The simple solution is start with this one document and create, what I call, a technical research outline, and use that to communicate with engineers.
The two main components—again just to repeat this—are the evidence, the reasoning, the customer feedback, anything you have there as to why you're building it so that your engineers and rest of the product team can get close to the customer. My favorite part still is the open questions because you're going to have questions about what you're building that might've never previously been answered in your process. Just that and then having communications while engineering solves this problem, but don't think it's going to take forever.
Customers Want Quick Fixes
Poornima Vijayashanker: The next question is, "Hiten, I hate to play the blame game, but a big source of our problems is our customers. Many want quick fixes, so we end up at their mercy and boy, do they hate eating their vegetables. How do I get them to come around?"
Hiten Shah: The good news is you're not asking the customers to eat any vegetable. You want to create that dessert for them, if you want to put it that way, but what you're looking to do is get your team to eat their vegetables. What I would suggest is that you take away this idea that you're ruled by your customers in terms of you have to do what they say and instead start taking a bunch of the items that they're giving you and start going through the whole EAT method process and getting actual estimates because then you'll actually be aligned with them. What they want to see is that you're improving the product based on what their needs are. What you want to do want to do is improve the product based on their needs.
Tell Your Customers What You Can And Can’t Deliver On
Just by applying the method itself on a high level and starting to go through the process with your team, you can go all the way to the explore aspect and the adjust aspect and you don't have to get to task yet as long as you can have an idea of comparing one thing they want versus another. Then, you can apply the idea that, "Well, we now have an idea that this thing we can do for them is going to take a week, this other thing is going to take a few days," which is probably a process you're not going through right now. Then, you can pick based on that.
Usually, I pick the thing that's going to happen quickest most of the time just to get all those knocked out and keep customers happy. Over time, you would create a balance of both types of things.
Poornima Vijayashanker: I'm sensing from this audience person that they probably have some customers that expect things done right away. Maybe like in the next day, week, or month, they have some deadline in their head that they want the team to meet.
You’re Probably Not Delivering A Product Fast Enough For Customer Right Now
Hiten Shah: This whole process you can add criteria, such as “our goal is to release this by this date,” and then the discussions happen. The whole idea of the process is that you can start setting certain criteria and, to me, what I've done before is put that as an open question. This is the most important thing customers want and we'd like to deliver it within, whatever the criteria is. Then, you get to have the discussions with engineering.
Here's the funny thing: even though a customer might have demanded it that fast, that doesn't mean today you're delivering it fast enough for them anyway. This is the most common thing. It's like if you have a faulty process or a process that's not delivering it; it's a circular kind of logic. For me, it's being deliberate and actually getting the estimates will help you get to a place where you can deliver something at the speed that your customers want it. Usually, the customers want the communication and they want accuracy just like you want more than they actually care that it's going to be delivered when they want it. If you tell them, "Hey, we can't do it in a day, but we guarantee it'll be done in three," and you get it done in two or you get it done in three they're happy.
How To Get Your Team To Follow Through On Providing Hourly Estimates For User Stories
Poornima Vijayashanker: Last question for you, "Hiten and Poornima, thanks again for this series. Unlike some of your other audience members, I have the opposite problem. My teammates are eager to adopt a new process, but when they hit a snag they are quick to punt and just do whatever they think they need to do to get the job done. What is the one thing you would advise them to have them stick through when implementing the process and practice of hourly estimates?"
Hiten Shah: This is great. It's great to have a team that's motivated to try new things. The best thing you can do for a team like that is give them the outlet to communicate at every step about how the process is working because then you can remind them that we're convicted, we need a better process. We're convicted that we want hourly engineering estimates on things, and so we are going to keep doing this process until it works. Thus we're going to include feedback from you, the people who are doing it into the process, and we're going to make improvements over time.
A technical research outline is created, let's say, and then the engineers work on it, and before you move on to the next step of the EAT method of adjusting, you would take a quick five minutes and let everyone give feedback on the outline itself. Was it effective? Did we miss anything? Are there things that we could've done better? Questions like that.
Collect Feedback From Your Engineering Team
I think, for me, if you're running a team, your job is to get feedback from them. Even with any kind of process that you want to change or improve, you want to sit there and say, "OK, how can I make sure that the team is aligned on it?" This is what I would call an alignment tool across the board, so that you're getting their inputs as well, and they don't have this fear or this reason to fall back to old practices that screw up the whole process.
Poornima Vijayashanker: That is the discipline, the getting the feedback and doing the adaptations as you go through.
Hiten Shah: You can't improve without feedback.
Poornima Vijayashanker: Yeah, got it. Thank you so much for taking the time to address a number of these concerns and objections that our audience has, Hiten. Any final words for our audience?
Hiten Shah: Yeah, absolutely. I'm super happy that all of you have watched this. This specific subject was the most controversial subject I've written about, ever in my life. I write about these things on my newsletter, Product Habits, you can sign up at producthabits.com, and I'll be talking more about things like this that are there to help you out all in emails though, no videos, so thank you for having me on video.
Poornima Vijayashanker: You're welcome. We'll be sure to share the link to Product Habits with our audience.
Hiten Shah: Thank you.
Poornima Vijayashanker: That's it for this series and today's episode of *Build*. Be sure to share it with your teammates, your boss, and be sure to subscribe to our YouTube channel to receive the next episode of *Build*. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
I don’t know about you but I HATE kale… That stupid leafy green vegetable with the ANDI score of 1000. It’s really hard to chew, and any time I see it on a menu, I skip it! But I get there are a lot of kale converts who go around saying, “Eat your veggies, especially kale!”
OK, I know what you’re thinking, “What does this have to do with building software products and product estimates?”
Everything.
Just like we have to buckle down and eat our veggies (including kale) to stay healthy, there are a number of things we need to do in order to have accurate estimates that will ensure shipping a product consistently.
In the last episode of Build, we mentioned how a number of the current approach fall short. If you were left wondering what to do next, don’t fret, because in, today’s episode, Hiten Shah is back. He’ll be introducing a new approach to coming up with product estimates, and it’s coincidentally called the EAT method.
As you watch the episode you’ll learn:
OK I know what you’re thinking… “Ugh not another approach!” OR, “This is never gonna fly at my company!”
Well that’s why after you’ve watched the episode, we want you to let us know what your concerns are tweet to us: @poornima @hnshah. We’ll be addressing a number of them in next week’s episode!
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
Check out these additional resources on estimating stories for your product:
## What We Need To Do To Produce An "Accurate" Ship Date For Our Product
Poornima Vijayashanker: In the last episode of *Build*, we explored a number of approaches to estimating work, and shared some of the shortfalls when it comes to over-, under-, or just not estimating altogether. If you missed the episode, I've included a link to it below. In today's episode, we're going to suggest an altered approach to estimating that you can adopt and adapt for your team, so stay tuned.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayshanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now one of the most elusive processes is coming up with estimates for a project or for a task. You'll remember in the last episode, we shared some of the shortfalls of the current approaches. In today's episode, we're going to suggest an alternate approach that you can adopt and adapt to fit your team and your product's needs.
To help us out in today's episode, Hiten Shah is back. You'll recall he has built a number of products. His most recent project is called Product Habits. Thanks for joining us again, Hiten.
Hiten Shah: Happy to be here.
Poornima Vijayashanker: Yeah, so let's go ahead and dive right in. I know we talked about a number of approaches last time, but I'm curious to hear what's your approach for estimates?
Estimating User Stories Is Like Eating Your Veggies
Hiten Shah: Well first, I have to say it's like eating your veggies.
Poornima Vijayashanker: OK.
Hiten Shah: With veggies, everyone knows they should eat them.
Poornima Vijayashanker: Right.
Hiten Shah: Many of us are not very good at eating them. We all know the reasons why. It's for health reasons and to prevent certain diseases and things like that. To me, the idea of getting accurate estimates is exactly like that. Nobody really wants to do it, but everyone knows they need to.
Poornima Vijayashanker: Well some of us need to buckle down and eat our veggies.
What You CANNOT Do With Hiten Shah’s EAT Method
Hiten Shah: Yeah, of course, but first let me talk about what you can't do with this approach that I'm going to share because what you can't do sometimes is more important than what you can do.
Poornima Vijayashanker: Sure.
Hiten Shah: What typically happens is that you have no estimates, or you have agile with points, or you have some kind of waterfall process, or you have some kind of build, measure, learn, lean startup process going on. If you're not actually doing accurate estimates, you end up running into all these issues. My method will make it so that you don't have to run into these issues. The issues are more issues of what I would call interpersonal communications between team members and teams. They involve things like, believe it or not I've seen this, engineers getting yelled at for not doing their job, so to speak, which would be actually creating the software.
Another example would be we end up sort of like scapegoating and saying that it's this person's fault, or that person's fault, or this team's fault. You can't do that with your engineers if you take this approach. I think partially most importantly of all, if you're actually able to be deliberate and take the approach I'm going to share, you're just going to make it so that you don't have this lack of clarity across the board. I think that's the most important thing. When there's a level of ambiguity on a team about what's going to happen, when it's going to happen, all that kind of stuff, it leads to all these problems of culture, leadership, management. So you're actually preventing a ton of problems if you can do this method.
Poornima Vijayashanker: OK, so what's the approach?
EAT (Explore, Adjust, and Task) Method For Providing Hourly Estimates
Hiten Shah: Yeah, so the approach is called the EAT method. The whole idea behind it is to do this three step process. It's an acronym for each of the three steps. The first step is explore, second step is adjust, and third step is task. The thing is, the whole goal behind it, is to get 100% accurate estimates. That means that you're down to 15 minute blocks, or hourly blocks, of estimates from engineers.
Poornima Vijayashanker: Wow, so people who normally can't estimate are suddenly going to be able to give you an hourly estimate of how long something is going to take?
Hiten Shah: Yeah, it's like magic.
Poornima Vijayashanker: Yeah, it sounds like that.
Hiten Shah: Like eating your veggies over your lifetime right, and being a healthy person.
Poornima Vijayashanker: Yeah, I think you're going to have a dive in a little deeper.
Explore: Do Technical Research To Uncover What It’s Going To Take To Build A Software Product
Hiten Shah: OK, sure. The first step is explore. In that step, there's one sort of piece of that step that's most important. What I named it is technical research. The reason for that is product people are used to doing user research, they're used to doing customer research, and so research is a word that they're used to, and it's something that the nonengineers start. What that involves is creating essentially a technical research outline. There's many different ways you can do it, but a high level of it is you're explaining exactly what you want to build, and you're also including the reasons you want to build it. Majority of time, depending on your organization, the reason you want to build something should be because there's a customer need, customer paying, or a business problem you're trying to solve, or a combination of both. Then from there you're actually going all the way down to if you have mock-ups, if you have any kind of sketches, you're putting it together.
Then my favorite part of it is when at the bottom you would write this whole idea, or this section, called open questions. These are questions you might have. You can already kind of figure out, you might have already figured out some of the things that might be tough or not tough. Then what you're doing is you're not just keeping that to yourself, you're not just keeping that on your team with your close folks who helped you write it, you're actually providing that to your engineers before they build anything, and before they even think too much about the problem ideally. That's their opportunity to evaluate it. So, that's the first step.
Poornima Vijayashanker: OK.
Adjust: List Out Open Questions That Need To Be Answered
Hiten Shah: Then the second step, which is sort of the adjust period, involves after they've taken a look at it, made comments, often times they add their own open questions because they have questions for you too, and so it's just a way to get this communication very deliberate instead of making it all happen in conversations that are either not recorded or just not setup in a way where people can look back at it. From the commenting and the open questions, you're able to adjust what you're going to build. This is the critical piece because if that middle piece of adjusting doesn't happen, that's where estimates completely fall down and that's where you run into all the problems we mentioned earlier in the previous episode about scope creep, and padding. All these things are a result of actually not communicating, and not adjusting what you want to build based on what the engineers tell you is going to be difficult, hard, easy hopefully.
A lot of times even the most seasoned product person and the most seasoned engineers don't generally have an idea of what's easy or hard, what's going to hypothetically take a long time or not, without actually diving into the details. This gets everyone on the same page about that. After that process, sometimes it takes multiple back and forth to get a really good document that outlines a technical research, ideally anyone on the engineering team that could work on this is able to take that and start tasking it. Actually it's engineering tasks in sort of your task management tool, or whatever the tool engineers are using, Pivotal Tracker for example. Then instead of putting points, that's the time when engineers are able to put in minutes and hours. I like 15-minute chunks is what I've found to be most valuable for my teams as part of this process.
Iterate As You Go Along To Avoid Misconceptions And Miscommunications
This is one of the things that's more of like what we would call a process improvement. When you do process improvement, it takes iterations to get it right. But what I've noticed is when the teams are deliberate and the product people really bought in to sort of wanting to do better and same with the engineers, this process completely reduces all that ambiguity and misconceptions, and miscommunications that happen when people are just assuming things about what to build and how long things are going to take. By then, the engineers are very comfortable providing very detailed estimate on tasks.
Poornima Vijayashanker: This is pretty novel, and I know that if I'm hearing this for the first time, I sure as heck am going to be opposed to it because I'm thinking I've got to get my whole team to buy in, there's new things I've got to do, all this technical research. I'm not sure I'm going to adopt this in the next week or even month. I think I'm going to have to slowly unveil it. I think our audience is going to have a lot of concerns for the two of us, but I think we should just stop right here.
Hiten Shah: Yeah, I have good news. I've heard it all before, so I'd love to hear it from them.
Tell Us Your Concerns Or Objections To EAT Method
Poornima Vijayashanker: Awesome. Well, Hiten and I now want to know what are your concerns with the EAT approach and doing estimates in this 15-minute interval with overall hourly estimates. Let us know what they are in the comments below. That's it for this week's episode. Be sure to subscribe at our YouTube channel to receive next week's episode, where we're going to dive into these concerns and hopefully address a lot of the objections that you're going to get from your teammates and your boss. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
What’s probably the MOST popular and frustrating question you’ve come across when building a product: “How long do you think it will take to do task X?”
It’s frustrating on so many levels…
First, we need to produce an “accurate” estimate. If it’s off, there goes our ship date!
Next, we need to give a response that seems “realistic”, i.e. is going to meet the expectations or deadlines set by someone else.
Third, we need to be a fortune teller and anticipate things that come up in the course of completing task X.
Finally, we have to do it the moment we’re asked because we’re expected to know how long any task will take.
I don’t know about you, but despite building and launching a number of software products over the past 14 years, I still struggle with estimating how long a task will take to complete.
There are a number of approaches and methodologies that have sprung up over the years such as Waterfall, Agile and Lean whose goal is to provide a framework that helps engineers, designers, and product managers to estimate how long something will take to build and ship. However, as you’ve probably experienced, each one of these misses the mark.
In today’s episode we’ll dive into the aftershocks you may experience when it comes to following one of these approaches and providing product estimates.
Next week we’ll tackle an alternate approach that may seem too good to be true…
To help us out, I’ve invited Hiten Shah, who is the founder of a number of software products such as Crazy Egg, Kissmetrics, and his most recent project is called Product Habits.
As you listen to the episode you’ll learn the following:
Check out these additional resources on estimating stories for your product:
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
## Why It’s Hard to Provide Accurate Product Estimates Under Most Popular Product Management Methodologies Transcript
Poornima Vijayashanker: Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode of *Build*, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. One of the most elusive processes has to be estimating how long a project or a task is going to take. And no matter how many times we do it, we somehow just always miss the mark because things come up. Well, in today's episode, we're going to share some of the aftershocks you may experience despite what approach you take when it comes to estimating. In a future episode, we'll dive into an alternate approach in how your team can adopt and adapt it to fit your needs.
To help us out in this episode, I've invited Hiten Shah, who is a founder of many products. His most recent project is called Product Habits. Thanks for joining us today, Hiten.
Hiten Shah: Thanks for having me. Happy to be here.
What Happens When We Don’t Accurately Estimate Stories Or Tasks
Poornima Vijayashanker: Yeah. You and I have been building products for a number of years. We've built a lot of different ones. And I know myself being an engineer and a product owner, no matter how many years I put in, I just constantly miss the mark no matter what. I either end up underestimating or overestimating. Let's dive right in and talk about what are some of the problems that happen when we don't accurately estimate.
Hiten Shah: Yeah. I think, when we're building products, we don't generally think about how long it's going to take to build them even though we pretend we do. We end up creating a road map with a bunch of timelines and we don't actually talk amongst the team, because, usually, a product can't be built by a single person. If it could have been built by a single person, then you don't have to worry about it as much because that single person has all the answers. One thing that ends up happening is you end up having surprises that come up that you didn't think of. You're thinking about using a certain technology, let's say such as Twilio or SendGrid or an API and the engineer has never used it before. They get in the weeds of it and they realize it's going to take longer than they think. And then your estimate is blown up and you're off. That's a very common problem.
What Causes Scope Creep In Product Management
There's a few others, too. One other one that I've seen people hit continuously is this idea of scope creep. We're both product people. You happen to be an engineer. I happen to be more a marketer. But we love product and building them and teaching other people how to do it, too. One of the aspects of that is we might still be learning and doing research as the product is being built, and we all of a sudden have this great idea we want to add. We go in and kind of blow up the whole process and expect that the timeline is not going to change or don't even think about the timeline and say, "Hey, we're going to build this new thing on top of the thing we're doing." Or, "Can you add this little tweak?" And not realizing how disruptive that is to the process of building the product itself.
What Happens When Communication On A Modern Software Team Breaks Down
Another thing that's very common is that if you aren't communicating very well with your team, especially the engineers when you decide that you're going to build something, what ends up happening is the best thing that they can do if you haven't spent enough time communicating early and often is they end up padding. They end up actually adding a whole day—or worse yet—a week or months to a rough estimate. We call it a rough estimate because it's rough.
Those are some of the more kind of common problems that come up when you're building something and trying to get estimates and actually think you have the right great estimates, which is the most common thing. And then all of a sudden all these things happen that you are probably are not conscious to about what kind of problems they cause in terms of being able to ship something on time.
Poornima Vijayashanker: Right. I think two other things I'm curious to hear your take on are large tasks. How do you actually divide them up and then the follow through? You think you're 80% way there and then you discover actually you just finished 50%.
What Causes Scope Creep? Large Tasks That Aren’t Broken Down.
Hiten Shah: Yeah. I see companies creating, even in my own companies, so much work that is not actually broken down enough. You might think that it's easy to add a button somewhere, so you say, "OK. This is a button." You think it's a small task. Maybe you're not the engineer, because often times you're the product person, or even if you are the engineer. Then the engineer, whether you decided to do it as an engineer or the product person, you get into the task and all of a sudden you're like, "I have to add the button." There's all these other things that need to change whether it's the user interface, or you're missing a certain component, or what that button does is more complicated than you thought. What ends up happening is this seemingly small task is actually a large task. It's usually because you haven't thought through all the things that you need to think through when you add something like that. And I'm talking about a button. Imagine a whole feature. Right? And considering that to be a small task when it really turns into a large one. I think the most common thing I see is that these things you consider small are actually large.
What Causes Scope Creep? Thinking That Tasks Are ‘Simple’ Or ‘Small’
Another common thing is not realizing that what you're asking for is actually a large task. Right. Like adding a messaging feature or things like that. Even a lot of times, I've had emails come in to me from people who are customers saying, "You can send me SMS as notifications. It will take one hour using Twilio, another two hours through your database and you're done."
Poornima Vijayashanker: Great. Come on down and write it for us.
Hiten Shah: You want to do it for me? I'll hold you to the three hours, because it's never as long as people say it is.
Poornima Vijayashanker: Yeah. There's a lot of different approaches we also like to take when it does come to estimating. Even though we know all these problems, we still continue to take an approach. Right? Let's dive into the approaches.
Well-Intentioned Product Methodologies: Waterfall, Agile, and Lean Startup
Hiten Shah: Yeah. I think one of the most common approaches that is very still operated by in a lot companies is what we call waterfall, which is one task happens after another task, after another task. A lot of times people are waiting on these things. This is actually the reason another process was invented called agile, which I know both of us are familiar with. Where you're essentially—the way I would describe it is you're trying to do things much more efficiently by basically having more regular meetings and having, I guess, smaller batches of work. What ends up happening there is you create this sort of system that works almost on a weekly basis at best. It means that you have a cadence of following up on all the tasks, we call it agile because you're supposed to be more agile with it and it's more nimble than waterfall and that's completely true, but you lose a lot in the process. Those are the two common ways that I'm most familiar with.
Then there's a third way, which I think is more inspired by things like *Lean Startup*, which again I like to say that we both probably grew up with that so to speak, around us. That's where you are even more hyper—I would call that more hyper agile than anything else, where you're adding in the component of much more customer feedback in the process, because agile wasn't necessarily invented at a time when customer feedback was a popular thing.
Poornima Vijayashanker: Right. What are some of the painful after effects of using agile?
How To Estimate Stories In Agile
Hiten Shah: What ends up happening with agile—one of my favorites, and there's a lot of tools out there that facilitate this—is the idea of adding points to an agile process. What you end up doing is you're officiating time. You're saying that something that would take one to three hours is like one point. Or something that would take three to six hours is two points or three points. And they have all these things like Fibonacci sequences. There's a lot of fanciness around points, when you're really trying to understand time not points. The reason that points exist is because—and not that I think this is necessarily bad, it's better than other methods—but some engineers decided that they wanted a metric that wasn't time.
Poornima Vijayashanker: Right.
Hiten Shah: They literally said, "It can't be time, because we cannot estimate."
Poornima Vijayashanker: Because they basically didn't want somebody to know that something was going to take only 15 minutes or five hours.
Hiten Shah: Exactly. Your minimum there is an hour at best. Often times it's much more. The thing is every team that I've seen implement agile with points in different ways. Their whole buckets around the number of points something takes is all different. What ends up happening is that engineers now feel great because they have a velocity score. And they can talk about how many more points they're doing every week or how many points they're doing every week as a total. And that's really hiding what I would call the truth, which is how long did something actually take.
Poornima Vijayashanker: Yeah. I know one of the alternatives is to just get rid of estimates all together, but you've probably experienced what that's like. Talk about what results when you get rid of estimates.
What Happens When You Get Rid of Estimating Stories
Hiten Shah: Sure. If you get tired of agile for whatever reason—and usually this happens because somebody that's a non-engineer is really not into it, because they don't understand what a point is even though it has timings and stuff. Then estimates are completely removed, which means points are removed and then there's just tasks. Then you run into some of the problems from earlier. Is it a small task? Is it a big task ? What it really boils down to...if you have no ability to understand how long something’s going to take or even how many points, let's say, then you end up not knowing how to prioritize what you work on. If there's just 10 tasks and all of a sudden the engineer's working on one and then you ask the engineer, "Oh. How are you doing?" They're like, "Oh, it's going to take another week." Well, if I had known that task you took was going to take another week or two weeks or whatever, I probably would have told you to work on something different because our customers are waiting for things. Right.
And that tends to be one of the bigger problems that happens, which is this communication breakdown because nothing is estimated, whether it's points or hours or whatever way people want to do it. And you end up having a massive communication issue and then you have these fiefdoms that get created. You have engineering not against, but against product, against sales, against marketing. And everyone's just waiting for product, everyone's just waiting for things to ship so you can make customers happy.
What Happens When You Pad Your Estimates
Poornima Vijayashanker: Right. One of the alternatives to both these is to create a buffer. Let's pad the system so that as an engineer I don't look bad and as a product person you feel like, oh, OK, there's some wiggle room. But we know that that has its shortfalls. Let's talk about those.
Hiten Shah: Yeah. Of course. I think padding is probably one of the worst practices, and you might as well have no estimate or no points or anything like that, because you're essentially saying that whatever estimate I give you, I don't know. I don't know. I'm going to pad it. Then you get in this padding mentality and then you still end up with the same problem that you actually didn't have a real estimate, and things are such a moving target that you failed to ship, you failed to actually do proper planning. You end up having a business where you're actually not getting the product you need in your customers’ hands fast enough so you can actually grow the business. I think padding leads to a whole different set of issues, because what ends up happening in the worst way I can say to you—and I've already said it in pretty aggressive ways—is that everyone's lying to everyone else. That doesn't help with prioritization or getting anything done either.
Poornima Vijayashanker: Well, thank you for taking the time today to share the shortfalls of these three approaches. I can't wait til next time when you unveil your approach for estimates.
Hiten Shah: Yeah. Can't help but share solutions with problems.
Poornima Vijayashanker: Thank you.
How Do You Estimate Stories And Tasks?
Now, Hiten and I want to know, have you tried one of these three approaches and how have they fell short for you? Let us know in the comments below. And that's it for this week's episode. Be sure to subscribe to our YouTube channel to receive the next episode where Hiten is going to dive into his approach for doing estimates. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.