The process of creating a sound estimate for your project will take some time in any agile project. You will have to define what work to do in the project. In general this work can be split up into two parts:
- Project related work. There’s project related work, such as creating a project proposal or setting up your development environment. The agile process Smart suggests a number of such project related work items to be added to your backlog.
- Functionality. And then there’s the functionality related work. In processes such as Scrum and XP this work is specified in (user) stories. In the Smart process we apply smart use cases, whereas in feature driven development (FDD) features are used.
Defining work
To create an estimate for your project, you will have to establish a number, in point, hours, pizza parts or whatever, for both types of work items. For the project related work items, this is fairly simple. How much time do your need to write the project plan? How much effort goes into setting up the development environment? The hard part here is to estimate the amount of functionality the project will realize.
Estimating this requires you to write down the stories, or in Smart to model the smart use cases. This will take some time, especially when you apply user stories as your main unit of work. The problem with estimating user stories is that each new user story is a new case. As user stories are (under normal circumstances) rather unstructured, there is no easy comparison possible with similar (previous described) types of user stories. Hence, the estimate will always be rather inaccurate.
Smart estimation
Using the agile process Smart we apply a specific way of modeling use cases, and apply these as our main unit of work. We model down use cases one level deeper than you would "normally" expect to do. Alistair Cockburn refers to this level of use case as sub-function level use cases. We refer to the collection of user goal level use cases plus sub-function level use cases as "smart use cases". They are equally granular and equally complex. And thus, they can be estimated by different teams in different locations, and in different types of projects in a similar way and on the same scale. Furthermore, we have built up a list of standardized types of smart use cases (stereotypes) from all kinds of projects. Smart estimates appear to be rather reliable (and repeatable).
Estimating agile SAP
For instance, I’m currently coaching an agile SAP project (not exactly the type of project you would expect to turn agile), and we’ve modeled and estimated the smart use cases in about three days with the team – more or less the time you would spend in writing stories for the project. This initial investment of three days, which in Smart project is normally one of the work items advised to put on your backlog anyway, pays back soon, as the smart use cases also make up the larger part of your product backlog.
| Share this post : |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |