The extra "S" needed in INVEST

Disclaimer: I probably do not have the mammoth insights needed to amend time-tested Agile practices. After all, any success in my Agile endeavours- I owe it to the giants like Mike Cohn or Jeff Patton and many other Agile coaches. But what I propose underneath is what I learnt from some of my own experience, which tells me that we can make INVEST even more powerful.

So we all understand that INVEST is the acronym for the following,

• I – Independent
• N – Negotiable
• V – Valuable
• E – Estimable
• S – Small
• T – Testable

I guess that should be pretty clear and known as well? If not, please refer to the horse's mouth: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Each of the above tenets has worked beautifully for me. However, consider one scenario.

In one of the discussions with a customer for a particular project (this one is in Mortgages), the customer rep expresses a need for a new lending type we were trying to introduce in the system.

Okay, quick rewinder- this was a team that was working on Phase 2 of an existing project. It had a BA (not myself), a QA lead, a couple of devs and a product owner from the customer. I had the good fortune of observing this project from a distance. Phase 2 was supposed to bring in some more lending types that would allow the customer to net more business (a lending type is basically a type of loan e.g. home loan, car loan. In our case, the team was working on a Sharia-compliant Home Purchase Plan)

So back to the discussion with the customer. As the BA mapped out the user journey for the new lending type to be supported, the customer felt that a particular set of fields and calculations had no business being in the system for the new lending type. The requirement seemed simple enough and made sense. Those were fields that needed certain "source" values which would not exist in the new lending type. Dev said, no problem. The BA was happy. It seemed that we were looking good. The user story ("As a Home Purchase Plan user, I should not see values pertaining to BTL lending") took shape.

This user story followed all the INVEST principles. It was independent- it did not touch any other stories we had in the backlog. It was a negotiable story- we could hide the fields, remove the fields or disable them. The story detail was right. There was value, yes. It was estimable and small. And it was also testable. All good? You can obviously guess that I am leading you somewhere here.

When the story was implemented and released (after a successful Sprint Demo as well), it was a disaster. Why, you may ask. Well, turned out that those set of fields had actually been removed from the flow for another lending type as well. This another lending type was quite similar to the one we were building and this was already in the system in Phase 1. This other flow from Phase 1 needed a couple of those fields. Like, REALLY needed. So it was a bloodbath that needed rollbacks, users of the other lending type were furious, common users found the new feature suspicious and didn't adopt etc.

An easy conclusion towards apportioning responsibility was that, someone (possibly the dev) needed to remove the fields in "the right way". Since the dev probably didn't do a very good job of observing care, we saw what we saw. But that wasn't true. This was a fresh team and the dev did do the best, considering all things. Phase 1 was handed over to us, but there was so much lost in the details (may be a better handover process- blog topic for another time). My perspective is that, the bug was not preventable. We didn't have the knowhow to guess and the developer had no way of knowing that similar lending types referred to some sort of common master field list. However, the bug should not have gone all the way through. Regression testing would have caught that easily. And we actually never regression-tested this story, as it didn't seem like a meaty piece of work warranting that extra testing effort.

Hence (and my many many other examples gained over 4 years of working in many of such Phase 2s), I say that we introduce a new "S" to INVEST and make it a still neat sounding "INVESTS". What does this new "S" stand for? Stability.

Stability asks- does the user story being developed stand to hurt any other component in the system? We are not talking about independence here (though you could extend the independence principle to cover this base). We are talking about affecting other parts, legacy parts of an existing system which may malfunction when we push something new. If this "S" had played a part in the incident I narrated, we would have asked, "Is this stable?" and there would have been greater likelihood of catching the problem we coded in.

The "S" could also be Sanity, but I like Stability more as it urges us to ask a clear question- would we be breaking something if we introduced this? I don't think this would be terribly important for projects starting out. But Phase 2s and 3s etc.- I believe and have learnt the hard way that INVESTS is the way to go.

What do you think of my new (and courageous?) addition to INVEST? Let me know in the comments or my email ([email protected]).