8

Let's say you have a validation engine that needs to cover 100 rules to be useful.

Let's also assume the team can only deliver about 10 rules per iteration.

How would you go about making a "potentially releasable product increment" by the end of the first iteration, when the rules engine would still be missing 90 of the core rules?

Would you, for example, add a temporary failure / warning that always fires based on the fact that not all rules have been implemented?

Edit for context: I'm developing middleware for a complex business process with many legacy use cases, meant to replicate and replace a large monolith. It's challenging to go live without 100% coverage, as we have limited ability to decide or restrict which tricky use cases will show up in production asking to be serviced.

  • Are you building the "validation engine", or are you simply writing 100 rules for an existing engine? – Bryan Oakley Mar 6 '17 at 16:16
  • @BryanOakley: In my case it's a basic Drools spreadsheet setup, where each agile story would either add / modify ruleset definitions or just add new rules within an existing ruleset. – James Daily Mar 9 '17 at 2:50
  • you should try Kanban rather than scrum here ... – user666 Mar 21 '17 at 22:13
7

How would you go about making a "potentially releasable product increment" by the end of the first iteration, when the rules engine would still be missing 90 of the core rules?

You release the first ten in the first sprint. Just because it's "potentially releasable" doesn't mean it has to be usable by the customer. It just means that what functionality is there has been tested and behaves as designed, and doesn't cause any regressions in the product.

Think of "potentially releasable" as "we have no more work to do for this feature. The code is done and it has been properly tested and documented".

Would you, for example, add a temporary failure / warning that always fires based on the fact that not all rules have been implemented?

That's definitely something you might want to consider, if you want the customer to actually test the feature.

  • I see, so there's a meaningful distinction between "potentially releasable" and "sufficient for the user needs" (where user may be a UI user, or a web service client hoping to call an API, or whatever) – James Daily Mar 9 '17 at 2:58
  • I'm realizing that my question isn't really about agile (the "Done" concept answers that handily), but rather a design question - how should an API gracefully detect and respond to unsupported scenarios when providing meaningful incremental releases? – James Daily Mar 9 '17 at 3:12
6

From the Scrum Guide, the definition of an Increment says:

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.

If you don't have sufficient rules completed, it's likely that the Product Owner will choose to not actually release it. However, the Increment should be "Done". Any rules that you have already implemented should have been completed per your team's Definition of Done.

The decisions that you make depend on what is going to be done with the Increment. In your question, you mention throwing exceptions for unimplemented rules. This could work, but if someone was going to be integrating with your rules engine, it may create overhead for them to deal with this error case, especially if it won't exist in a finished product. Or maybe it's what would make their life easier. Consider what the intent of the Increment is, who may be using it, and go from there.

  • "but if someone was going to be integrating with your rules engine, it may create overhead for them to deal with this error case" Absolutely true, but a necessary evil in enterprise scenarios or we'd never get anything out the door :) – James Daily Mar 9 '17 at 3:03
  • @JamesDaily No, it's not a necessary evil. You can mitigate it by not throwing an exception that the finished system wouldn't throw or by returning values. Anything that means that the other system doesn't need to add error handling code just to handle the fact that your system isn't finished yet to be able to demonstrate a minimum functionality. – Thomas Owens Mar 9 '17 at 9:42
  • Perhaps throwing an exception is too harsh. Soft warnings or even a Full vs. Partial validation indicator is more sensible and easier for a client to react to. In another comment, I noted my thinking is moving towards: how should an API gracefully detect and respond to unsupported scenarios when providing meaningful incremental releases? – James Daily Mar 10 '17 at 17:01
3

You have defined a situation with no escape.

I'm sure there are real life situations where you have a block of complicated functionality which can't be split. But the usual case is that you can break down a requirement into sub requirements which do have some benefit of themselves.

Say for example my requirement is to validate UK credit card billing addresses. This is pretty complicated, we want to ensure as best as possible that the address is the residential address of the person named on the card so that if they default on a payment we can chase them up.

There are potentially hundreds of validations and checks we can do to improve the reliability of the check, but each one individually is testable and offers a real decrease in fraud risk.

  • address has a house number and a post code
  • postcode is valid format
  • postcode lookup with external api succeeds
  • postcode is a geographic postcode
  • address is validated with credit card supplier etc etc

If push came to shove, the customer would be able to make money with only a subset of the rules implemented. Either the extra risk could be accepted or manual work arounds could be added to the workflow to mitigate the situation.

Scrum and agile methodologies are designed with this in mind. They try to avoid failure of the whole project by ensuring that some missing requirements do not cause the entire solution to be worthless.

But they cant change reality, if you have a space rocket which definitely needs X, Y and Z to fly. Then you need all three!

The trick is to recognise that generally in line of business applications this is not the case, despite what the customer might say.

  • Yes, I could imagine an iterative approach with temporary informational warnings that are returned when the validation is known to be incomplete for a given input. Eg, you asked me to validate your local residence address and your foreign banking address, but the engine had to skip the foreign address as it's not yet supported. The PO may decide it's not complete enough to actually go live, but at least the API is being honest about what it has or has not validated. – James Daily Mar 9 '17 at 2:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.