Alternatives To Adding And Removing Stories Mid-Sprint
The Challenges of Changing Requirements
Adding, removing, or altering user stories during an ongoing sprint can disrupt team velocity, reduce efficiency, and make accurate planning and estimation difficult. However, changing business needs or shifting product priorities often necessitate changes in scope or requirements mid-sprint.
When new requests arrive, the product owner must decide whether to incorporate them immediately or defer them until the next sprint planning session. Amending the sprint backlog interrupts the team’s momentum and established commitments. On the other hand, delaying urgent user stories slows value delivery and responsiveness.
Likewise, removing low priority stories late damages trust in the product backlog and sprint forecast. The development team risks under-delivering on the forecasted scope. However, strictly locking down scope reduces agility in adapting to evolving information and realities.
Finding alternatives to changing stories mid-sprint balances reactiveness and intentionality. The following practices aim to thoroughly vet and tightly scope sprints while retaining flexibility to meet emergent customer and business needs.
Prioritizing New User Stories
Before adding new stories, critically evaluate their business value and alignment with current goals. Reset expectations with stakeholders if deprioritizing lower value items originally slated for the sprint.
Analyze any dependencies the new stories have on existing work and factor these risks into prioritization decisions. Also carefully consider new stories’ scope and effort estimates before scheduling them mid-sprint.
When possible, identify redundant stories delivering similar or overlapping value and consolidate efforts there. If adding new items, first remove any obsolete, gold-plated or nonessential stories of equivalent effort from the sprint.
Urgency vs. Importance
Categorize incoming requests based on their urgency and importance. Urgent, critical user stories demand action within 48 hours. Important but non-urgent stories align with strategic goals but have a longer timeframe for delivery.
Unimportant, non-urgent stories offer little differentiated value and lowest priority. They become candidates to descope if higher priority work enters mid-sprint. Distinguish superficial urgency from underlying importance when rebalancing the sprint workload and determining what can wait until next time.
Cost of Delay
Calculate the short and long-term costs of not immediately addressing new stories or changes in priority. Estimate lost revenue, missed opportunities, and compounding risks from delays using data-driven financial forecasting models.
Quantify and communicate costs and tradeoff for deprioritizing existing work to make room for new items. However, balance urgency with sustainable pace,Load new items only when capacity allows absorption without overburdening the team or jeopardizing sprint goals.
Watch Bench Strength
Monitor team bandwidth before injecting additional work mid-sprint. Ideally existing stories and new requests should not exceed 90% utilization per role given historical velocities and estimated capacities.
Look at skills match-up between new items and current staffing rather than overall headcount. Scope in new requests only when the bench has appropriate skills and availability to take on the work without oversubscribing staff.
Splitting User Stories
Breaking down large user stories into smaller, independent pieces achieves greater granularity in scoping, tracking and delivery. Component stories can have separate priorities and release schedules.
Vertical Slicing
With vertical slicing, divide a story along technical layers like user interface, business logic and database access. Teams deliver thin vertical slices that traverse the system architecture and enable incremental demonstrations of progress.
Prioritize slices representing critical workflows or foundational infrastructure over less essential ones. Describe each vertical slice as a separate story for granular tracking, estimation and work allocation even if relying on the same codebase.
Horizontal Slicing
For horizontal slicing, decompose stories into frontend and backend components. For example, separate the data model, business logic and REST API endpoints from the user interface views and client side JavaScript application.
Delivery horizontal slices in small increments working across the layers. Coordinate cross-component dependencies between frontend and backend sub-teams to synchronize deliverables into cohesive product increments.
Spike Stories
Complex stories often benefit from dedicated investigative spikes before full implementation. Create lightweight spike stories for proof-of-concepts, risk identification, analysis, discovery and prototyping activies.
Timebox spikes to convey scope expectations. Rotate paired subgroups of the team through different spike initiatives to build knowledge more broadly across the organization.
Pushing Stories to the Next Sprint
When new priority initiatives bump lower ranking stories from the sprint, defer descoped stories to the next iteration rather than abandoning them altogether.
Communicate clearly about pushed stories to set expectations both within the team and with stakeholders. Reset carrryover work estimates, priorities and acceptance criteria during next sprint planning.
Manage Morale
Frequently shelving near complete items damages morale, incentives and velocity trends. To avoid waste and rework, freeze code check-ins on pushed stories several days before sprint end.
Test and integrate deferred work into the mainline for easy resumption next iteration. Brief the team on why descoping choices were made and how pushed work enables better overall outcomes.
Get Consensus
Describe newly inserted stories and low priority descoped candidates transparently when replanning mid-sprint. Solicit team member perspectives on alternative options and tradeoff decisions.
Strive for consensus on changes, but focus on factual impacts to scope, timelines, risks and predictions rather than opinions. Provide the rationale guiding choices to help justify outcomes.
Set Expectations
Reduce uncertainty by distinguishing firm sprint commitments from contingency stories preassigned stretch targets. Communicate probabilities of achieving stretch work during planning for downstream predictability.
If reducing overall scope midstream, notify affected stakeholders immediately and explain how deferred functionality will ultimately improve the product and customer outcomes.
When to Break the Rules
Fixed sprint lengths and isolated teams buffer development cadences from interference and churn. However rules restricting change likewise decrease responsiveness and agility when priorities shift.
Find balance between structure and flexibility based on contextual variability factors. Case-by-case deviations that circumvent change restrictions may prove necessary in narrowly defined situations.
Reduce Batch Sizes
Large initiatives turn minor course corrections into major upheavals. Divide big bang efforts into smaller batches through continuous delivery workflows. Streamline release processes so change volumes and cycles synchronize with business dynamics rather than arbitrary timeboxes.
Small, incremental capability injections adjust trajectories gradually without piling incomplete work. Continual prioritization refinement also prevents distant due dates and abstract requirements from solidifying prematurely.
Custom Fit Frequency
Fixed sprint durations help reliably forecast team throughput but reduce responsiveness to shifts in priority. Consider tailoring iteration intervals and alignment points across squads according to distinct rhythms.
For example, tune customer-facing product teams to weekly intervals for tighter feedback loops while persisting longer cycles for infrastructure groups. Sync seams between streams for integration and dependency management.
Shelve WIP, Not Progress
Freezing mid-sprint work risks losing continuity, context switching and duplicated startup effort when resuming later. When deprioritizing, analyze tradeoffs between potential rework, lost opportunities and the cost of change.
For higher value stories with significant existing progress, shelf just-in-time design or development may prove more wasteful than letting teams complete within current sprint capacity constraints before redirecting focus.
Set Aside Buffers
Build planning contingencies directly into sprint forecasts to minimize disruption from reasonable fluctuation in scope or priority changes. Allocate variable capacity reserves for likely disruptions.
Timebox contingency allowance for flexibility rather than leaving buffers open-ended. Limit use of buffers to transparently controlled exceptions based on defined approval criteria rather than hiding loose commitments.
