In search of a definition of uncertainty in three point estimates

I've written elsewhere in this blog about the value and theory of three-point estimating (3PE). See "3PE - why I use three estimates where one might do!". The main practical snag with using 3PE in an agile context is the additional overhead of thinking of 3 numbers every time you want to confirm "effort to complete" - ideally something people can quickly update even on a daily basis.

So I'm working on a mechanism which shows the level of uncertainty in an estimate to complete which takes into account the effort completed to date (T) and the three points of the estimate: best case (b), most likely (m) and worst case (w). If you're interested in the intricacies of such things, please read on!

The composite estimate (E) is the estimate is the derived "median" which is used when one number is required (as for example in the "Total" field in the screenshot above). It is derived from best case (b), most likely (m) and worst case (w) as follows based on assumptions about distribution of cases between best and worst:

E = (b + 4m + w) / 6

Various formulae are possible for our level of uncertainty or estimate risk (R). Here's a starting point expressed in terms of just b and w as follows:

R = (w - b) / (w + b - 2T) ..................................[1]

This expresses the average "error", (w-b)/2, as a proportion of the average time to complete, (w+b-2T)/2. However since it ignores the most likely estimate, it doesn't take into account that for example the worst case may be much further away from the most likely than the most likely is from the best case. An alternative formula would therefore be:

R = (w - m) / (m -T) ........................................[2]

But this formula ignores the best case completely. One could say the "error" should be defined as whichever is greater out of (w-m) or (m-b), but actually it's not this aspect that worries me practically. The worst case is always more significant from a forecasting viewpoint, and from an estimating viewpoint it is the one that can be much further in error than the best case, which can never go lower than T and in practice will always be a little bit higher than T (or you can forget about estimating and just finish it!).

So a better approach is to define the "error" in the formula for R relative to the median estimate, E, all three points are then taken into account. It's much more satisfactory.

Following this approach, here's the formula for the uncertainty in the estimates (estimate risk) that I'll be using:

R = (w - E) / (E - T) ........................................[3]

For those interested in the mechanisms within xProcess to use this formula, there'll be a discussion on that project's wiki about how users can set estimate to complete and level of uncertainty rather than worrying about 3pe every time they update time to complete.

Inaugural meeting of the Southern UK Scrum User Group

Several scrum enthusiasts in the South of England have decided that, rather than spending a few hours on the train to get to the London Scrum meeting, it would be a good idea to get together more locally to talk about Scrum. The inaugural meeting was last night at the Inn on the Furlong in Ringwood (easy reach of Southampton, Bournemouth, Winchester, Salisbury and so on). Apart from some excellent discussions about people's experiences with Scrum we were able to savour the very fine selection of real ales from the Ringwood brewery. If you're in the South of England and interested in joining us next time check out the group's forum discussions on LinkedIn here.

How to define a custom report in v3

There are 2 ways to generate a report on a project. One is to right-click on a project and select "Reports", and the other is to select from the File menu: File -> Menu -> Custom Reports and then select the type of report you want and its subject. For example using File->Export we can select a "Work Log" report for a person or a task.

What if the report we want isn't in the list? Can you write your own report template? Yes you can - that's what this article is about.

Let's say I want a report on a task in the project. I need to define an "Action" in the process I'm using, identify that action as an "Export Action" (checkbox in the Action dialog) and define the file extension for the report. Let's say in this case we want an html file. You can see in the screenshot this action being defined. Note that the "Applicable to:" field has been filled in as "Task" and also the "Expression:" field has been given the value "name". This won't be a terribly fascinating report but even so let's run it!

Use the File-> Export-> Custom Reports menu and select one of the tasks in your project as the subject of the report. Once you've supplied a filename and pressed "Finish" you should find that a browser is launched and a page generated containing the name of your task. Congratulations you've generated your first xProcess custom report!

So what about doing someting a bit more interesting. As you've probably guessed by now that will mean looking in a bit more detail at the "Expression" field. The script that goes in this field must be written in OGNL so you need to know a bit about that language - if you'd like to read the (quite small) reference manual click here - and a little bit about the xProcess Java API. (You'll also find the OGNL reference manual in the xProcess Help documentation.)

So let's try a slightly larger bit of OGNL to generate our task report. How about this:

'<h1>' + name + '</h1>' + '<br>' +
description + '<br>' +
'Start: ' + start + '<br>' +
'End: ' + end50 + '<br>' +
'Closed?: ' + closed

You could even turn this into a report on all tasks in your project. First change the "Applicable to:" field to "Project" (this will also mean you can invoke it by right-clicking on your project) and turn the above code into a subroutine that can be called for every task. Like this...

#taskReport = :[
#output = #output +
'<h1>' + name + '</h1>' + '<br>' +
description + '<br>' +
'Start: ' + start + '<br>' +
'End: ' + end50 + '<br>' +
'Closed?: ' + closed
],
#output = '',
allTasks.{#taskReport(#this)},
#output

Browse other Actions in the predefined processes to see other examples of using OGNL. Then if you make a report you think others will find useful - or if you need help with syntax or the API - post it to one of the xProcess Forums on SourceForge. See xProcessForums.

Define the process behind your projects

To get started with xProcess it's sensible to start with a pre-defined process - the Simple Process for example (see "The Simplest Possible Way to Get a Project Plan?").

However defining your own process in xProcess needn't be complicated. First thing is to switch to the Process Engineer perspective via the toolbar across the top of the screen (from the default Project Manager perspective). The explorer view in this perpective shows you the processes that have already been imported into your data source and you can create a new process simply by clicking on the process icon in the task bar on the left hand side.

Here are some of the other things you can create in a process:

• Project pattern(s)
• Task patterns
• Role Types
• Category Types
• Gateway Types
• Workflow Packages
• Artifacts and Artifact Types

Start by looking at some of the Task Patterns in pre-defined processes like Basic Scrum and Basic FDD which come included in the download. You can see the structure of the task and project patterns by using the hierarchy or process diagram. When you define a parent task in a pattern you can define what kind of child tasks can be created in the parent by right-clicking on the task and selecting New -> More Patterns... This makes it easier for Project Managers to build sets of tasks that match the process you are defining.

There are many other aspects of Process Engineering with xProcess to discover. If you are interested in taking the on-line course for the Certified xProcess Engineer qualification, contact us now through the xProcess site on SourceForge.

Theory of Constraints and Agile Project Management

Recently on the LinkedIn forum PM Toolbox, Arash Sadati asked for comments about tool support for how Goldratt's Theory of Constraints (TOC) or Critical Chain Project Management can be integrated as part of the Agile Project Management. Here are my thoughts on the subject.

One thing all agile projects share is that - because of a conscious removal of dependencies between features wherever possible - they will be resource constrained rather than critical path constrained (a generalisation but broadly valid). Methods like Scrum-XP try to avoid specific role constraints (e.g. we can't make progress because we don't have a BA or a GUI expert or a middleware expert available) by specifying only 3 role types (Product Owner, Scrum Master, Team Member). So the team as a whole must to some extent be generalists (or at least prepared to learn / fill in specific roles) to reduce the risk of role constraints. In any real application of Scrum of course such role constraints may be real and teams will have to pay attention to them. The default condition though is worth understanding because it's a means to keep the effect of role constraints to a minimum.

FDD defines many more roles and I think as a result there is a greater risk of role constraints. Availability of specific class owners for example is a typical problem which Palmer and Felsing discuss in their book on FDD. Flexibility, especially in small teams, for people to wear multiple role "hats" is crucial. The really interesting observation in comparing agile to waterfall is the requirements process where detailed specification of features is ideally "just in time". David Anderson and others point out that it is a serious waste of precious resources to allow too much work to be done on future requirements when the critical constraint is the development team.

When we were specifying the xProcess product which is designed to support any priority-driven process (any agile process in other words), we did want to be able to give visibility to problems arising from role or resource constraints. Patterns of tasks can be defined in custom processes that require specific or general roles - or even allocation to specific team members - so that forecasting can take into account not only the total development effort available, but in the cases where specialised roles are required. It can therefore show the impact of limited availability of critical roles. Custom reports can be generated to show resource utilisation, and where these show less than 100% utilisation, the situation is likely to be one where specific roles are "critical", requiring other roles to wait for them.