Back to Resources

Messy Jira? Meet Uplevel's Engineering Time Allocation Model

  • 5 Minute Read

Table of Contents

    Written By Lauren Lang

    Messy Jira - Featured ImageFor enterprise engineering organizations, thoughtful and prioritized time allocation is essential to delivering high-quality software on schedule. But it takes time and effort to track time and effort. The manual and labor-intensive methods used to allocate developers' work, like surveys and time tracking, are not only unsustainable, but also prone to inaccuracy and obsolete by the time the data is ready for review. 

    Uplevel solves that pain by ingesting data from your organization’s dev tools — calendar, project management platforms, CI/CD, code repositories, incident response, and chat — to surface a data-driven (read: faster and more accurate) estimation of time allocation. 

    But one of the concerns potential customers raise is whether or not an engineering intelligence platform is capable of handling their unique data. “Our Jira boards are a mess,” we’ve heard. “How can you pull any consistent data from them, let alone anything useful?” It’s a fair question. Many solutions do require clean data to provide usable allocation metrics, which means they are not the right choice for organizations who want to avoid a costly and time-consuming migration process to standardize workflows. 

    At Uplevel, we’ve developed a better alternative: an intelligent allocation model that can interpret product data as it is and use other signals across sources to enrich your organization’s allocation story. 

    How Our Time Allocation Model Works

    Uplevel has a novel approach to how we calculate time allocation. Where many companies claim they can provide allocation metrics without calendar integration, we find that calendar data is critical to estimate work activity with enough precision for enterprise organizations, especially when Jira is not able to tell the whole story. 

    Why? Because time allocation needs to be based on actual work time available, which varies widely across engineers, their teams, and entire company cultures. Here’s how it works:

    Allocation Model

    1. Visualize all work

    The first step is collecting daily availability and activity data from connected sources. This gives an automated and integrated look into the work done and the time available to do it.

    Time usage data is pulled from calendar data and illustrates how much time is available for work. If an engineer is out of office, attending meetings,or involved in lengthy Slack conversations, we assume that they are not available to perform development tasks. Work time, then, is what remains (after a lunch break that we also build in).

    Time usage data for engineering time allocation

    Activity data is the collection of signals from PM and code platforms like Jira and Github that indicate a) that the engineer is actively working and b) what issue or code they’re working on. This activity — like changing ticket status, adding descriptions or attachments, and committing, commenting on, reviewing, or merging code —provides important timestamps that form the basis of our allocation — even if the project data itself is incomplete or messy.

    Activity data for time allocation

    2. Match available working time to activity

    Now it’s time to apply the activity data to the available working time. We do this by looking at the distribution of activity (the space between timestamps) as a portion of the entire working day and applying that same percentage of available working time as the allocation.

    Allocate engineering activity to available working time

    For example, imagine the green bar above is 35% of the distribution. We’ve calculated that this person had 5.75 hours of available work time this day, so this stretch of time should get 35% of that 5.75 hours, or 2 hours, which is then allocated to the activity at the end of that block.

    What if there is no activity data available?

    In the event that there is no observed activity for the day but there is available working time, we can still make a rough estimate of work distribution based on the history for the type of action. For example, if there are issues with activity in the past week that are still open, Uplevel’s calculations will default to distributing working time according to the story points of those issues.

    Once the estimated time for each type of activity is calculated for each person and each day, we now have the basic data. Now we need to further enrich and categorize this data so that it can be viewed in higher groupings of work. 

    3. Apply rules engine "magic" to clean up and enrich data

    At Uplevel, our customers come to us with wide variability in how they track time and label work. Not only does every company have its own project naming conventions, but it’s not uncommon at the enterprise level for each team to have its own conventions as well. 

    Uplevel’s rules engine provides configurable data handling to account for different conventions in Jira and Azure DevOps projects. Each customer has its own set of rule definitions. Some are pre-seeded, such as Project, Epic, and Initiative, while others are custom fields and customer-defined aggregations. For example, if leaders want to categorize new feature work and differentiate it from KTLO, Uplevel can configure the rules engine so that issue titles like “refactoring” or “maintenance” fall into the KTLO bucket, but issues that include “feature,” “enhancement,” “new,” or “customer request” would be categorized as new value. 

    Uplevel time allocation rules engine data

    Running the data through the rules engine applies an allocation “bucket” to each block of work and its associated PR or ticket. From there, Uplevel can calculate and display aggregate results on the front end based on work time, activity, and allocation category.

    For example, as an engineering leader, you might first want to understand investment in new value, KTLO, bug fixes, support, research, etc. This helps you understand the types of investments you’re making… but that’s not enough. Maybe you also need to understand how much work is going into your top priorities. If you have five top-level initiatives that you expect the team to be spending time on, how much time are they actually investing in those projects? Is there lingering work from last quarter's initiatives that are continuing? Are you actually solving your most important problems? 

    We often find that every leader has different organizational context that they will want to apply to understanding time spent. One of the advantages of Uplevel’s time allocation model and rules engine is that it can allow them to set up their views to show that context. 

    Engineering Time Allocation for Empowered Decision-Making

    Accounting for the variability in issues, workflows, and priorities allows Uplevel to surface actionable insights from allocation data to solve common pain points: 

    • Capacity Planning: Rolling up individual work items into higher-level categories like feature development, maintenance, and failure demand work allows for holistic views of team activities. Engineering leaders can get a better sense of how much time engineers are spending on projects and make data-driven arguments for how to prioritize new product and feature requests based on capacity.

    • Organizational Reporting: Where sales and marketing can clearly report on data like conversions and revenue targets, engineering leaders often do not have easily attainable metrics to present to executives and stakeholders. Uplevel allocation data is easily presentable to explain at a high level “what engineering is doing.”

    • Cross-Organization Benchmarking: Uplevel enables comparisons across teams and even companies by standardizing data categorization. This allows leaders to see industry benchmarks for performance (and set their own internally), identify areas for improvements, and drive operational improvements.

    • Software Development Cost Capitalization: Bucketing work into R&D and non-R&D (KTLO and feature demand) categories provides a more accurate and easier way to create capitalization reports than asking engineers to self-report.

    More Allocation Improvements on the Horizon

    While Uplevel’s current time allocation model is already creating positive results for customers, there is always more work to be done. For example, our data science team is working on ways to create “smart allocation” models that leverage machine learning and natural language processing algorithms to infer which PRs should be linked to which epics and provide even more accurate allocation. We’ll be announcing these improvements as they form on our roadmap.

    Uplevel is the only engineering intelligence platform that combines technical performance, team performance, and allocation metrics with machine learning to provide engineering leaders with a holistic view of organizational effectiveness. Want to prove how Uplevel works with your team’s data? Schedule a demo today.