Assume I have 1-3 Objectives (OKRs), and 1 to 3 Key Results (KR) per Objective.

Today here’s my workflow:

  • I work with my team during grooming sessions to get a high level cost to achieve the KR. I do this by breaking the KR into l stories and T-shirt sizing those stories.
  • I prioritize the Objectives and KRs by assessing impact vs complexity. I prioritize 1) low-hanging fruits and 2) high impact and complex KRs (typically with the longest poll) that require de-risking and an early start.
  • Once I understand priorities, I overlay the KRs with the complexity (i.e. man-months) and I build a Gantt Chart with each KR 1 (or more) work streams.
  • I use the complexity numbers to identify when can a work stream start and what can go in parallel.

The problem is that the above assumes that each engineer on the team is fungible and can move anywhere up and down the stack. I worked in a team like that and the above strategy almost always worked.

I’m my current team, engineers aren’t fungible, you have the Front End, Back End, and Data Engineers. So it feels I need to build 3 Gantt Charts (one per Engineering focus area) and can only complete a work stream once the same work stream across all Gantt Charts complete.

Q1- This seems overly complex, how do managers do this effectively? Is there a better way? Should I continue following my original approach even though it’s not accurate?

  • 2
    And, you know, managing projects composed of different teams (which is essentially what's happening here), is fundamental to Project Management.
    – Gregory Currie
    Commented Oct 22, 2021 at 6:37
  • @GregoryCurrie when you put it like that… yes! I didn’t see it like that, but you are correct. I still don’t know the answer though but it’s something to think about.
    – Kam
    Commented Oct 22, 2021 at 6:41
  • Are you actually using OKRs, or are you renaming epics to "KR"s? What you describe sounds odd to me since I expect KRs to results expressed in relation to a metric and not specific items that can directly be broken down into stories.
    – Helena
    Commented Oct 24, 2021 at 15:34
  • How many teams and people are in your org?
    – Helena
    Commented Oct 24, 2021 at 15:39
  • @Helena KRs can be metrics but they can be business functionalities (which is in my case). For example an objective can be “achieve feature parity with system X” a KR can be “build the Y functionality”. So it really depends on the system. But in general KR will always be driven by one or more epics in the quarter. At least that’s how I track work on my team. Do you see any issues with this approach?
    – Kam
    Commented Oct 24, 2021 at 17:58

3 Answers 3



You're trying to build a Gantt chart based on a process that worked with a previous team, but clearly isn't viable with the current team. There are probably many reasons for this, and I'll enumerate some below, but I think the best approach for you would be to take a step back and assess the best process for planning with your current team.

One of the best ways to do that is to present your planning problem to the team, and ask them to help you develop the plan. While you are responsible for the plan itself, leveraging the people on your team to gather data and develop a functional process is often a useful approach.

Analysis and Recommendations

This question isn't tagged with any agile tags, but I still think that a key tenet of agile project management could help you. In your case, the problem seems to be that you are attempting to break down the work, and you are trying to decide how long various things will take. This is an anti-pattern even in traditional project management because:

  1. People aren't fungible resources, even when they're not over-specialized.
  2. What takes a given developer three days to accomplish may take another developer three weeks, so skill- or knowledge-based estimates aren't really fungible either.
  3. Complex work is rarely cleanly delineated along lines of specialization, especially in IT or knowledge work.
  4. Most work of any sizable complexity will require collaboration across areas of specialization or domain knowledge.

In short, you need more collaboration on your team in terms of both process and estimation. In comments, you give the example of front-end vs. back-end developers. My point isn't that these folks are interchangeable, or can do each other's jobs, but rather that they will need to collaborate in many areas such as design, testability, usability, and various other dimensions. Your planning should, at the very least, capture those areas of overlap and essential collaboration so that the whole team is thinking about those things when helping you to build the plan. Otherwise, you may end up with a critical path that lacks essential nodes, or estimates that don't take the overhead of interdisciplinary back-and-forth into account when planning.

As for the question of accuracy, in knowledge work it's practically a truism that any estimate not provided by the person doing the work is likely invalid. In other domains that's not always true, of course, but in IT you often run into problems when anyone other than the assigned resource provides the estimates. What you typically end up with then are management targets, not accurate estimates. If that's what's needed in your organization that's fine, but if you're actually looking to increase the accuracy of your estimation process then you need to involve the people doing the work when estimating.

By breaking the work down into milestones, you may be able to build your Gantt chart based on when the different work streams converge for a given project increment. In other words, given target date X for milestone Y, you can then build your dependency mappings and start-to-finish planning backwards from those dates and milestones. I won't say that this will be accurate to some arbitrary decimal place, but it will still give you a visualization tool that will help you determine whether a given work package is on-track or off-track.

  • Thank you for your answer. Maybe I wasn’t too clear. Let me try again. My team is the one that tshirt size the work and breaks it down into stories/tasks. The problem is that if I take the work stream size it might lead to inaccurate predications on delivery ETAs.
    – Kam
    Commented Oct 22, 2021 at 23:36
  • As an example. If I have 6 resources (4 Software Engineers and 2 Data Engineers) and 2 work streams with the cost of 3 man months each. I can in theory say that we can deliver both streams in 1 month. However, this would be an incorrect assumption if you realize that both streams require 2 Data Engineers each. Then the only solution would be to sequence the work.
    – Kam
    Commented Oct 22, 2021 at 23:39
  • @Kam Whether the work is parallel or sequenced isn't the point here. The integration points are. At some point, your parceled-out work needs to be integrated with the rest of the project, so use those integration points in your planning. If you or the team aren't accounting for the integration of the work, you end up with mythical man-month problems. Everyone needs to be thinking about how their work intersects and integrates, or you end up with a spaghetti bowl.
    – Todd A. Jacobs
    Commented Oct 22, 2021 at 23:53
  • Assume there’s no integration needed, both projects are orthogonal (I’m trying to simplify)
    – Kam
    Commented Oct 22, 2021 at 23:54

Meh ... "My front end engineers are front end specialists, they can’t possibly work on the data layer, that requires years of training they don’t have nor want to get."

As a thoroughly-seasoned software engineer, long before I became interested in project engineering and management, I can very comfortably say that all of your engineers can actually be much more flexible than you yet realize.

"Go ahead ... ask them."


Work should be assigned to cross-functional teams.

Your problem seems to be that you're trying to plan the project based on the individual contributions of your team members.

Instead, work should be assigned to, and estimated by, the team a large. When "T-shirt sizing" your stories, get the entire team to do it.

When you do this, you don't have a Front End Dev, a Back End Dev, and Data Engineer. You have a team that can handle all work. Overall things should smooth out - if there is, say, an abundance of back-end work, this will be addresses during the estimation. Plus, the non-back-end-developers can assist the back-end-developers, thus becoming more T-shaped.

  • Well the issue is that my team isn’t fungible. The FE folks can’t possibly work on the database.
    – Kam
    Commented Oct 22, 2021 at 16:28
  • You’re saying: if there’s an abundant of backend work the front end folks can assist so things smooth out (and the team estimations would be fairly accurate). I’m saying that front end folks can’t actually assist backend folks. So things won’t smooth out.
    – Kam
    Commented Oct 22, 2021 at 18:13
  • My front end engineers are front end specialists, they can’t possibly work on the data layer, that requires years of training they don’t have nor want to get.
    – Kam
    Commented Oct 22, 2021 at 18:16
  • I’m not going to argue because I used to work at big tech firms and what you are saying is the norm. In this case, can you assume that what I’m saying is correct please. Front End and Data Engineering is very orthogonal at lease in this team and they won’t be able to make any meaningful contribution. It took my DEs 6 months to understand data concepts, it not that simple. My question really becomes in this situation: should I treat Front End and Backend Engineering as fungible and 1 team from planning perspective and follow your strategy and treat data engineering as a separate team?
    – Kam
    Commented Oct 22, 2021 at 18:24
  • Let us continue this discussion in chat.
    – Sarov
    Commented Oct 22, 2021 at 18:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.