Get certified - Transform your world of work today


ROI from INVEST-ing

Ensure That INVEST Works for Our Projects

6 November 2013

Arijit Sarbagna
Atos India

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).

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.7 (7 ratings)


Yogesh Shinde, CSM,CSPO, 11/6/2013 8:29:33 AM
Good one.
Arijit Sarbagna, CSP,CSM, 11/7/2013 1:53:52 AM
Glad you liked it! :)
Jeevan TM, CSM, 11/7/2013 7:37:13 AM
Good one Arijit! :)
Gagan Rana, CSM,CSPO, 11/9/2013 5:02:44 PM
Yes, organizations need to write independent stories. And there are many ways to handle dependencies, so that we can write independent stories and also we have to keep the track of these dependencies. This is job of Product Owner and Technical Team Lead (or Scrum Master) to ensure constant communication and dependency tracking method is in place. Where stories have dependency, then break story into two stories, one contains user aspect and second contains tech aspect or we can assign the tech task as one of the task of the same user story. Tagging in agile management took (like Jira, Mingle etc) can be used for tracking/visibility of dependency. Also, Sprint 0 or Hardening Sprint is very important, where tech lead can setup the technical framework/environment before coding. Every body needs to think ahead and do things appropriately to ensure the time is not wasted... One way to handle stories which crosses many sprints is by assigning these stories as Global in nature and Definition of Done can specify to check whether all required global stories are delivered within the sprint or not. Another way is writing dependent stories as NFR stories. Again DFD needs to specify to check the NFRs before story/sprint is done. Tagging in the Agile tool works well here...
Arijit Sarbagna, CSP,CSM, 11/11/2013 12:45:41 AM
@Gagan: Well said & very crucial points. As you rightly said - one of the major challenge is indeed towards dependency management. One of the ways of doing so could well me introducing a simple MPP type master release plan - where predecessor & successors could be well tracked.
In the modern ALMs we do have many similar features & I am sure we we progress, we will have better tools to drive this (minimizing human errors).

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up