Skip to main content

"Done" but not releasable

Last post 06:06 am September 26, 2019 by Marvin Ynte
4 replies
05:48 am September 13, 2019

I am working for a company that has a number of teams who are developing the different modules of a single product. Unfortunately, we are not scaling it yet. One of the problems that we encounter is this.


Team A develops feature A but they can't deploy it yet in the upcoming release because there is a dependency with Team B and Team B has not finished developing feature A yet. Is it correct to assume that feature A in Team A's sprint backlog is already Done?

06:15 am September 13, 2019

Is it correct to assume that feature A in Team A's sprint backlog is already Done?

No. Work must be proven to be Done, which means integrated and ready for immediate release.

  • It may be possible to code against common interfaces by means of which Team B's work is stubbed, the feature being turned off until B finishes. When the complete feature is proven to be Done it is flipped on. However, that would mean Team A's work is not conducted in a timely manner, inviting depreciation and waste.
  • A better approach would be to self-organize into feature teams, each of which can deliver a feature without dependency. This may require an architecture which supports the modular development and release of features. A and B are then in a position to develop and deliver features under their own steam. This approach effectively descales the challenge.
  • If descaling is not possible, and there are only 2 teams, then A and B should be able to co-ordinate between themselves so work is integrated into a feature-complete increment.
  • If there are more than 2 teams, they may need to consider a scaling approach such as Nexus, through which they manage their integration dependencies.

05:05 pm September 13, 2019

Depends. I agree with Ian so let me ask on the proven there a dependency of Team A Feature A with Team B's feature, for the sake of it being functional/useable? Or is just the production release of Feature A blocked because the release needs to contain Feature B and the two features don't actually interact with each other?

You also said sprint backlog as opposed to product backlog, so within the sprint context if your process can call something done when it's deployed to a staging environment, and it's reviewable, then you can call the stories done. However, I would not call Feature A done from the product backlog until it's actually released. There may still be work to do in the next/current sprint for the integration support. 

This is a great opportunity to set your Definition of Done to match the ideal state and let that light a fire for the needed scalable architecture support. You can capture the cost of delay of your feature and have that help support the operational costs, as opposed to having your DoD consume the accommodation and have external folks believe there is not problem.

05:29 pm September 14, 2019

Going to pull the opening statements from the Scrum Guide section on the Development Team (emphasis added by me)

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. A "Done" increment is required at the Sprint Review. Only members of the Development Team create the Increment.

So if your Feature A meets the Definition of Done and everyone agrees that is has, I'd say it can be done.  Is it able to be included in an upcoming release?  Completely different question.  As @Ian Mitchell says the increment has to be proven to be done and ready for immediate release but it doesn't mean it has to be released. 

Both @Ian Mitchell and @John Varela make good points about the dependencies between the two features.  Are they functionally dependent on each other or just releasable dependent on each other? If you are building functional dependent features then you may want to rethink the strategy taking their words into account.  If it is releasable dependencies, welcome to software development but you may want to consider the ability to flip features on and off independently of each other.  That would allow your Feature A to be included in the release but it would just not be available until all of the "checkboxes" for the marketing announcements are complete. 

06:06 am September 26, 2019

Thanks for the feedback guys. It seems the next best move is for us to implement scaling, Of course we are eyeing Nexus as the framework to use..



By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.