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 calculating and using simple productivity for improved forecasting.

Velocity is defined as the amount of required work delivered per time period. In the Scrum process for example, required work is called the Backlog, and its component parts, the Backlog Items, are individually sized and prioritised. The size of an item is not the same as the effort required to complete it, though size and effort are related and may - once the velocity of the team is known - be derived one from the other (see here for further discussion of size and effort). The size of backlog items is usually estimated in a team-specific measure called points (sometimes called Story Points, Feature Points or, if related to the amount of work a team member could carry out in a full uninterrupted day, Ideal Days). The size estimates therefore really only give a relative size for the backlog items. However once a timebox has been completed - in Scrum timeboxes are called Sprints - the team has a measure of how many points they were able to complete and so have the first reading for velocity in Points per Sprint.

When using xProcess for Scrum you can see the velocity of completed Sprints from the burndown chart. For example in the Sprint shown below you can see that a total of 91 points were completed, giving the team a velocity of 91 points per sprint.

Using the principle of yesterday's weather it might be natural for the team to commit to a similarly sized set of backlog items in the next sprint. Before doing so they might be wise to look at all the history on the project. Here are the burndown charts for the previous two months, first Sprint 02 and then Sprint 01...
As we can see from the respective velocities of 40 points per sprint and 73 points per sprint, velocity is not always constant and, if we look at the reasons behind this, we may be able to forecast the velocity for the next sprint more effectively. Why did Sprint 02 for example do so badly?

Well one clue is in the dates for this Sprint. This won't be the only team to have discovered their productivity was lower between mid-December and mid-January! All the team were on holiday for at least some of the Sprint, and when they were in they probably discovered someone they needed to speak to was away, or that there were other activities they had to attend to which were not related to the sprint backlog. Another factor was that this sprint had a number of items that had been worked on but not completed at the end of the sprint. Since they are not finished they cannot be counted in the size of work "done". Backlog items like this do not necessarily get done in the following sprint since other priorities may be introduced to the team at that point. However if they are carried forward (as they were in this case), there will be considerably less work left to complete in the following sprint. This at least partially explains why Sprint 03 was such a productive one.

So what velocity should the team predict for Sprint 04? This is where other information from xProcess comes in very handy in the planning process. xProcess allows team members to record when they were working on overhead tasks (like management meetings, email and admin, training courses and office parties) as opposed to backlog items themselves. xProcess also give us information about the amount of time spent on backlog items that were not completed in the sprint.

The key metrics we want to derive in order to better predict the next sprint are these:

• simple productivity (size of work done in points per ideal person-day)
• overhead percentage (what proportion of people's time is applied to non-backlog-item tasks)
• availability (when are people available to the project)

We'll leave discussion of overhead tasks and availability to another occasion, though they can be set simply in xProcess. The simple productivity measure of Size/Effort can be calculated automatically by xProcess. I say simple productivity measure since, as Putnam and Myers point out, it is more complex to derive a true process productivity for a project, taking into account that size and effort do not follow a linear relationship when the duration under consideration varies. This non-linearity can be broadly discounted however if the duration of the sprint does not vary. (One of the reasons why agile methods recommend fixed durations for timeboxes is to ensure that feedback from one timebox is applicable to the next.)

Simple productivity for a given period (a sprint for example or the whole project) takes into account all the non-overhead tasks booked to during the period. It also takes into account tasks which were incomplete at the start and end of the period. Once the simple productivity factor has been calculated for previous sprint (or for the project so far), the value can be use to set new effort estimates based on size using the Set effort to match size UI Action described in a previous article.

The simple productivity currently being used on this project is 1.0 - in other words a backlog item estimated as size 1 will be scheduled with an estimated required effort of 1.0 ideal person-days. Using this factor the current state of the burndown chart for Sprint 04 is as shown below.


However using the history from the previous 3 sprints, xProcess can calculate the actual productivity in points per ideal person-day. In this case it was found to be 0.91 - in other words historically a task of size 1 has taken on average about 8.8 person-hours to complete. Using the Set effort to match size action, we can quickly adjust the estimates of all the open tasks in the project to reflect this factor. Once all this is applied (see burndown chart below), the state of Sprint 04 now reflects the true situation that certain tasks are at higher risk of not completing.

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 xProcess Data Source has registered an interest in that type of event. If it has it invokes the defined action(s) for that event, potentially committing changes to the xProcess data or indeed to external systems. Several monitors are delivered with the xProcess Workflow Server. There's the DataSourceMonitor itself which monitors state transitions within the Data Source.There are also monitors for the Flyspray bug tracking system, for CollabNet's Project Tracker and a general purpose email monitor. However if you want to integrate external systems with xProcess this is exactly the way to do it - write your own monitor. In spite of my introduction to this blog article, this is quite straightforward to do. There are 3 key elements:

1. A monitor class (inheriting from com.ivis.xprocess.workflowserver.monitors.MonitorImpl)
2. Methods for this class which initialize it, find the events
   
3. [optionally] An event class (inheriting from com.ivis.xprocess.workflowserver.ExternalEvent) and possibly useful methods that may be called when the event is triggered.

Here (below) is a code snippet for a sample monitor which show the key methods init(), which is called when the Workflow Server starts up, and findEvents(), which is called periodically by the server in order for this monitor to query its external system and provide the events to the server.

public class SampleSystemMonitor extends MonitorImpl {
SortedSet events;
public static String EXTERNAL_SYSTEM_NAME = "My External System";
public static String EXTERNAL_EVENT_NAME = "My event name";

public String getSystemName() {
return EXTERNAL_SYSTEM_NAME;
}

public String[] getEventNames() {
return new String[] { EXTERNAL_EVENT_NAME };
}

@Override
public void init(DataSource dataSource) throws WorkflowException {
super.init(dataSource);
// TODO initialize connection with external system
}

@Override
protected SortedSet findEvents() throws WorkflowException {
events = new TreeSet();
// TODO query external system for new events, e.g.
// loop
ExternalEvent xevent = new SampleSystemEvent(new Date(), EXTERNAL_EVENT_NAME);
Map map = xevent.getMap();
//TODO set map values so they can be referenced in the triggered action, e.g. ...
map.put("name", "New Task");
events.add(xevent);
// end loop
return events;
}
}

The monitors are singleton objects and are instantiated within the server by Spring. So having written your monitor you can inform the Workflow Server that it should be called simply by modifying the xprocess.xml in the Tomcat WEB-INF directory (following the pattern of other monitors). Specific objects in the xProcess Data Source can respond to the events and trigger specific actions through their "WorkflowPackage" - which is declared in the process definition.

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
Expression:
#factor = getProject().getFloatProperty( "CurrentProductivity_pointsPerIdealPersonDay"),
#factor = (#factor < 0.01) ? 1.0 : #factor,
#size = getSize(),
setBest(#size/#factor*240.0),
setMostLikely(#size/#factor*480.0),
setWorst(#size/#factor*720.0)
Applicable to: Task
UI Action: True
Parameters: (none)

Note that the operation uses a factor to scale the mapping between size points and effort. If this factor is 1.0 the mapping is 8 hours effort (480 minutes) per size point.

Perhaps - like it's inverse operation, this will one day appear in the preconfigured operations of the Simple Process. Note that is very similar to the Set estimates action which is delivered in this process. However that operation is designed to take Size as a parameter (usually during the instantiation of a pattern) and so it is not suitable to make that one into a UI Action for operating directly on existing tasks.

Traceability through a simple metamodel

When people start defining processes with total traceability between every aspect, the sight is often not very pretty! When traceability adds multiple layers of complexity it rarely pays for itself in terms of improved quality or maintainability.

This is one of the reason why we defined what we termed the "minimum metamodel" in the Better Software Faster book on agile development. The diagram shown here is this model in its simplest form. The questions traceability should answer are:

• How is this requirement tested?
• How is this requirement implemented?
• How is this part of the design tested?
• Why is this part of the design needed?

It's a useful starting point when defining the artifacts required in a software development process, and the references they should contain to enable these questions to be answered.

The Role of the Process Engineer

Since xProcess provides configurability of processes, it also introduces a new role to projects - that of the Process Engineer. Of course the role may be played by a project manager or process consultant, or simply by one of the members of the project, but it's an important role and one that can greatly enhance the success of projects using xProcess.

Several Process Engineers have already created the processes that come bundled with xProcess (Basic Scrum, Basic FDD, Simple Process) and there are others such WPM Prince 2, Web Development, Issue Management and Basic UP that are available in the community. So the likelihood is that most Process Engineers will start with one of these processes as the baseline. As experience with a process is gained, the details of the way it is being used by the projects can be understood and the sorts of useful modifications or additions to the patterns, actions and workflows can be specified.

Using parameters in task patterns

Processes are defined in xProcess through Patterns - patterns for sets of tasks, for projects, for priority groupings (e.g. Folders) and patterns for artifacts. By constructing sets of patterns, including patterns within patterns (Composite Tasks), a complete definition of the process behind a family of projects can be built up. A key part of pattern definition is the specification the pattern's parameters. This is what this article looks at.
The diagram above shows the editor for a typical pattern from the Simple Process, showing the 4 parameters that this pattern has: Name, Project Home Page, Start Date, Duration. These are the values that the user can supply when creating an instance of the pattern. Parameters always have default values which are used if the user does not change them, but you can add an action to a parameter - a DefaultValueGetter - which will set the default value at run time based on teh context or time at which the pattern is being instantiated. You can see in this case that Start Date has such an action attached which sets the start date to the current date. Parameters also have a type which can be one of: Integer, Floating Point, Boolean, String or Rich Text.

Having set up the parameters of your pattern you can then use these values to set values within the elements that are created by your pattern. Typically these will be projects, tasks and artifacts any or all which can be modified from the state of the prototype elements in the pattern to the real elements made when a user uses the pattern.

Th first way to use a parameter is by string substitution. Any text field in your prototypes, for example the prototype project's name, can include a parameter substitution. Simply enclose the parameter name with 'Simple Project pattern, the name of the prototype project is $Name$, showing that when the pattern is used the name of the project comes from this parameter. It's also used in the case of the Project Home Page parameter, which sets the description field to point to this url.

You can even use string substitution with artifacts, provided that the artifact uses a text-based, rather than binary format (e.g. rtf, xml, csv formats). In this case just put the substitution string, say $Name$ inside the file attached to your pattern. You'll find when you use the pattern that the corresponding artifact has this string substitution applied. Several patterns in the Basic FDD signs in the field, and when the pattern is instantiated the parameter value will appear at this point instead. You can see an example of this type of parameter use in nearly all the pre-defined patterns delivered with xProcess. In our example here, the Simple Project pattern, the name of the prototype project is $Name$, showing that when the pattern is used the name of the project comes from this parameter. It's also used in the case of the Project Home Page parameter, which sets the description field to point to this url.

You can even use string substitution with artifacts, provided that the artifact uses a text-based, rather than binary format (e.g. rtf, xml, csv formats). In this case just put the substitution string, say $Name$, inside the file attached to your pattern. You'll find when you use the pattern that the corresponding artifact has this string substitution applied. Several patterns in the Basic FDD process have artifacts that use this feature.

The second important way that parameters are used is in actions. As well as DefaultValueGetters, patterns have another very useful type of action - InstantiationActions. These actions are called when a pattern is used. When you define InstantiationActions you specify which of the prototype tasks you want to be transformed by the the action, and which particular action you wish to be called. Here's the InstantiationAction used in the Simple Project pattern.It uses the Set project dates action which sets a number of dates (targets and scheduler dates) associated with the project. It is this code which ensures projects you create start on the date provided by the Start Date parameter. One thing to note about parameters appearing in OGNL code is that spaces in parameter names are replaced by underscores and non-alphanumeric codes are ignored. Also following OGNL conventions the parameter is preceded by a hash (#). Note that the Set project dates action uses both the Start Date and Duration parameters.

When you're starting to use parameters in your patterns the best approach is to look at patterns delivered with the pre-configured processes in xProcess and to re-use actions that these patterns use. The Simple Process for example provides the following actions that you can re-use in your own patterns:

• Next timebox date (Project): finds the latest finishing folder/timebox and adds a day to its end date
• Set required role type (Task): finds a RoleType matching the supplied string and sets this as the required role type for the task
• Set target dates (Task): sets targets
• Get today with offset: returns a date relative to the current date
• Set max participants (Task): sets the number of people for a task
• Set project dates (Project): sets target and schedule dates
• Assign to account name (Task): searches for a matching user and assigns to the task
• Get earliest start or end date (Task): returns either today or the task's project's scheduleStart if this is later
• Set target dates and weight (Folder): sets the folder's targets and priority weighting based on that of preceding folders/timeboxes
• Next timebox name (Project): finds the name of the latest finishing folder/timebox with the appropriate name and returns a name with its number incremented
• Set estimates (Task): sets three-point estimates based on Size
• Set importance (Task): categorizes task into High, Medium or Low categories.
  

Note: there are also some UI Actions in the set of actions supplied by the Simple Process. See for example this article: Set size to match effort.

Artifact templates

When you're defining the process for your project don't forget that a major part of this is defining the standards for the files, documents and records (artifacts) that are created, modified and qualified as a result of the process. xProcess provides excellent support for defining the types of artifacts that will be used in a process. Furthermore it stores both the document templates and the resulting documents within its version control system so you can not only reliably access the most up to date version, but also compare it with previous versions if necessary. Here's a task pattern showing artifact templates that have been added to each of the subtasks in the pattern.
You can do this simply by right-clicking on the task and adding a "reference" to a new artifact - an attached file, form or hyperlink. (To learn more about the different types of artifacts supported in xProcess see Creating Artifacts in the Help system). Once you've done this, every time you make an instance of this pattern a clone of your artifact template will be created for use with that instance. Another nice feature is that you can substitute text in the file when you instantiate it, using the values that the user enters into the parameters of the pattern.

Actually parameters of patterns are discussed in the next article in this series, so see Using parameters in task patterns for more details.