Skip to main content

Concordion specs for xProcess

We've recently started writing the specs for xProcess changes with Concordion which is an open source tool for writing acceptance tests- here's some initial feedback.

This is probably a topic I'll come back to, but for now if you're interested in seeing the first examples produced, they are available with the source code download at Source Forge. The initial area where Concordion is being used is the specification of constraints and dependencies. This is a complex area and we felt just adding unit tests for the xProcess scheduler would be insufficient to capture the nuances of the effect of adding a constraint; for example a task ending after the start of another one. This constraint alters not only the end date of the task, but also the order in which certain aspects of scheduling take place, which could affect the forecast dates of other tasks. Comments in the test code are simply not good enough to capture this behaviour, but Concordion provides ideal flexibility and clarity to document and test such behaviour. So far the experience has been very positive.

Below is an example of the generated output from Concordion following the test run.

Example output

Note - the links in the generated output below are to local files and therefore not accessible!

xProcessScheduler >

Constraints and Dependencies

Constraints may be defined on a task to limit when the task may either start or end. For example a task may be constrained to start after a specific calendar date, or a date which is manually defined on another task such as its target start date. Constraints may also reference the forecast date of another task, in which case it may be referred to as a dependency.

Dependencies defined on a task from another project use the forecast dates from the last time that project was scheduled - see Dependencies on another project - (note: such dates will be "NEVER" if the depended-on project has not yet been scheduled). Dependencies on tasks in the same project however require that the depended-on task is scheduled before the depending task. The depended-on task may be promoted in schedule order (start-after-end-of constraints) or the depending-on task may be demoted in schedule order (other forms of dependency such as start-after-start-of constraints). More details can be found on this and following pages.

Example 1. - With no Constraints

Assume that today is Wednesday 2012/4/12. (2012/4/12 )


  • a small project starting today
  • with one fully available participant available 8 hours per day for the duration of the project
  • having 2 date-based tasks (overheads of 20% each on all participants, one for the duration of the project and the other for the first week)
  • 10 effort-based tasks with 16 hour estimates, named a-j,
The following table sets up the tasks:

Task Name Task Type Hours / % Earliest Start Earliest End No. of Participants
a For Horses effort-based 16 1
b For Mutton effort-based 16 1
c Forth Highlanders effort-based 16 1
d For Rential effort-based 16 1
e For Braun effort-based 16 1
f For Vessence effort-based 16 1
g For Police effort-based 16 1
h For One And One For All effort-based 16 1
i For Novello effort-based 16 1
j For Oranges effort-based 16 1
General Overhead date-based 20% 2012/4/12 2012/10/18 All
Starting Overhead date-based 20% 2012/4/12 2012/4/19 All

When the project is scheduled the project forecast start will be: 2012/4/12

Then the start and end dates of the workpackages will be as follows:

Workpackage Forecast Start Forecast End (50%)
project 2012/4/12 2012/10/18
a For Horses 2012/4/12 2012/4/17
b For Mutton 2012/4/17 2012/4/20
c Forth Highlanders 2012/4/20 2012/4/24
d For Rential 2012/4/25 2012/4/27
e For Braun 2012/4/27 2012/5/1
f For Vessence 2012/5/2 2012/5/4
g For Police 2012/5/4 2012/5/8
h For One And One For All 2012/5/9 2012/5/11
i For Novello 2012/5/11 2012/5/15
j For Oranges 2012/5/16 2012/5/18
General Overhead 2012/4/12 2012/10/18
Starting Overhead 2012/4/12 2012/4/19

A dependency of one of these tasks on a task that is lower in priority will change the order of scheduling and result in different forecast dates for the project.

How Constraints change this result

Post a Comment

Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…