Get certified - Transform your world of work today

ROI from INVEST-ing

Ensure That INVEST Works for Our Projects

11/06/2013 by Arijit Sarbagna

INVEST is a pretty popular mnemonic used in Agile world, and it is "tried" widely. If we may draw an analogy, INVEST is actually an investment and can give you true ROI -- provided you have used it properly. But do we really do so?

When we go for any new Agile project, we all follow the drill and explain to the story authors that any "requirement" needs to be broken down in small independent units, per the INVEST model. Now, assume you are part of a large program, where you have a strong team of architects who wish to create "common controls" to be reused across teams. How does our story author understand which requirement will have dependency on those "common controls"? Also, even if developers help identify them, who will ensure that those dependencies are tracked and that eventually a sprint planning session will take note of them and accordingly push back stories that are waiting on half-baked user controls or frameworks?

The crux of the matter is that using INVEST will need some preplanning and expectation setting across teams, and then only one may expect the ROI on it. So, what could be those planning points?

Let's try to look at a few:

  1. How do we define "requirement" as Independent or self-contained?
  2. Does our architecture team realize that while this is a great practice to reuse controls or frameworks, this effort should not block others from progressing (you don't want to build a framework holding others back, which may eventually need rework in the long run, based on market/technology dynamics)?
  3. While we take into consideration external dependencies, we also need to check internal ones. E.g., assume we take up a user story that has a technical design review piece stitched to it. It does imply that till this design and corresponding review is done, developers will not be able to start writing their code. If that is the case, think about putting such effort one sprint ahead, so that at the next sprint we are ready with the story -- with design and review already taken care of.
  4. Is it truly Negotiable and Valuable? Remember, nothing is fixed and set in stone till you have your user story fitting INVEST -- till then, refine it and refine it further. This is where your backlog grooming comes handy.
  5. If we have done a good job with step 4, refining the backlog, we should have a user story that is Estimable and Small for development to deliver in a few person-days of effort.
  6. Lastly, all requirements coming out of development teams' hands -- i.e., as a functional piece -- should be Testable. The idea is simple: If we can't test it, we surely messed up backlog grooming and story refinement. No wonder this is why TDD makes more sense dealing with "test first."
So, how do you ensure that all such points are well accepted and followed? Apart from continuous coaching, you need to pull these points as part of your DoD and get client buy-in (as you will mostly have your POs coming from the client team).

In my experience, the majority of INVEST failures are largely (almost 70 percent) attributable to failing on being Independent. Interestingly the next prominent challenge has been the Testable part of it. So, to conclude, if we really wish to get ROI on our INVEST-ment, let us drive and understand all six aspects, with specific focus on "IT" (Independent and Testable).