I was confused at first by the “backlog items will NOT be the same” – then I realized, you meant “the backlog items used to create the existing system can not be re-used ala copy-paste” – because new acceptance criteria (maintainability, not-on-platform-X) were not present previously. Agreed.

The structure / format of requirements for a migration project are still the same (as we both alluded) – stories + acceptance criteria.

I like that you called out maintainability as a measurable NFR. It opens an interesting sub-topic, how to (a) define acceptability and (b) measure how good we were.

If we were to migrate from (for example) Java to .NET, so that we can save money, the project should be considered a failure if that did not actually result in saving money – because ‘maintaining in .NET turned out to be just as expensive as maintaining in Java.’

How that plays out will ultimately be a function of the people you have available to maintain the system. Good programmers usually have (a) languages they know now, and (b) languages they don’t know yet. Unless you’re doing something dramatic like moving from a very unsuited (to the task) language to a very-suited-to-the-task language, I wouldn’t expect to get efficiency gains from a rewrite. Re-architecting often can make sense. Moving to a highly-cohesive, loosely-coupled design in a complex system enables rapid parallel development and increases business agility (or lowers the cost to be agile).

When I’ve seen “technology mandates” in the past, they’ve usually been expressed as constraints that are trickled-down mandates. They can still be articulated as acceptance criteria. The “is it worth it?” discussion usually (in my experience) happens at a higher level than, and outside the context of, a particular project. My mental model is company-wide standardization. Is that a good requirement? Depends on your team and your staffing models and your recruiting capabilities – as well as the product. Sometimes yes, sometimes no.

The biggest impact someone can have on a “migration project” is to make sure that the only stuff that gets (re)built is the stuff that still provides value.

I cringe whenever I hear “like for like” or “pin-compatible” migration projects. They might make sense, but are (I think) more likely to be “we’re too busy/lazy/rushed to define what _today’s_ requirements are. Let’s just blindly use the requirements from 5 years ago.

A proper backlog contains functional requirements (expressed as user stories or use cases that are notfleshed out with individual steps) paired with acceptance criteria that represent the nonfunctional requirements attached to each function. Together, these items state the least stringent conditions that must hold to verify that you’ve solved all the problems the system is intended to solve.

Presumably, there is a reason that you are restructuring the system. What is the problem you are trying solve? You’ve stated it relates to maintenance costs. Maintainability is a nonfunctional requirement, and you can attach measurable acceptance criteria that must hold to know the system has achieved an acceptable level of maintainability and cost of maintenance.

Thus the backlog items will NOT be the same. In particular, the acceptance criteria will need to change to reflect the more stringent maintainability requirements.

I wrote a couple articles about “migration projects” in the past, that may answer your questions. Or they may lead to more specific questions.

The crazy short answer is “the backlog items look the same” – you are standing up capabilities (in a new system) to replace capabilities* in the old system.

*You only need to replace the capabilities you actually use – some of the functionality that exists today in the home-grown system is undoubtably unused. And some capabilities are more valuable than others (giving you prioritization).

Here are the previous articles:

• Software Requirements for Migration Projects
• Organizing a Software Migration Project

Let us know (here, or in the discussions on those articles) if you have more questions, and thanks for contributing to this discussion!

Scott (@sehlhorst)

Let me try and reword your question into two questions, and please let me know if I got it right. I’ll answer each separately.

When implementing new functional requirements, for a product that already has some non-functional requirements (NFRs) “completed”, what is the impact on those non-functional requirements?

The really short answer is that the NFRs are unaffected. The short answer is that they are unaffected, because they still apply – however, they may apply in new ways. The long answer is that how they apply to previous functional requirements is unchanged. They now also apply, when appropriate, to the new functional requirements. As Roger points out in an earlier comment, the existing NFRs may not affect the new requirement – you may have an NFR that says that search results are generated in under 2 seconds, so that NFR would not make sense when adding support for two-factor authentication. However, adding the two-factor authentication capability does not “release” your product from the 2-seconds-per-search requirement. That NFR still applies. If, however, the new functional requirement is to allow people to find their friends in the system, and you happen to implement that with search, then the old NFR still applies – the search for friends must return results within 2 seconds.

For the reverse of the situation – how does adding new NFRs impact already implemented functional requirements, the answer is different (but the derivation of the answer is the same).

The new NFR will impact how all relevant existing functional requirements perform. Imagine that you have implemented search already, for product data, and user reviews. When you add the NFR to assure that search results are displayed in under 2 seconds, that NFR will apply to all existing search capabilities. It will “technically apply” to everything that already exists, but only makes sense in some situations.

If, for example, your previous “find your friends” capability was implemented by always showing all of your friends on the screen – users are never asked to “search” for them – then it would not really make sense. Imagine, over time, that adoption of your product has grown over time, and you decide to refactor the user interface – because showing all friends all the time creates a bad experience – when you refactor your product to enable “friend searching”, the (previously implemented differently) ‘see your friends’ capability would then need honor the NFR for searching-in-less-than-2-seconds.

Does that address your question?

I don’t bake the NFRs into sprint 0, because they (1) tend to change – because they are usually overlooked, they are usually unearthed or refined after releases, and (2) because they provide a great way to split epics into workable stories.

As an example: As a reseller, I want to receive your OEM product catalog electronically, so that I can sell your products to my customers. For sprint 1, I may only release to resellers in the US (deferring the need for translated product descriptions), or to only 10 key partners (deferring the need to scale), or only provide unformatted data (deferring the need to provide semantically marked-up HTML) for partners that create “parts lists.”

I’ve never heard of a “Hardening Sprint” before – but I have created “compliance themes” and “scalability themes” that defined specific NFRs designed to meet goals around compelling events (analyst approval, trade-show demo, etc). The only difference, I think, is to take it one step further and ask the question – “why do you need a robust infrastructure?” Maybe it is risk mitigation (but risk of what exactly?

I put “need” in quotes because response time (an attribute) leads to a constraint (under two seconds) that is a (current) manifestation of a more-is-better requirement, which has to clear a must-be hurdle, then exhibits diminishing returns.

I love the nuances of this stuff!

If you want to further develop the notion that an NFR applies to some, but not all features, look at the frequency of use of all features. It should be a power law distribution. Where a feature network extends into deeply into the long tail, that’s where the opportunity lies to live with a lower service level.

For example, for most web sites, it’s much more important for it to be available to visitors than it is that the administrator can change the content or formatting of the web site.