Hey everyone, you're listening to Developer Tea. My name is Jonathan Cutrell. Do you ever get the feeling that everything seems to be going right, but nothing seems to be working? Everything seems to be going right because all of the measures that you're using indicate that things are going well. But the things that matter, they're not going so well at all. This happens in startups all the time. The startup seems to be doing well as far as shipping features go. They're responding to customer requests. And yet the startups bottom line is failing. What is happening when we have a mismatch between what seems to be the case and what is actually the case? That's what we're talking about in today's episode. Before you listen to this episode, I encourage you to go back and listen to the previous episode of the show, the one that released on Monday, this particular episode talks about setting your goals and the concept of productivity. And as it turns out, it's directly related to what we're talking about today. But first, I want to see if you identify with this story. You and your colleagues are on a software engineering team and you have requests that are coming in from product managers and other teams that are in the company that you work for. You have external requests. All of these things are being organized on some kind of board. And you're taking what you believe is the most important request and working on them. And you have a way of defining how much complexity is involved with a given request. You may do some estimation up front and go and perform the actual work necessary. Correct that estimation. And ultimately, you have some picture, some prediction of what the complexity is. And ostensibly, you along with your product manager, maybe the engineering manager, someone who is responsible for the productivity and keeping tabs on the productivity of the team, you measure your productivity based on the trend of how many of those complexity points you complete. It's a some familiar. It should. And if you're doing something like Agile, then you're likely using something like StoryPoints. It's quite similar. And the StoryPoints are intended to abstract the idea of complexity away from the idea of time. And they should be some representation of the work completed. And so if you have, let's say, 50 StoryPoints in your backlog and you're completing 10 to 15 StoryPoints per week, then you can imagine that in something like four to five weeks, those 50 StoryPoints in your backlog, you could expect to complete if no other work shows up. And so in order to make your team more productive, you want to increase your StoryPoint throughput. This is the most common thing that we're trying to measure and then optimize. We want to increase our StoryPoint throughput, our velocity. Now, if you identify with that story, you probably also identify with the fact that your increases and your velocity seem to never really make a huge difference in terms of your success. This isn't always true, but imagine that many of you have had this experience where you've increased your velocity, but the company doesn't really register the improvement. Your manager's may, but the bottom line doesn't seem to change. We're going to talk about why that might be the case. Right, if we talk about the sponsor. This episode of Developer Tea is sponsored by InstaBug. Building and maintaining mobile applications is not simple. Bugs, crashes and performance issues can be a nightmare for developers. What if you can not only detect and dissect these issues, but also get a holistic understanding of your app's performance? Well, within Sbug, you can. Through comprehensive bug and crash reports, performance monitoring and real-time user feedback, InstaBug gives you the visibility that you need to build top-quality apps. Observe and fix issues like UI hangs, slow app launches and screen loads, network failures and anything else that may be affecting your user experience. Get a quick read on their impact on your users and access all of the granular data relevant to the issue in seconds so you can prioritize, assign, and debug before your next update release. It only takes a minute to integrate InstaBug's SDK into your app and it fits right into your workflow with integration support for JIRA, Slack, Trello, GitHub, Zendesk and many more. Stop flying blind on your mobile app issues and try InstaBug today. Go to InstaBug.com and get the visibility you need to start delivering superior app performance and better user experience. InstaBug.com Why do your story points, your velocity, why do they never seem to actually make a difference? Why do they never have a real impact on the company? Well, you may want to take a look at what does seem to have an impact on your company and we can't answer that question in this episode because the answer to that question is highly unique. But what does seem to be universally true is that most of the fluctuations we have in our productivity don't have a meaningful impact on the bottom line. They don't actually change how effective our company is at making money. Why is this the case? Now, I can already hear you, I can hear people saying that, well, in fact, it does have an impact. We just can't really directly tie those impacts to the work that we've done. And that's a fair criticism of this point. But in a vast majority of cases where you're trying to improve productivity by measuring something local, right? In other words, you're trying to measure your productivity as a team based on the throughput of arbitrary complexity. That's the important point right here. The arbitrary complexity, the complexity that you accomplish, right? The complexity of the tasks that you complete is rarely directly correlated with the bottom line of your company. Think about this one more time. The complexity of the work that you do is rarely correlated with the amount of money that you're going to make from that work. And so in order to measure our productivity towards a goal, remember from the last episode, the productivity is meaningless without a goal. In order to measure productivity towards a goal, we shouldn't just be thinking in terms of complexity because the complexity is not a measurement of our movement towards that goal. In fact, in some cases, a higher velocity, a higher investment in complex tasks, more complexity completed may actually be counterproductive to your goal. Now, am I saying that you need to abandon story points, abandon agile? Not really not. Let me be very clear that measuring complexity is important still. But thinking about what that complexity means clearly is even more important. If you can't tie the work that you're doing to the actual value that it's producing, right? If you can't understand the value of the work that you're doing, then you'll never be able to understand the productivity of the work that you're doing. A simple proof of this. Take two tasks. One has a complexity of, let's say, five and a value of five. The other has a complexity of seven and a value of five. Which of these tasks is likely a better task to take on. Hopefully intuitively, you know the answer is the less complex task. The return on that complexity investment is equal to the return on a higher complexity investment. So let's go with the one that's less complex. But if you were just looking on a piece of paper and only the complexity that was completed, you have an incorrect picture of productivity. Seven points versus five points. So here's the homework for you to do. When you think about prioritization, specifically when you're talking to your product manager, when you're talking to your engineering manager, when you're talking to your team, it's start talking in terms of relative value. Start talking about how much of more valuable one task is than another. What you'll quickly understand is that the most important process to get right on your team is not the complexity analysis. It's not actually implementing anything. The most important process is prioritization. Getting prioritization right is the first step in making your measurements actually produce something valuable. All of your velocity and story points, if they're headed in the wrong direction, will lead to great numbers on paper, but a failing team and a failing organization. Instead, focus your efforts on doing the right things, doing the things that produce the most value, regardless of the complexity that you get to chalk up to your velocity. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoyed this challenging discussion on complexity and velocity, and hopefully you see this picture as clearly as I can lay it out. This idea that your measurements, your local measurements of productivity don't always translate to something that matters to your company. This applies in our lives. It applies in so many areas. We need to be focused on the things that we care about most and then measure for those things more than we're measuring for some kind of local productivity scheme that we have in mind. Thanks so much again to today's sponsor, InstaBug. Building and maintaining mobile applications is not simple. Through comprehensive bug and crash reports, performance monitoring and real-time user feedback, InstaBug gives you the visibility you need to build top quality apps. Go to InstaBug.com to give it the visibility you need to start delivering superior app performance and better user experience. It's InstaBug.com. If you enjoyed this episode of Developer Tea, you enjoyed this discussion and you want to hear more, then go ahead and subscribe in whatever podcasting app you're currently listening through. If you have yet to leave a review for the show, this is the only thing that I ask for listeners to do. This is a ton of free content that we put out for over seven years now. If it has helped you even a little bit, then I'm asking for five minutes of your time, probably less, honestly, a couple of minutes of your time. To go and leave a review in iTunes, this lets other engineers who are looking for good content that helps them find the show and decide to actually give it a listen. It helps me to make the show a little bit better. Thanks so much for listening. Thank you for leaving reviews. If you also would like to take this conversation further, we've established a community of engineers head over to developertea.com slash discord. This is a totally free community. People who are around 24-7, a lot of the time, and you can go and talk to other engineers who are in similar stage of career, similar stage of life. They have similar problems that you're facing and they can give you advice beyond what I'm giving you here. So go and check that out developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.