I’ve worked in many environments over the years, and it seems like one constant in IT is that teams always seem be behind on projects or overworked. Teams are scrambling to meet deadlines, don’t have enough time to do things the right way, and amass a bunch of technical debt in the effort to meet a date, and then dream about what it would be like to address that technical debt while they move onto the next project that will inevitably be behind.
How does this keep happening? I’m guessing that most of us don’t work for slave drivers that ruthlessly pile work on us (if you work in an environment like that, I’m sorry).
I’d like to think that most of us work for good people. The people that we work for look bad when we’re behind, and it’s hard for them to go to their bosses and have to explain why the teams underneath them couldn’t hit a deadline.
So how does this happen? And how much control do we have over it? I would argue that it’s mostly on us as teams and leaders of teams. Here’s what I’m doing about it.
Defining normal
Your team gets to define what is a normal pace for your team. This often seems very arbitrary.
Let’s say that you’re on a project where you need to work 60 hour weeks to meet a deadline. Clearly if you’re working 60 hour weeks, you’re behind. In this situation, everyone settled on 60 hour weeks as “normal” for this team on this project. Given that you’re behind, it would be beneficial for the completion of the project if you worked 100 hours a week, but that’s outside of the normal that you’ve defined. So while the project feels out of control, everyone settled on some form of equilibrium.
I realize that I’m over-simplifying things a bit. If someone imposed a deadline on you, or you committed to something and drastically underestimated, maybe you feel stuck in this situation. Or maybe you aren’t pushing back enough or doing your part to define normal.
Most teams have long backlogs, and inevitably there will be pressure (malicious or not) to add more work to the schedule. You get to control when you say yes and when you push back. This is how you settle on “normal”, and it depends mostly on how the team responds to requests.
Let’s look at this another way. Let’s say that your team works 40 hour weeks and no one is overworked, yet you complain that you don’t have time to address technical debt. You give reasons for this like “management won’t let us” or “the business won’t let us”. But if you’re an agile team, isn’t your team doing the estimating? Don’t you have input on how much you commit to each sprint? Given that you’re not working 60 hour weeks, it seems like people are being reasonable with work/life balance.
Once again, you get to define normal. If you can complete 100 story points in a sprint and you want to use 10% of your capacity for technical debt, then for the next sprint just tell the business they have 90 story points to work with. If someone questions you, you answer that you need to keep up with technical debt in order to continue to move at the speed that they want you to move at. If you have deadlines that won’t allow that, when you get to the point where you define the next deadline, take things like technical debt into account.
Use the right data to improve your estimates
I find that many teams don’t track data to help them get better as estimating, or they track the wrong metrics. We all know that estimating is hard, but planning is a simple data analytics problem, and it’s not even that difficult.
If you wanted, you could call me up and I could come in and estimate your project for you. Chances are it wouldn’t be a very good estimate compared to what you could come up with. Obviously, that’s because you would be drawing on past experience to determine what will happen in the future. So why don’t we do more to learn from the past?
A lot happens during a sprint, and these things can be tracked. Please understand that I am talking about team-level metrics, not individual metrics or anything that would be used to compare teams. Here are some things that you can track:
- Team velocity for the sprint
- Cycle time
- How much work was added to the sprint after it started
- How much work was removed from the sprint after it started
- How much work carried over to the next sprint because it wasn’t complete
- How much work that was included in a sprint was already partially done because it carried over from the last sprint
- How much production support came up during the sprint
- How many developer days you have in each sprint (taking into account PTO, holidays, etc.)
- Unexpected days off during a sprint (e.g. people getting sick, emergencies, etc.)
- How much work in the sprint was due to bugs that would found during the sprint
- How many story points ended up in an epic when it was complete (compared with the number you thought it would have when you started)
- What areas of the system tends to have the most defects
- How many bugs are found in production vs. before production
- For a given project (or type of project), how much work ended up getting added to the scope throughout the course of the project, and why
I could probably keep going. Tracking things like this tell me things about my project. You can estimate all of these granular things and use those guesses to make better estimates about larger things. These aren’t things that need to be shared with anyone outside your team. These are things that you use to get better.
I find that many teams track very little data about their project. Then when they have to give an estimate for a project, the odds of them guessing wrong are a lot higher, and the consequences are difficult.
Having empirical data also gives you a leg to stand on when someone questions your estimate. If someone questions why you think something will take so long and you can respond with, “I know this seems long, but we’ve done the same kind of thing 3 times before, and this is how long it took those times,” that’s a very compelling argument. Because if you get into an argument over whether your estimate is correct or the boss’ idea in his head is correct, the boss often wins unless you have data to back your estimates up, and data is really hard to argue with.
We are inherently overly optimistic
We all want to succeed, we all want to get projects finished early. We all want to please our bosses, stakeholders, customers, and users. But most people have a tendency to be overly optimistic when it comes to estimating.
Developers are often really bad at this. I can say that because I’ve been very guilty of this. Some of you reading this may have worked with me and are chuckling right now. I promise, I’ve gotten better.
Developers often estimate based on the rainbows and unicorns scenario where they don’t hit any roadblocks, the requirements are bulletproof, they don’t get interrupted by production support, and the code is easier to write than expected. In reality, some or all of things things don’t work out. You don’t know which thing will go wrong, but something usually does, so we need to start including that in estimates.
Our feelings are fickle, so we need to resist the urge to give an estimate that will make our boss smile. What will make them smile even more is having a project completed on time without having the shuffle their schedule because you couldn’t get your part of the project done.
Stop counting hours
Our team has completely stopped estimating anything and hours and switched completely to story points. This probably deserves a blog post of it’s own.
I estimated in hours for years. For awhile I thought that story points were only for situations where you had very little information about a project and you needed to estimate it. Now I think that we’re pretty much always in a situation where we don’t have enough information to estimate in hours.
Story points are nothing more than a relative scale where work is estimated relative to other work, taking into account complexity, uncertainty, risk, scope, and effort. As a result, crazy things are possible. For example, our team has estimated 75 stories in 30 minutes. Many of these stories had nothing more than a title. We had no idea how many hours those would take, but we had a pretty decent guess of whether something was harder than something else.
Have you ever been in a meeting where someone in a leadership role (manager, tech lead, project manager, etc.) was arguing with a developer about how many hours a feature would take to develop? With story points, there is no argument. What difference does it make if a developer thinks something is 5 story points vs. 3 story points? It’s just an arbitrary number that has no effect on how long the actual work (done right) is going to take in the end.
Hour estimation leads to developers making bad decisions. For example, a story is estimated at 10 hours, and as soon as a developer has spent 10 hours on the ticket, they feel like their time is up, and they start cutting as many corners as they can in order to get the work “done”. If you use story points, there is no artificial hour limit to distract people from doing the right thing.
Estimating in hours also encourages project managers to try and account for how every hour of the day is being spent. This often leads to measuring developers against each other (or perception that that could happen). Inevitably someone (with good intentions maybe) starts tracking actual hours vs. estimated hours to get better as estimating, but this encourages developers to cut corners even more so that their personal numbers look better.
I really don’t care about any metrics that aren’t at the team level. On most teams that I’ve worked on, the best developers often get less done than others on the team because they spend more time helping others, planning, designing, and other things that don’t get added up to hours spend coding to complete a ticket. But those efforts do a lot to contribute to the success of the team!
Expect the unexpected
Unexpected things go wrong all the time. Production support happens, people get sick, team members leave the company, unexpected scope gets added to your project, users find high priority issues that they need fixed ASAP. And all of this stuff can be estimated and tracked.
Last year, we had 6 people leave our team, and we onboarded 6 new people. 2 developers were each out close to 3 months on long-term leave. I can sit there and make excuses for how these things shredded our timelines and made them unreasonable, or I can attempt to plan for them.
Look, people don’t stay in jobs as long as they did 30 years ago. This is not a surprise. If you have a team of 10, how many do you think will still be on the team a year from now? Probably not all 10. Do you have time in your schedule to absorb the loss of 2 team members and the onboarding of 2 new team members? Those things are a massive drain to your productivity, and they’re also very likely to happen.
On many projects, there are a lot of unknowns, and both you and your stakeholders are going to find many other things during the course of the project that absolutely have to be done. Once again, you can blame scope increases for being behind, or you can estimate how much you think it will happen and refine those estimates over time. This is not arbitrary schedule padding, this too can be an educated estimate based on actual historical data.
Continuous improvement
If you’re leading a team, you owe it to your team to find ways to get better at estimating. After all, their work/life balance is on the line, and your reputation as a leader is as well. I personally take this very seriously and am continually trying to find ways to get better at it. The success of your team may depend on it.