Work Management and Flow Problems

• 1: Blocked Work Sits Idle Instead of Being Picked Up
• 2: Completed Stories Don't Match What Was Needed
• 3: Stakeholders See Working Software Only at Release Time
• 4: Sprint Planning Is Dominated by Dependency Negotiation
• 5: Everything Started, Nothing Finished
• 6: Vendor Release Cycles Constrain the Team's Deployment Frequency
• 7: Services in the Same Portfolio Have Wildly Different Maturity Levels
• 8: Some Developers Are Overloaded While Others Wait for Work
• 9: Work Stalls Waiting for the Platform or Infrastructure Team
• 10: Work Items Take Days or Weeks to Complete

1 - Blocked Work Sits Idle Instead of Being Picked Up

What you are seeing

A developer opens a ticket on Monday and hits a blocker by Tuesday - a missing dependency, an unclear requirement, an area of the codebase they don’t understand well. They flag it in standup. The item sits in “in progress” for two more days while they work around the blocker or wait for it to resolve. Nobody picks it up.

The board shows items stuck in the same column for days. Blockers get noted but rarely acted on by other team members. At sprint review, several items are “almost done” but not finished - each stalled at a different blocker that a teammate could have resolved quickly.

Common causes

Push-Based Work Assignment

When work belongs to an assigned individual, nobody else feels authorized to touch it. Other team members see the blocked item but do not pick it up because it is “someone else’s story.” The assigned developer is expected to resolve their own blockers, even when a teammate could clear the issue in minutes. The team’s norm is individual ownership, so swarming - the highest-value response to a blocker - never happens.

Read more: Push-Based Work Assignment

Knowledge Silos

When only the assigned developer understands the relevant area of the codebase, other team members cannot help even when they want to. The blocker persists until the assigned person resolves it because nobody else has the context to take over. Swarming is not possible because the knowledge needed to continue the work lives in one person.

Read more: Knowledge Silos

How to narrow it down

1. Does the blocked item sit with the assigned developer rather than being picked up by someone else? If teammates see the blocker flagged in standup and do not act on it, the norm of individual ownership is preventing swarming. Start with Push-Based Work Assignment.
2. Could a teammate help if they had more context about that area of the codebase? If knowledge is too concentrated to allow handoff, silos are compounding the problem. Start with Knowledge Silos.

Ready to fix this? The most common cause is Push-Based Work Assignment. Start with its How to Fix It section for week-by-week steps.

Related Content

• Work Items Take Days or Weeks to Complete - Idle blocked work drives up cycle time
• Everything Started, Nothing Finished - Blocked items accumulate as excess WIP
• Team Membership Changes Constantly - Knowledge silos worsen when people leave
• Push-Based Work Assignment - Assignment model that prevents swarming
• Knowledge Silos - Concentrated knowledge that prevents handoff
• Limiting WIP - WIP limits make blocked items visible and prompt swarming

2 - Completed Stories Don't Match What Was Needed

What you are seeing

A developer finishes a story and moves it to done. The product owner reviews it and sends it back: “This isn’t quite what I meant.” The implementation is technically correct - it satisfies the acceptance criteria as written - but it misses the point of the work. The story re-enters the sprint as rework, consuming time that was not planned for.

This happens repeatedly with the same pattern: the developer built exactly what was described in the ticket, but the ticket did not capture the underlying need. Stories that seemed clearly defined come back with significant revisions. The team’s velocity looks reasonable but a meaningful fraction of that work is being done twice.

Common causes

Push-Based Work Assignment

When work is assigned rather than pulled, the developer receives a ticket without the context behind it. They were not in the conversation where the need was identified, the priority was established, or the trade-offs were discussed. They implement the ticket as written and deliver something that satisfies the description but not the intent.

In a pull system, developers engage with the backlog before picking up work. Refinement discussions and Three Amigos sessions happen with the people who will actually do the work, not with whoever happens to be assigned later. The developer who pulls a story understands why it is at the top of the backlog and what outcome it is trying to achieve.

Read more: Push-Based Work Assignment

Ambiguous Requirements

When acceptance criteria are written as checklists rather than as descriptions of user outcomes, they can be satisfied without delivering value. A story that specifies “add a confirmation dialog” can be implemented in a way that technically adds the dialog but makes it unusable. Requirements that do not express the user’s goal leave room for implementations that miss the point.

Read more: Work Decomposition

How to narrow it down

1. Did the developer have any interaction with the product owner or user before starting the story? If the developer received only a ticket with no conversation about context or intent, the assignment model is isolating them from the information they need. Start with Push-Based Work Assignment.
2. Are the acceptance criteria expressed as user outcomes or as implementation checklists? If criteria describe what to build rather than what the user should be able to do, the requirements do not encode intent. Start with Work Decomposition and look at how stories are written and refined.

Ready to fix this? The most common cause is Push-Based Work Assignment. Start with its How to Fix It section for week-by-week steps.

Related Content

• Everything Started, Nothing Finished - Rework adds unplanned items that inflate WIP
• Work Items Take Days or Weeks to Complete - Rework loops extend cycle time
• Push-Based Work Assignment - Assignment without context leads to intent mismatch
• Work Decomposition - Breaking work into slices with clear, outcome-focused acceptance criteria
• Working Agreements - Team norms for refinement and Three Amigos sessions

3 - Stakeholders See Working Software Only at Release Time

What you are seeing

Stakeholders do not see working software until a feature is finished. The team works for six weeks on a new feature, demonstrates it at the sprint review, and the response is: “This is good, but what we actually needed was slightly different. Can we change the navigation so it does X? And actually, we do not need this section at all.” Six weeks of work needs significant rethinking. The changes are scoped as follow-on work for the next planning cycle.

The problem is not that stakeholders gave bad requirements. It is that requirements look different when demonstrated as working software rather than described in user stories. Stakeholders genuinely did not know what they wanted until they saw what they said they wanted. This is normal and expected. The system that would make this feedback cheap - frequent demonstrations of small working increments - is not in place.

When stakeholder feedback arrives months after decisions, course corrections are expensive. Architecture that needs to change has been built on top of for months. The initial decisions have become load-bearing walls. Rework is disproportionate to the insight that triggered it.

Common causes

Monolithic work items

Large work items are not demonstrable until they are complete. A feature that takes six weeks cannot be shown incrementally because it is not useful in partial form. Stakeholders see nothing for six weeks and then see everything at once.

Small vertical slices can be demonstrated as soon as they are done - sometimes multiple times per week. Each slice is a unit of working, demonstrable software that stakeholders can evaluate and respond to while the team is still in the context of that work.

Read more: Monolithic work items

Horizontal slicing

When work is organized by technical layer, nothing is demonstrable until all layers are complete. An API layer with no UI and a UI component that calls no API are both invisible to stakeholders. The feature exists in pieces that stakeholders cannot evaluate individually.

Vertical slices deliver thin but complete functionality that stakeholders can actually use. Each slice has a visible outcome rather than a technical contribution to a future visible outcome.

Read more: Horizontal slicing

Undone work

When the definition of “done” does not include deployed and available for stakeholder review, work piles up as “done but not shown.” The sprint review demonstrates a batch of completed work rather than continuously integrated increments. The delay between completion and review is the source of the feedback lag.

When done means deployed - and the team can demonstrate software in a production-like environment at any sprint review - the feedback loop tightens to the sprint cadence rather than the release cadence.

Read more: Undone work

Deadline-driven development

When delivery is organized around fixed dates rather than continuous value delivery, stakeholder checkpoints are scheduled at release boundaries. The mid-quarter check-in is a status update, not a demonstration of working software. Stakeholders’ ability to redirect the team’s work is limited to the brief window around each release.

Read more: Deadline-driven development

How to narrow it down

1. Can the team demonstrate working software every sprint, not just at release? If demos require a release, work is batched too long. Start with Undone work.
2. Do stories regularly take more than one sprint to complete? If features are too large to show incrementally, start with Monolithic work items.
3. Are stories organized by technical layer? If the UI team and the API team must both finish before anything can be demonstrated, start with Horizontal slicing.

Ready to fix this? The most common cause is Monolithic work items. Start with its How to Fix It section for week-by-week steps.

4 - Sprint Planning Is Dominated by Dependency Negotiation

What you are seeing

Sprint planning takes hours. Half the time is spent mapping dependencies: Team A cannot start story X until Team B delivers API Y. Team B cannot deliver that until Team C finishes infrastructure work Z. The board fills with items in “blocked” status before the sprint begins. Developers spend Monday through Wednesday waiting for upstream deliverables and then rush everything on Thursday and Friday.

The dependency graph is not stable. It changes every sprint as new work surfaces new cross-team requirements. Planning sessions produce a list of items the team hopes to complete, contingent on factors outside their control. Commitments are made with invisible asterisks. When something slips - and something always slips - the team negotiates whether the miss was their fault or the fault of a dependency.

The structural problem is that teams are organized around technical components or layers rather than around end-to-end capabilities. A feature that delivers value to a user requires work from three teams because no single team owns the full stack for that capability. The teams are coupled by the feature, even if the architecture nominally separates them.

Common causes

Tightly coupled monolith

When services or components are tightly coupled, changes to one require coordinated changes in others. A change to the data model requires the API team to update their queries, which requires the frontend team to update their calls. Teams working on different parts of a tightly coupled system cannot proceed independently because the code does not allow it.

Decomposed systems with stable interfaces allow teams to work against contracts rather than against each other’s code. When an interface is stable, the consuming team can proceed without waiting for the providing team to finish. The items that spent a sprint sitting in “blocked” status start moving again because the code no longer requires the other team to act first.

Read more: Tightly coupled monolith

Distributed monolith

Services that are nominally independent but require coordinated deployment create the same dependency patterns as a monolith. Teams that own different services in a distributed monolith cannot ship independently. Every feature delivery is a joint operation involving multiple teams whose services must change and deploy together.

Services that are genuinely independent can be changed, tested, and deployed without coordination. True service independence is a prerequisite for team independence. Sprint planning stops being a dependency negotiation session when each team’s services can ship without waiting on another team’s deployment schedule.

Read more: Distributed monolith

Horizontal slicing

When teams are organized by technical layer - front end, back end, database - every user-facing feature requires coordination across all teams. The frontend team needs the API before they can build the UI. The API team needs the database schema before they can write the queries. No team can deliver a complete feature independently.

Organizing teams around vertical slices of capability - a team that owns the full stack for a specific domain - eliminates most cross-team dependencies. The team that owns the feature can deliver it without waiting on other teams.

Read more: Horizontal slicing

Monolithic work items

Large work items have more opportunities to intersect with other teams’ work. A story that takes one week and touches the data layer, the API layer, and the UI layer requires coordination with three teams at three different times. Smaller items scoped to a single layer or component can often be completed within one team without external dependencies.

Decomposing large items into smaller, more self-contained pieces reduces the surface area of cross-team interaction. Even when teams remain organized by layer, smaller items spend less time in blocked states.

Read more: Monolithic work items

How to narrow it down

1. Does changing one team’s service require changing another team’s service? If interface changes cascade across teams, the services are coupled. Start with Tightly coupled monolith.
2. Must multiple services deploy simultaneously to deliver a feature? If services cannot be deployed independently, the architecture is the constraint. Start with Distributed monolith.
3. Does each team own only one technical layer? If no team can deliver end-to-end functionality, the organizational structure creates dependencies. Start with Horizontal slicing.
4. Are work items frequently blocked waiting on another team’s deliverable? If items spend more time blocked than in progress, decompose items to reduce cross-team surface area. Start with Monolithic work items.

Ready to fix this? The most common cause is Tightly coupled monolith. Start with its How to Fix It section for week-by-week steps.

5 - Everything Started, Nothing Finished

What you are seeing

Open the team’s board on any given day. Count the items in progress. Count the team members. If the first number is significantly higher than the second, the team has a WIP problem. Every developer is working on a different story. Eight items in progress, zero done. Nothing gets the focused attention needed to finish.

At the end of the sprint, there is a scramble to close anything. Stories that were “almost done” for days finally get pushed through. Cycle time is long and unpredictable. The team is busy all the time but finishes very little.

Common causes

Push-Based Work Assignment

When managers assign work to individuals rather than letting the team pull from a prioritized backlog, each person ends up with their own queue of assigned items. WIP grows because work is distributed across individuals rather than flowing through the team. Nobody swarms on blocked items because everyone is busy with “their” assigned work.

Read more: Push-Based Work Assignment

Horizontal Slicing

When work is split by technical layer (“build the database schema,” “build the API,” “build the UI”), each layer must be completed before anything is deployable. Multiple developers work on different layers of the same feature simultaneously, all “in progress,” none independently done. WIP is high because the decomposition prevents any single item from reaching completion quickly.

Read more: Horizontal Slicing

Unbounded WIP

When the team has no explicit constraint on how many items can be in progress simultaneously, there is nothing to prevent WIP from growing. Developers start new work whenever they are blocked, waiting for review, or between tasks. Without a limit, the natural tendency is to stay busy by starting things rather than finishing them.

Read more: Unbounded WIP

How to narrow it down

1. Does each developer have their own assigned backlog of work? If yes, the assignment model prevents swarming and drives individual queues. Start with Push-Based Work Assignment.
2. Are work items split by technical layer rather than by user-visible behavior? If yes, items cannot be completed independently. Start with Horizontal Slicing.
3. Is there any explicit limit on how many items can be in progress at once? If no, the team has no mechanism to stop starting and start finishing. Start with Unbounded WIP.

Ready to fix this? The most common cause is Push-Based Work Assignment. Start with its How to Fix It section for week-by-week steps.

Related Content

• Work Items Take Days or Weeks to Complete - High WIP directly increases cycle time
• Pull Requests Sit for Days Waiting for Review - Review queues are a common source of excess WIP
• Unbounded WIP - No limits on work in progress
• Limiting WIP - Setting and enforcing WIP limits
• Work in Progress - Measuring and tracking WIP over time

6 - Vendor Release Cycles Constrain the Team's Deployment Frequency

What you are seeing

The team is ready to deploy. But the upstream payment provider releases their API once a quarter and the new version the team depends on is not live yet. Or the downstream enterprise consumer the team integrates with requires 30 days advance notice before any API change goes live. The team’s own deployment readiness is irrelevant - external constraints set the schedule.

The team adapts by aligning their release cadence with their most constraining external dependency. If one vendor deploys quarterly, the team deploys quarterly. Every advance the team makes in internal deployment speed is nullified by the external constraint. The most sophisticated internal pipeline in the world still produces a team that ships four times per year.

Some external constraints are genuinely fixed. A payment network’s settlement schedule, regulatory reporting requirements, hardware firmware update cycles - these cannot be accelerated. But many “external” constraints turn out to be negotiable, workaroundable through abstraction, or simply assumed to be fixed without ever being tested.

Common causes

Tightly coupled monolith

When the team’s system is tightly coupled to third-party systems at the technical level, any change to either side requires coordinated deployment. The integration code is tightly bound to specific vendor API versions, specific response shapes, specific timing assumptions. Wrapping third-party integrations in adapter layers creates the abstraction needed to deploy the team’s side independently.

An adapter that isolates the team’s code from vendor-specific details can handle multiple API versions simultaneously. The team can deploy their adapter update, leaving the old vendor path active until the vendor’s new version is available, then switch.

Read more: Tightly coupled monolith

Distributed monolith

When the team’s services must be deployed in coordination with other systems - whether internal or external - the coupling forces joint releases. Each deployment event becomes a multi-party coordination exercise. The team cannot ship independently because their services are not actually independent.

Services that expose stable interfaces and handle both old and new protocol versions simultaneously can be deployed and upgraded without coordinating with consumers. That interface stability is what removes the external constraint: the team can ship on their own schedule because changing one side no longer requires the other side to change at the same time.

Read more: Distributed monolith

Missing deployment pipeline

Without a pipeline, there is no mechanism for gradual migrations - running old and new integration paths simultaneously during a transition period. Switching to a new vendor API requires deploying new code that breaks old behavior unless both paths are maintained in parallel.

A pipeline with feature flag support can activate the new vendor integration for a subset of traffic, validate it against real load, and then complete the migration when confidence is established. This decouples the team’s deployment from the vendor’s release schedule.

Read more: Missing deployment pipeline

How to narrow it down

1. Is the team’s code tightly bound to specific vendor API versions? If the integration cannot handle multiple vendor versions simultaneously, every vendor change requires a coordinated deployment. Start with Tightly coupled monolith.
2. Must the team coordinate deployment timing with external parties? If yes, the interfaces between systems do not support independent deployment. Start with Distributed monolith.
3. Can the team run old and new integration paths simultaneously? If switching to a new vendor version is a hard cutover, the pipeline does not support gradual migration. Start with Missing deployment pipeline.

Ready to fix this? The most common cause is Tightly coupled monolith. Start with its How to Fix It section for week-by-week steps.

7 - Services in the Same Portfolio Have Wildly Different Maturity Levels

What you are seeing

Some services have full pipelines, comprehensive test coverage, automated deployment, and monitoring dashboards. Others have no tests, no pipeline, and are deployed by copying files onto a server. Both sit in the same team’s portfolio. The team’s CD practices apply to the modern ones. The legacy ones exist outside them.

Improving the legacy services feels impossible to prioritize. They are not blocking any immediate feature work. The incidents they cause are infrequent enough to accept. Adding tests, setting up a pipeline, and improving the deployment process are multi-week investments with no immediate visible output. They compete for sprint capacity against features that have product owners and deadlines.

The maturity gap widens over time. The modern services get more capable as the team’s CD practices improve. The legacy ones stay frozen. Eventually they represent a liability: they cannot benefit from any of the team’s improved practices, they are too risky to touch, and they handle increasingly critical functionality as other services are modernized around them.

Common causes

Missing deployment pipeline

Services without pipelines cannot participate in the team’s CD practices. The pipeline is the foundation on which automated testing, deployment automation, and observability build. A service with no pipeline is a service that will always require manual attention for every change.

Establishing a minimal viable pipeline for every service - even if it just runs existing tests and provides a deployment command - closes the gap between the modern services and the legacy ones. A service with even a basic pipeline can participate in the team’s practices and improve from there; a service with no pipeline cannot improve at all.

Read more: Missing deployment pipeline

Thin-spread teams

Teams spread across too many services and responsibilities cannot allocate the focused investment needed to bring lower-maturity services up to standard. Each sprint, the urgency of visible work displaces the sustained effort that improvement requires. Investment in a legacy service delivers no value for weeks before the improvement becomes visible.

Teams with appropriate scope relative to capacity can allocate improvement time in each sprint. A team that owns two services instead of six can invest in both. A team that owns six has to accept that four will be neglected.

Read more: Thin-spread teams

How to narrow it down

1. Does every service in the team’s portfolio have an automated deployment pipeline? If not, identify which services lack pipelines and why. Start with Missing deployment pipeline.
2. Does the team have time to improve services that are not actively producing incidents? If improvement work is always displaced by feature or incident work, the team is spread too thin. Start with Thin-spread teams.
3. Are there services the team owns but is afraid to touch? Fear of touching a service is a strong indicator that the service lacks the safety nets (tests, pipeline, documentation) needed for safe modification.

Ready to fix this? The most common cause is Missing deployment pipeline. Start with its How to Fix It section for week-by-week steps.

8 - Some Developers Are Overloaded While Others Wait for Work

What you are seeing

Sprint planning ends with everyone assigned roughly the same number of story points. By midweek, two developers have finished their work and are waiting for something new, while three others are behind and working evenings to catch up. The imbalance repeats every sprint, but the people who are overloaded shift unpredictably.

At standup, some developers report being blocked or overwhelmed while others report nothing to do. Managers respond by reassigning work in flight, which disrupts both the giver and the receiver. The team’s throughput is limited by the most overloaded members even when others have capacity.

Common causes

Push-Based Work Assignment

When managers distribute work at sprint planning, they are estimating in advance how long each item will take and who is the right person for it. Those estimates are routinely wrong. Some items take twice as long as expected; others finish in half the time. Because work was pre-assigned, there is no mechanism for the team to self-balance. Fast finishers wait for new assignments while slow finishers fall behind, regardless of available team capacity.

In a pull system, workloads balance automatically: whoever finishes first pulls the next highest-priority item. No manager needs to predict durations or redistribute work mid-sprint.

Read more: Push-Based Work Assignment

Thin-Spread Teams

When a team is responsible for too many products or codebases, workload spikes in one area cannot be absorbed by people working in another. Each developer is already committed to their domain. The team cannot rebalance because work is siloed by system ownership rather than flowing to whoever has capacity.

Read more: Thin-Spread Teams

How to narrow it down

1. Does work get assigned at sprint planning and rarely change hands afterward? If assignments are fixed at the start of the sprint and the team has no mechanism for rebalancing mid-sprint, the assignment model is the root cause. Start with Push-Based Work Assignment.
2. Are developers unable to help with overloaded areas because they don’t know the codebase? If the team cannot rebalance because knowledge is siloed, people are locked into their assigned domain even when they have capacity. Start with Thin-Spread Teams and Knowledge Silos.

Ready to fix this? The most common cause is Push-Based Work Assignment. Start with its How to Fix It section for week-by-week steps.

Related Content

• Everything Started, Nothing Finished - High WIP and uneven workloads reinforce each other
• Burnout and Unsustainable Pace - Chronically overloaded developers burn out
• Push-Based Work Assignment - Assignment model that prevents self-balancing
• Limiting WIP - Constraints that make imbalance visible
• Work in Progress - Track per-person WIP to surface imbalance

9 - Work Stalls Waiting for the Platform or Infrastructure Team

What you are seeing

A team needs a new environment for testing, a configuration value updated, a database instance provisioned, or a new service account created. They file a ticket. The platform team has its own backlog and prioritization process. The ticket sits for two days, then a week. The team’s sprint work is blocked until it is resolved. When the platform team delivers, there is a round of back-and-forth because the request was not specific enough, and the team waits again.

This happens repeatedly across different types of requests: compute resources, network access, environment variables, secrets, certificates, DNS entries. Each one is a separate ticket, a separate queue, a separate wait. Developers learn to front-load requests at the beginning of sprints to get ahead of the lead time, but the lead times shift and the requests still arrive too late.

Common causes

Separate Ops/Release Team

When infrastructure and platform work is owned by a separate team, developers have no path to self-service. Every infrastructure need becomes a cross-team request. The platform team is optimizing its own backlog, which may not align with the delivery team’s priorities. The structural separation means that the team doing the work and the team enabling the work have different schedules, different priorities, and different definitions of urgency.

Read more: Separate Ops/Release Team

No On-Call or Operational Ownership

When delivery teams do not own their infrastructure and operational concerns, they have no incentive or capability to build self-service tooling. The platform team owns the infrastructure and therefore controls access to it. Teams that own their own operations build automation and self-service interfaces because the cost of tickets falls on them. Teams that don’t own operations accept the ticket queue because there is no alternative.

Read more: No On-Call or Operational Ownership

How to narrow it down

1. Does the team file tickets for infrastructure changes that should take minutes? If provisioning a test environment or updating a config value requires a cross-team request and a multi-day wait, the team lacks self-service capability. Start with Separate Ops/Release Team.
2. Does the team own the operational concerns of what they build? If another team manages production, monitoring, and infrastructure for the delivery team’s services, the delivery team has no path to self-service. Start with No On-Call or Operational Ownership.

Ready to fix this? The most common cause is Separate Ops/Release Team. Start with its How to Fix It section for week-by-week steps.

Related Content

• Lack of Self-Service Environments - Environments that require tickets to provision
• Pipeline Changes Require Another Team - Pipeline config changes blocked by the same structural separation
• Sprint Planning Is Dominated by Dependency Negotiation - Cross-team waits that dominate planning
• Separate Ops/Release Team - Structural separation that prevents self-service
• No On-Call or Operational Ownership - Delivery teams without operational responsibility

10 - Work Items Take Days or Weeks to Complete

What you are seeing

A developer picks up a work item on Monday. By Wednesday, they are still working on it. By Friday, it is “almost done.” The following Monday, they are fixing edge cases. The item finally moves to review mid-week as a 300-line pull request that the reviewer does not have time to look at carefully.

Cycle time is measured in weeks, not days. The team commits to work at the start of the sprint and scrambles at the end. Estimates are off by a factor of two because large items hide unknowns that only surface mid-implementation.

Common causes

Horizontal Slicing

When work is split by technical layer rather than by user-visible behavior, each item spans an entire layer and takes days to complete. “Build the database schema,” “build the API,” “build the UI” are each multi-day items. Nothing is deployable until all layers are done. Vertical slicing (cutting thin slices through all layers to deliver complete functionality) produces items that can be finished in one to two days.

Read more: Horizontal Slicing

Monolithic Work Items

When the team takes requirements as they arrive without breaking them into smaller pieces, work items are as large as the feature they describe. A ticket titled “Add user profile page” hides a login form, avatar upload, email verification, notification preferences, and password reset. Without a decomposition practice during refinement, items arrive at planning already too large to flow.

Read more: Monolithic Work Items

Long-Lived Feature Branches

When developers work on branches for days or weeks, the branch and the work item are the same size: large. The branching model reinforces large items because there is no integration pressure to finish quickly. Trunk-based development creates natural pressure to keep items small enough to integrate daily.

Read more: Long-Lived Feature Branches

Push-Based Work Assignment

When work is assigned to individuals, swarming is not possible. If the assigned developer hits a blocker - a dependency, an unclear requirement, a missing skill - they work around it alone rather than asking for help. Asking for help means pulling a teammate away from their own assigned work, so developers hesitate. Items sit idle while the assigned person waits or context-switches rather than the team collectively resolving the blocker.

Read more: Push-Based Work Assignment

How to narrow it down

1. Are work items split by technical layer? If the board shows items like “backend for feature X” and “frontend for feature X,” the decomposition is horizontal. Start with Horizontal Slicing.
2. Do items arrive at planning without being broken down? If items go from “product owner describes a feature” to “developer starts coding” without a decomposition step, start with Monolithic Work Items.
3. Do developers work on branches for more than a day? If yes, the branching model allows and encourages large items. Start with Long-Lived Feature Branches.
4. Do blocked items sit idle rather than getting picked up by another team member? If work stalls because it “belongs to” the assigned person and nobody else touches it, the assignment model is preventing swarming. Start with Push-Based Work Assignment.

Ready to fix this? The most common cause is Monolithic Work Items. Start with its How to Fix It section for week-by-week steps.

Related Content

• Everything Started, Nothing Finished - High WIP and long cycle times reinforce each other
• Merging Is Painful and Time-Consuming - Long-lived work creates merge pain that further slows delivery
• Monolithic Work Items - Stories too large to finish quickly
• Work Decomposition - Breaking work into small, deliverable slices
• Development Cycle Time - Measure time from first commit to deployable