How OKRs can help you to understand the team’s capacity

And why we should be honest when looking at what they are showing us

And why we should be honest when looking at what they are showing us

In my last post, I’ve talked about some things that I’ve experienced using agile methodologies that aim to help teams to achieve their OKRs easily. In my text, I’ve written:

Somehow maybe it would be interesting to break things down to squad level. Let the team organize itself on how they will achieve that goal together. This CAN help in a big implementation issue using Scrum/Agile in our (Latin culture), that is not pointing fingers in problems that are affecting the team, mainly when team members are not delivering as expected.

I think that this issue is so important that I want to write an article about it.

One of the greatest advantages of working with OKRs is following, along the time, our performance. Without constant follow-up, the OKR methodology doesn’t make sense. This forces us to constantly be aware of how much we can deliver — and if we are on the right path.

For instance: imagine that your team, which has 4 developers, has to deliver 300 mobile app features within 3 months. Well, this would bring us to 25 features per week, along with 12 weeks. However, your team has 4 people that together deliver 16 features weekly, max.

In this case, what is the point in believing that this is an achievable goal when the team delivers 9 features less than expected every week? None, right? If you want to have 300 features delivered, it’s obvious that things will have to change and understand what needs to be made to, at least, put meaning in the OKR.

At this moment some questions need to be made. Are you going to hire more developers to raise feature delivers? Are you going to invest time understanding what are the bottlenecks in the current team? Anyway, what are the ACTIONS that you and the team will have to take to make this OKR viable?

Another example: imagine, that the same team is working with simultaneous OKRs. By the end of the first month of the quarter, you look at the results delivered and see that it is impossible to deliver both. Sometimes there’s no way: you will have to prioritize and choose one OKR that makes more sense according to the team’s capacity.

In my point of view working with OKRs is a synonym to make important decisions every week, forcing us to decide what would be made out of the results, whenever they are good or bad. After all, not only the OKRs need to be clear, strategic, and reachable. The ability to identify faulty points must exist and work along the whole process.

If at any moment nobody in the team will stop and be honest, pointing out that it won’t be possible and identifying the performance gaps, then the real use of OKR methodology will fall apart. It is important to make decisions according to the team’s capacity, understanding that it’s viable and what will need to be canceled or left to another moment.

In addition, it’s important that during weekly follow-up the math gets done. Transparently, understand how much your team delivers and compare the capacity with what OKRs needs. Starting from there, ask yourself how much that goal makes sense — if it’s possible to be achievable and how. Next week, do the math again, and so on. Believe me, that will make all difference along the way when the OKR deadline comes close.

And you, what techniques are you using to understand the team’s capacity while following OKR? Tell us in the comments and let’s talk about it.