At my company, we have adopted full Agile methodologies and related tools.

We plan our sprints based on a set of customer requested features by the end of the sprint. Commonly, we do not deliver the features requested by the customer by the end of the sprint and we push to future sprints.

This has me concerned because of the bow wave we are creating with a backlog where the backlog grows of problems and features keep getting added. The customer wants both problems addressed and features developed with no relief on either.

I know that Agile means to deliver working software faster.

How does Agile address this case where we have hard deadlines to eventually deliver features that may be pushed ad infinitum?

This has to do with technical debt; however not whether to schedule as a feature or a bug. It has more to do with how long is too long to push features to the right.

I have tried holding sprints open and my team has disdain for this approach because they say it affects their metrics for velocity.

  • Possible duplicate of Should technical debt be scheduled as a feature or a chore (or a bug)?
    – gnat
    Nov 1, 2017 at 11:56
  • 3
    "based on a set of customer requested features" - and are you taking into account what you can actually deliver? The point of sprint planning is to commit to a deliverable amount of work so that the engineers and the product owners can agree on what's the highest priority to focus on over that period. If you keep failing to deliver you're right to be concerned, something is going wrong. Using agile methodologies doesn't make you magically faster, the point is to shorten feedback loops.
    – jonrsharpe
    Nov 1, 2017 at 11:56
  • "we have adopted full Agile methodologies and related tools" No, you did not, as there is no list of Agile methodologies that you could consider adopting whole. And that Agile doesn't define any tools to be adopted.
    – Euphoric
    Nov 1, 2017 at 12:26

3 Answers 3


Sprints in the main should be the same size - there are occasional exceptions but extending a sprint to complete work is solving the wrong problem.

If you aren't completing sprints - you need to understand why. Are you committing to too much work? Are stories being sufficiently groomed? Are blockers left to fester? Do you have a bottleneck of certain skills? Are developers fully committed or do they have other distractions (other projects, support, admin etc)? All this should be addressed in the retrospective.

Next, you need to address how you carry items over. Are they simply bumped as they are or can the story be split.

The elephant in the room seems to be that you're committing to continuing work on incomplete stories while agreeing to extra work. I'd nip this in the bud right now. You need some form of triage where the customer agrees what the priorities are otherwise your sprints will become more and more unachievable.

  • 'Sprint' degenerates to 'slog' which eventually becomes "death march". Agile does not allow one to outrun problems, apparently.
    – user251748
    Nov 1, 2017 at 14:27

You claim your team is "full agile" but you keep putting things in sprints that won't get done according to your history. You can be agile, but you're not going to be very good at it if your client is not. Your case is a perfect example of how that doesn't really work.

In the Agile Manifesto, "...marketing, or management, or external customers, internal customers, and, yes, even developers—don’t want to make hard trade-off decisions, so they impose irrational demands through the imposition of corporate power structures. This isn’t merely a software development problem, it runs throughout Dilbertesque organizations."

Planning a sprint should take into consideration how much work you've been able to do in the past and not how much someone "wants" you to do. That's the trade-off decision. At some point you have to tell the client how much work you can get done and nothing more. If you keep getting less done, you have to promise less. Hire more or better programs.

Do your client a favor and learn how to say no up front instead of after the sprint when you've failed to deliver. Your client's demands are irrational because your company is not helping them manage their expectations.

  • But if they say "No", then the customer will find another developer, who doesn't say "No". /s
    – Euphoric
    Nov 1, 2017 at 12:44
  • @Euphoric but if the promised work simply cannot be done in the desired time, by anyone, then those "other developers" fail, and the customer comes back to you, now much delayed and dispirited, but hopefully wiser. I have seen this enough times. You don't need to solve the problem of others making stupid deals, just wait for them to fail.
    – user251748
    Nov 1, 2017 at 14:30
  • 1
    @nocomprende did you really see customer come back? Do you have any details about such cases? After how long they came back?
    – Euphoric
    Nov 1, 2017 at 14:49
  • 1
    @Euphoric - that's not entirely true. You don't have to say no to everything. Customers will ask for many things on any given project and have them rejected.What makes clients more upset is if you keep saying yes and fail.
    – JeffO
    Nov 1, 2017 at 19:01
  • @JeffO I do agree that is how it should be happening. But being cynical myself, I often hear about customers who just can't accept the idea that they might be requesting too much.
    – Euphoric
    Nov 2, 2017 at 6:37

Having a large amount of carryover between sprints is a sign that stories were not properly groomed, fixing this requires a lot of work with the product owner to clarify requirements and create a firm definition of done. Some of this may be how you plan your sprints, they should only be as big as the amount of points you actually delivered in the past, not just everything that a customer wants now. If you have a product owner that wants more in a sprint than you know you can accomplish you need to push back and get the properly prioritized set of stories that fit your sprint size and take on no more than that. In a scrum/agile methodology its the responsibility of the dev team to ensure that they manage the size of a sprint to only be as much as they can do.

You seem to also have a belief that Agile means delivering more faster or your customers have that belief. This is not true in the sense that most people believe it to be. When agile people say they deliver working software faster they are constraining working software to be only what was in the sprint or previous sprints. You can deliver a site that has a working payment system faster, but its not going to have search, reviews, photo galleries, wish lists, etc. Agile guarantees working software faster, not necessarily feature complete software faster (though that can happen with a mature team).

The agile process isn't super great at explaining how hard deadlines are managed, it's generally more implied. It's managed by taking the estimated story points of the feature and using velocity to work backwards to get the latest sprint that these items could go in to deliver on time. If features are not high enough on the backlog to get into sprints before they can be finished on time it needs to be brought to the attention of the product owner so they can prioritize accordingly. Ensuring your backlog can prominently display deadlines for items or having a separate tracker for deadlines that is reviewed regularly during grooming are good ways to keep on top of these things. Your product owner will work with you to prioritize work to meet deadlines that are truly important, sometimes you may need to actually miss a deadline that you said you would for them to understand you can only fit so much in a sprint (I'm not advocating doing this on purpose, but sometimes people need a wake up call or teams are overly dramatic about deadlines).

As far as managing technical debt goes, the only real way that will work is to enforce the boy scout rule of improving code as you go and baking that in to estimates. Pure tech debt stories can be created, but its extremely rare that they ever hit high enough priority to be worked on. Other options like occasional maintenance sprints, or setting X hours a week as clean up/free time/training tend not to work as well since there will be pressure to use that time to work on higher priorities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.