Agile and Delivering Features

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.