To the question: “How long will it take for one of your Rule Analysts along with one of my SMEs to harvest and implement about 500 business rules?”, the straight answer, from the top of my head is: “Between 6 and 8 weeks!”

Since there is no sense of doubt or hesitation here, you may be curious and ask: “And how did you come up with that number?” I can choose between the following: “Just a WAG”, or better: “It’s a SWAG” or, my favorite: “It is based on ABRD!”

1: The WAG

This one starts with an unapologetic comeback, such as: “Well, and how did you come up with that 500 rules number?”. Given the vagueness of the initial question, my wild-assed guess on workload is certainly as good as the one that was used to count the rules.

Indeed, someone’s interpretation of what is called a rule can range from -a single row among a group of 500 belonging to the same large decision table to- a whole paragraph from a business policy guideline document.

Besides the issue of defining the real number (and complexity) of rules, there is a whole set of other critical factors that impact the estimate. Among those are:

• The nature of the rule source material (interviews, documents, application code)
• The number of decision points included in the proposed batch of rules
• The pre-existence of a shared vocabulary, fact model, or business object model
• The distribution of the rules over multiple business entities
• The level of experience of the SME with rule harvesting
• The experience of the Rule Analyst with the business domain
• The overall experience of the team with object oriented analysis and design

While the WAG is a deserved casual answer to a vague and uninformed question, it doesn’t help either of the parties. Instead, proposing to execute a Discovery Workshop, a short 3-day engagement part of the inception phase of the ISIS methodology, is a great way to achieve at least two goals: 

1. Extract the business context needed to craft an informed estimate.
2. Provide some education on rule set development methodology.

2: The SWAG

This time, the “scientific wild-assessed guess” justification for the 6 to 8 weeks is based on average time estimates per rule, numbers coming from past project experience. The ISIS methodology offers the following durations (in minutes) for Business Rules (BR) and Decision Table (DT).

A Decision Table is deemed complex if it has more than 50 rows. Other considerations, such as the number of columns involved may be taken into account. For business rules, complexity is linked to the fact that it performs complex calculations, involves complex pattern matching, implements an exception, etc…

Armed with these numbers, we must also consider that the time taken to develop a ruleset is never a linear function of the number of rules. It is instead logarithmic, or more simply, follows the common 80/20 rule (or some other statistical distribution close to it), with 80% of the time spent on the first 20% of the rules. Finally, we can apply a distribution of 65% of simple BRs, 25% of complex BRs, 9% of simple DTs and 1% of complex DTs. This yields around 6 weeks for 100 rules (20% of the 500), and then 8 weeks for the whole set.

In her “Scoping A Business Rules Harvesting Project” webinar, Gladys Lam present the following baseline estimations for rule harvesting alone: 2 to 3 weeks to produce a fact model, 45’ to specify, analyze, trace and review a rule, and 2 weeks for a final review and business validation cycle. She also mentions that the first 50 to 100 rules will always take the lion share of the time. Using these baseline numbers, 6 weeks gives us roughly between 50 and 100 harvested rules, with factors such as the ones listed previously influencing the estimate up or down.

So obviously, we are quite capable of justifying an estimate by relying only on a simple abacus. This abacus plus some additional insight on the factors listed in the previous “WAG” section can yield a reasonable estimate.

However, I’m arguing that if we don’t back it up with a proven rule development methodology, this estimate does not have much operational value.

Rule development is inherently an agile and iterative activity. We certainly cannot stand by our time estimate if we decide to approach the development using a waterfall process where we sequentially start by defining the business object model, then harvest and document all the rules, and finally implement and test them.

3: Using ABRD

Overall, relying on a proper development methodology is more critical than focusing on the estimate. The Agile Business Rule Development (ABRD) methodology is aimed not only at harvesting the rules but, more importantly producing an executable (albeit incomplete) ruleset as early as possible. It is based on five cycles: Harvesting, Prototyping, Building, Integrating and Enhancing. Within the cycles, the activities are Discovery, Analysis, Authoring, Validation and Deployment. The fourth cycle, Integrating, which should occur roughly within 4 weeks of the start, sees the deployment of a first executable version of the ruleset.

At this point, only 40% to 50% of the rules are developed, but are strategically distributed over the various tasks of the rule flow. Also, after the first deployment, there have been enough iterations on the Discovery, Analysis, Authoring and Validation activities to ensure that the business object model is solid and well-founded and that the existing rules are sound.

In 4 weeks, we thus have a solid and tangible (meaning executable) foundation for the ruleset. The ruleset then goes into the Enhancing cycle, when it is incrementally completed with the remaining rules.

 

As a conclusion, and to better play the estimate game, you may want to consider the following:

• Besides the pure size of a problem, producing a good estimate depends on multiple complex factors that need to be discovered in a short preliminary estimation workshop.
• The relevance of the problem size is diminished by the fact that the time it takes to develop a ruleset is not a linear function of the size of the ruleset.
• The estimate is close to meaningless if it is not attached to a specific agile development methodology, such as ABRD.

Let us know what your personal experience is on this software estimation topic applied to the business rule context!

Tags: ABRD, BRMS, business rule development, estimate, ISIS, software estimation, workload estimation

Posted by Pierre Berlandier in BRMS, ISIS, Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.