Uplevel's 2-Week Sliding Calculation Window

Balancing the tradeoffs between leveraging the latest information and maintaining integrity in reporting.

Data from your source systems (JIRA/Git/Calendar/Slack/etc.) is fluid.

While a JIRA issue may have been classified as a "story" at one point in time, it might later get reclassified to a "bug". Issues can move between epics, PR's can have their descriptions updated, and past calendar events can be removed. 

While some engineering leaders prefer to have their metrics always reflect the most up to date version of the data, other leaders value integrity and stability in historical reporting higher.

Neither is wrong, and Uplevel tries to strike a balance between the two approaches with it's 2-week sliding window. 

Here's how it works -- for the trailing 2 weeks from "today", Uplevel is constantly recalculating it's metrics based on the latest information. For all dates more than 2 weeks in the past, Uplevel "locks" in the state of the metric at that time, based on the information that was available at that time. 

Let's look at an example:

• Suppose an engineering leader is just getting started with Uplevel, and decides to undertake a big JIRA "cleanup" with their team. In the "cleanup" they correct how they were historically  populating a custom field to match a new working pattern.
• The next day, the engineering leader comes to Uplevel to see how their time allocation metric is reflecting the changes. What they will find is that when selecting dates within 2 weeks of "today", all of their JIRA updates will match the cleanup that was undertaken in JIRA. However, when selecting dates more than 2 weeks in the past, none of the JIRA changes will be reflected.

The benefit of this, is that if the engineering leader is later asked to reproduce the allocation numbers for last quarter, they'll be able to do so easily. If Uplevel were always using the most up to date information, their past analysis may not be reproducible.