Agile Zone is brought to you in partnership with:

Paul is a principal consultant at ThoughtWorks. He is enthusiastic about open source in particular. He is known for Dependency Injection (one of its pioneers with PicoContainer), Selenium browser automation (co-founder), Branch by Abstraction and most recently Client-Side MVC frameworks. Paul is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Delaying Non-functional Stories

  • submit to reddit

Minimal Viable Product

For software projects in the Agile/Lean side of the IT industry, we are often chasing “minimal viable product” (MVP). Moving clients from a series of 18-month delivery slogs (“Waterfall” was very popular in the 90s) to iterative is easier when you can get them to believe that you’ll be able to go live in weekly intervals after that first push.

Obviously, sequencing the highest business-value stories for that MVP is appropriate. Consequentially, delaying some functional stories until after that initial go-live is key, at least the "some" that you’ve analyzed as non-critical to the initial MVP release. Back in the 90s, customers used to negotiate hard for all the items on the “user requirement checklist”, because it was going to be 18 months to the next release (or phase), but that’s not the case with Agile. Functionality flows into an application during a modern project, and you can measure it. From that, trust and confidence emerge.

But what of non-functional stories?

The answer is to generally delay them as long as the cost of implementation is flat. If the cost of the delayed non-functional story is beginning to hockey-stick, or you’ve left no reasonable contingency, then you’ve left it too late.

It could be that you know exactly what you’re going to do and it’s a pure implementation cost. If this is the case, then it’s all about trading the cost of that story with a more valuable functional one.

Delayed Decisions

It could be that it’s a decision that you’re delaying. Imagine you’re using MongoDB in an early version of the new app, but it’s clear for long term needs you’ll need a full relational schema for reporting. You might be torn between the Java ORM tools Hibernate and MyBatis (or NHibernate and Dapper for .Net). The cost of indecision could be growing very gradually – more “entities,” even if it is cheap to code I/O to MongoDB for new entities. That could be close enough to flat for you to say that the delay is worth it, as you’re able to focus on functional deliverables for longer.

Delaying until after the initial go-live?

You could also say that the cost of delay is still flat(ish) for the non-functional decision after you’ve gone live with the initial release. In this case, you need a data conversion to populate the relational schema from accumulated Mongo records. You might also count that as a relatively constant cost, rather than something ballooning.

Delaying Indefinitely

This is now getting interesting – you may choose to not decide even longer. Mongo could be working for you, and you might choose to do a longer series of releases with it, or indeed now plan to never change to relational at all (savings).

Changing Your Mind During the Delay

It gets even more interesting if you consider that you could make a post-go-live decision to go to Apache’s Cassandra instead, which is far closer to Mongo than Relational plus ORM is. If you’ve made that decision, you saved the cost of going to Hibernate or MyBatis inappropriately, and essentially back. Your initial decision to not implement is now a hedged bet that has paid off.


The risk is that you might not be able to predict when that hockey stick change in costs will be. The challenge is coolly predicting when that hockey-stick happens, and being able to bank the preferred functional changes in the meantime. Added to that is a need to convince your risk-averse customers to relax, and be pleased about the modestly smarter investing.

Many times I’ve witnessed a project that prioritized third-normal-form DB design before interactivity and user experience were coded. Back in the 90s that was ordinary. More recently, in the client/server era, with Agile/Lean as a methodology, it has been unusual and could be one factor that tips projects towards failure. I enumerated others previously.

Of course, this really isn’t new thought. It’s yet one more technique pulled from the world of lean manufacturing into software project management, and is routinely used by experienced PMs and Techies.

Published at DZone with permission of Paul Hammant, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)