Sprint management workflow custom rule prevents stories from transitioning

ALM Rally (Broadcom Agile Central)
, , , , , , , ,
1

We implemented a custom workflow rule in our sprint-mgmt module to enforce stricter state transitions for user stories. The rule validates that stories must have task completion >= 80% before moving to “Completed” state. However, since enabling this rule three days ago, team members report stories getting blocked during iteration close with validation errors.

The rule uses WSAPI queries to check task percentages:

if (story.ScheduleState === 'Completed' && story.Iteration) {
  let taskCompletion = story.Tasks.filter(t => t.State === 'Completed').length / story.Tasks.length;
  return taskCompletion >= 0.8;
}

Sprint velocity has dropped 25% because stories remain stuck in “In-Progress” despite being functionally complete. The validation fires even when manually updating stories through the UI. Is there a way to scope this rule to only trigger during automated state transitions, or exclude iteration boundary scenarios? Our sprint cadence is being severely impacted.

2

Comprehensive Solution for Sprint Workflow Rule

Your custom workflow rule needs refinement across all four focus areas to handle iteration scoping properly:

1. Custom Workflow Rules - Iteration Boundary Detection

Modify your rule to detect iteration close scenarios by checking if the story is being moved between iterations:

if (story.ScheduleState === 'Completed' && story.Iteration) {
  if (story._PreviousValues && story._PreviousValues.Iteration !== story.Iteration) {
    return true; // Allow transition during iteration moves
  }
  // Continue with validation for normal transitions
}

2. WSAPI Queries - Robust Task Calculation

Your task completion logic needs defensive checks:

let tasks = story.Tasks || [];
if (tasks.length === 0) return true; // No tasks = allow transition
let completed = tasks.filter(t => t.State === 'Completed').length;
let taskCompletion = completed / tasks.length;
return taskCompletion >= 0.8;

3. State Transitions - Conditional Validation

Add logic to differentiate between user-initiated and system-initiated transitions. Check if the update includes a “_SystemUpdate” flag or if multiple state changes occur simultaneously (typical of bulk iteration operations). For user-driven transitions during active sprints, enforce the 80% rule strictly. For system operations during sprint close, allow more flexibility.

4. Iteration Scoping - Time-Based Bypass

Implement a 48-hour grace period before iteration end:

let iterationEnd = new Date(story.Iteration.EndDate);
let now = new Date();
let hoursUntilEnd = (iterationEnd - now) / (1000 * 60 * 60);
if (hoursUntilEnd <= 48) return true; // Bypass validation near sprint end

Implementation Strategy:

Combine these approaches into a single rule that checks conditions in priority order: (1) iteration boundary detection first, (2) time-based bypass second, (3) task validation last. This ensures your compliance requirements are met during normal sprint work while preventing workflow blockages during iteration transitions.

Test the updated rule in a sandbox workspace first, focusing on sprint close scenarios. Monitor validation errors in the first sprint cycle and adjust the 48-hour window if needed. Your sprint velocity should normalize once stories can transition freely during iteration boundaries while maintaining validation rigor during active development.

The key insight: workflow rules should understand sprint lifecycle phases, not just individual story state. By adding iteration context awareness, your rule becomes sprint-cadence friendly while preserving the audit controls your compliance team requires.

3

Thanks for the suggestions. The warning approach is interesting, but our compliance team requires hard validation for audit purposes. I’m more interested in the iteration boundary check idea. How would I structure the WSAPI query to detect if we’re in an iteration close scenario? Should I compare current timestamp against Iteration.EndDate?

4

Yes, timestamp comparison works. You’ll want to check if the current date is within 24 hours of Iteration.EndDate. But there’s a cleaner approach-check if the story is being moved TO a different iteration simultaneously with the state change. If story.Iteration is changing in the same update, skip your 80% validation. That specifically targets iteration rollover scenarios while maintaining your rule during normal sprint work.

5

We hit something similar last quarter. Custom Rules in rally-sa can’t distinguish between user-initiated vs system-initiated state changes. You might need to add explicit iteration boundary checks in your rule logic. Check if the story’s Iteration.EndDate is within the current date range before applying the 80% threshold. That way, stories can transition freely during sprint close.

6

Have you considered using a warning instead of a hard block? We modified our validation rules to log warnings to a custom field rather than preventing the transition entirely. This gives visibility without breaking the sprint flow. You could set a “ValidationWarning” field that flags stories for review in the next planning session, but still allows iteration close to proceed.

7

I’d also recommend reviewing your task completion calculation. Dividing by total task count can throw errors if Tasks.length is zero. Add a null check and default to allowing the transition if no tasks exist. We’ve seen stories without tasks get permanently blocked by similar validation logic.