Size Estimation – Some Thoughts From the Trenches
This is not a deep walkthrough of estimation methods and techniques. There is a lot of readily available information out there if you are interested. Some references are included here that you can use for further reading.
This article will discuss my experiences "from the trenches" in estimation. The cases discussed here focus on estimating the size of some product(s) to be developed.
First, a few words about what size estimation is about. In this context, it is about estimating something to be developed in a product—something that has not been done before. Thus, there is an inherent uncertainty, not the least about how much work is required to produce a finished product. It can be estimating a new or changed functionality of an existing product, or the contents of a completely new product. It can also be estimating something that will not change the functionality (e.g., refactor a product’s internals in order to make it easier to maintain and develop; i.e., reduce the technical debt) (Wikipedia, n.d.a.). Estimation is about having a grip on the size of a project in terms of the amount of work, complexity, or functionality, either directly or indirectly. This is very important and will be explained further.
Now, let’s say that the context is a product development organization of a reasonable size (large-scale agile) with cross-
Please log in or sign up below to read the rest of the article.