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 approaches 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.
Here’s what you’ll learn as you watch the episode:
Watch the episode here to learn how the EAT method can help you come up with more accurate product estimates.
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 in the comments below. We’ll be addressing a number of them in next week’s episode!
Check out these additional resources on estimating stories for your product:
Listen to the episode on iTunes!
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.
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?
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.
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.
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.
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.
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.
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Category: BuildTV
