Skip to main content


Showing posts from March, 2009

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 follo…

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 h…

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 patternsRole TypesCategory TypesGateway TypesWorkflow PackagesArtifacts and Artifact TypesStart 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…

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 …