How do you use a cycle time scatterplot to set an SLE?
This tests your ability to use data, not feelings, to manage stakeholder expectations. Explain the scatterplot, identify the outlier, calculate the 85th percentile, and propose a data-backed Service Level Expectation (SLE).
WHAT THIS TESTS: This tests your ability to move beyond simple averages and use statistical concepts like percentiles to manage stakeholder expectations. It's a test of data-driven communication. The interviewer wants to see if you can take a raw metric (cycle time), visualize it (scatterplot), and use it to create a predictable forecast (an SLE based on the 85th percentile) that a business stakeholder can understand and trust. It's about shifting the conversation from "Why was this one story late?" to "How can we be predictable X% of the time?".
A GOOD ANSWER COVERS: A great answer has four parts. First, explain the cycle time scatterplot: each dot is a completed work item, the y-axis is its cycle time in days, and the x-axis is the completion date. Second, use the plot to visually frame the problem: point out the cluster of dots at 2-3 days and the single outlier at 15 days. This validates the stakeholder's concern but also shows it's an exception, not the norm. Third, introduce percentile lines. Calculate the 85th percentile and explain what it means in plain English: "85% of our work is finished in X days or less." For example, if the 85th percentile is 8 days, you can propose an SLE of 8 days. This means for any 100 items we start, we expect 85 of them to be done within 8 days. Fourth, propose next steps: use the new SLE for forecasting and commit to investigating the root cause of the 15-day outlier to see if systemic issues can be prevented.
COMMON WRONG ANSWERS: A major red flag is getting defensive or anecdotal. Don't blame the specific story ("That one was really complex") or the team ("We had someone on vacation") without first grounding the conversation in the data. Another weak answer is using the average or median. Averages are easily skewed by outliers (like the 15-day story) and don't provide a probabilistic forecast. Saying "our average is 4 days" is less useful and less confidence-inspiring than "85% of our stories finish in 8 days or less." Finally, failing to propose a concrete SLE is a missed opportunity to show leadership and a focus on business outcomes.
LIKELY FOLLOW-UPS: "How would you get the team to buy into this SLE?" (Answer: Frame it as a tool for protection and predictability, not a deadline; involve them in setting it). "What if the stakeholder says the 85th percentile of 8 days is too long?" (Answer: This opens a conversation about trade-offs. We can reduce the SLE by reducing Work In Progress (WIP), swarming on work, or slicing stories smaller. The data shows what's currently possible; changing the outcome requires changing the system). "What tools do you use to generate these charts?" (Jira with plugins like ActionableAgile, custom scripts, or even a simple spreadsheet).
ONE CONCRETE EXAMPLE: "I'd show the stakeholder the scatterplot with 100 recent stories. They'd see 95 dots clustered below the 5-day line and one dot way up at 15 days. I'd draw a line at the 85th percentile, which might be at 8 days. I'd say, 'You're right to notice that 15-day story; it was an outlier. This chart shows that 85% of our work finishes in 8 days or less. Let's agree on an 8-day SLE. This means we can be confident that for every 10 items we start, 8 or 9 will be done within that window. We'll also investigate the 15-day item to learn from it.'"
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.