Skip to main content


Showing posts from February, 2008

Calculating team velocity

Why is it that agile methods use timeboxes containing broadly similar sets of activities - as opposed to phases favoured by more traditional methods, which contain different types of activity in each phase through the lifecycle? A key reason is that stakeholders in the project get quicker and more effective feedback on the progress and direction of the project. As a consequence planners can judge more accurately the effectiveness of the project and what it is likely to achieve over its full duration. One of the most useful metrics planners get from each timebox is the velocity of the team. Scrum projects usually use the velocity from previous sprints to forecast their likely progress - a technique often referred to as "yesterday's weather" since it effectively assumes the next period will be broadly the same as the previous. In this article we discuss what velocity is, how to calculate it in xProcess, and how to go beyond "yesterday's weather" by calculatin…

Developing your own workflow monitor

Just occasionally I'm tempted to post a really techie article that will probably only be of interest to hard-core xProcess enthusiasts! This is one of those occasions. I've written elsewhere about some of the aspects of workflow support in xProcess (see for example the article on State Diagram support which explains how to define triggers for internal events graphically, and "From tracking to planning and back" which discusses how tracker products can be linked to xProcess via workflow). This article though will go a bit further and give you some hints about how the Workflow Server works and how you can link in your own programs to detect workflow events and trigger actions on them.

The Workflow Server sits in a Tomcat instance watching the outside world (and the inside world of the xProcess Data Source) through a set of monitors. When these monitors discover events that might be of interest, they tell the Workflow Server which checks whether any object in the xProces…

Set effort to match size

A previous entry provided the script required to define an action shortcut for setting the Size of tasks based on existing estimates for the effort required (see Set size to match effort). In some cases the inverse of this operation - Set effort to match size - is the useful operation. Here's the code you need for that one. Once again you should make it a "UI Action" by setting this field to True so that it appears on the right-click menu when you select a task or set of tasks.

Action Name: Set effort to match size
#factor = getProject().getFloatProperty( "CurrentProductivity_pointsPerIdealPersonDay"),
#factor = (#factor < 0.01) ? 1.0 : #factor,
#size = getSize(),
Applicable to: Task
UI Action: True

Note that the operation uses a factor to scale the mapping between size points and effort. If this factor is 1.0 the mapping…