The popularity of agile methodologies for software development is deserved.  The predominant method of choice is Scrum.^[1]  Customers may change their minds … but how does Scrum deal with policy makers that change their minds?

I have seen many rule authors (also business analysts or subject matter experts) struggle to deliver value in projects that use Scrum.

What is the issue?

• Business rules are rewritten into a user story, introducing double work from the view of the rules author.
  
  
• The user story for a business rule is used in planning poker.^[2]  The resulting plan consists of an incomplete set of rules causing the programmer to 'creatively fill in the gaps'.
  
  
• The rules authors don't keep pace with the development team.  The development team continues development of the software application features, and the rules are harvested from the code after the fact.

The resulting inefficiency or incorrectness is easily blamed on the rule author.  Being a subject matter expert, he often does not have enough insight in Scrum for a good defense.

Scrum's popularity is due to faster software delivery with better results.  Why do Scrum teams struggle with business rules while they intend to have a flexible development method that is able to deal with changes?  A logical reason may be that Scrum is just not designed to deal with business rules.  Scrum is designed for problems that cannot be fully understood or defined.  In contrast, business rules operate in situations that can be fully understood and described, are always explicit, and should be unambiguous.

That being said, the Scrum team still needs business knowledge and business rules.

The business rules may be fully understood and described … but other aspects of a software product may not be.  One way to deal with the situation is to deliver all rules in advance as a complete and consistent set.

However, this is undesirable because:

• it feels like going back to the waterfall method that delivered such bad results;
  
  
• the project needs to wait for the rules, resulting in unwanted delays;
  
  
• policies may still change over the course of the project.
  

Example

Let's go into a little more detail.  A user story plays a central role in Scrum to scope, plan, and evaluate a development cycle of three weeks.

No programmer can implement this user story without extra information.  In an attempt to provide complete information to the programmer it is tempting to associate the user story with a decision and the scenarios with rules.

Other scenarios would need to deal with VAT for other kinds of products and other countries.

What we forget in these attempts is that user stories should be limited in detail by 'what can be hand-written on a small paper note-card'.  Obviously all VAT rules of all countries can't be written on a small paper note-card.  Rules should be considered 'an artifact' or 'data' in Scrum terms.

A happy marriage is the union of two good forgivers.

The subject matter expert should help the Scrum team to define a good scope; the Scrum team should be aware of the special value of business rules.

The dilemma is that the Scrum team needs to cover all aspects of the software system in one Scrum cycle:  database, business logic, user interface, workflow, etc.  Therefore it is likely he tends to take a depth-first slice in a hierarchical knowledge structure:  ship only to the Netherlands.

This structure does not show the rules but rather the way information depends on other information as a result of rules.  The rules themselves may be expressed by rule statements (for example, in RuleSpeak) or by decision tables.

By doing so the resulting knowledge is always incomplete.  One may argue that this incompleteness is inherent and will be corrected in future Scrums.  True, but it means constant changes in every Scrum cycle to rules developed earlier.

A better way is to take a breadth-first slice in the hierarchical knowledge structure.^[3]

The result is that details are gradually added and the delivered rules will be more stable.

Not all knowledge has a hierarchical structure.  So here is my advice for the general case:

• The rules author may only deliver rules as a rules set that is well-scoped, complete, and consistent.  He should advise the product owner to choose a well-scoped user story.
  
  
• The Scrum team must consider adding a user story such that a new rule should be something like minutes' work rather than hours' work (or days' work).  Rule changes will be part of the Scrum life cycle, whether they are caused by policy changes, new insights, or something overseen in earlier Scrum iterations.

This is just one step toward business-driven software development.  Looking forward to the next?

References

[1]  Scrum:  https://en.wikipedia.org/wiki/Scrum_(software_development)  

[2]  'Planning poker' is a main concept in the Scrum methodology.  Those familiar with Scrum are familiar with planning poker.  It is a way to make estimates on the importance or development effort of a software feature that eliminates the cognitive bias of where the first number spoken aloud sets a presedence for the others.  See:  https://en.wikipedia.org/wiki/Planning_poker  

[3]  Breadth-first versus depth-first strategies are two different ways to traverse a tree structure. Breadth-first assumes that you first explore all neighbours on one level before exploring the next (deeper) level.  The picture above shows the two ways.  See:  https://en.wikipedia.org/wiki/Breadth-first_search  

# # #