I.N.V.E.S.T. a story about listening to people experienced in Agile development

I think everyone in the development group has heard our engineering manager go on about the Agile term INVEST.

  • Independent (of all others)
  • Negotiable (not a specific contract for features)
  • Valuable (or vertical)
  • Estimable (to a good approximation)
  • Small (so as to fit within an iteration)
  • Testable (in principle, even if there isn’t a test for it yet)

But the question is HOW do you practice INVEST, when so much is interdependent? Best guess, and engineering input.

Every story worked on in a sprint should have no dependency to any other story in a sprint. That is, if you have a story with dependencies, those dependencies should be on another sprint before the story you are working on.

Negotiable is to prevent both engineers and product owners from asking for the gold plate, when a plastic plate will suffice. But it also is there to allow for the prevention of technical deficit. (Scale and scope will be covered below.) The KEY to negotiable is that the backlog grooming is WITH the TEAM. That means that engineering participates in the grooming process. This isn’t just the product owners and scrum masters

One of the suggestions, from CST Scott Dunn, is that the morning stand ups are only 15 mins, but an hour is carved out, so that any discussion that needs to run on after the stand up can immediately pick up. If there are no follow up discussions, then fill that 45 min time frame with a little grooming with the team. This way you don’t have massive negotiation and grooming jammed into one day, and you don’t have an unwieldy kickoff day.

Valuable is that there MUST be value in the feature being completed, and the value can be demonstrated. If there is no value, then it is a failed story. This is why stories are considered cake and not pie. A story should cover all of the needed layers, and not just UI, or DB, or middleware. All layers that are needed to add value should be part of the story.

Estimable means that the story is tangible. It has definite beginning and end. The success criteria are known. It can be designed, developed, and tested, all with effort.

Small, also scaled, means that the story is minimal viable. Again, we don’t want to churn out gold plated chairs, when all we need to a stool to sit on.

Testable is that the story should be validatable within the same sprint as the development. If we have our test patterns setup correctly, we should be able to run automated regression at build. The question becomes, what does the team consider “released”? Is released when the PO approves the work, but the UAT is not finished, or is released when all testing, including UAT is signed off? 99% complete isn’t complete. If the engineering team can only code to75% of the two week window, then have to leave room for testing, what does the engineering team do for the remaining time? They address dropped balls in the sprint.

Dropped balls includes assisting in testing, and addressing technical debt. Most technical debt addressed in this time is the testing debt of building out more unit tests. Getting caught up in the automation.

In summary, our engineering manager was right, but engineering teams needs to start running miles with this plan, and not just give it a nod.

This entry was posted in Agile Development, Brian's Code Extreme. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s