How and in which units is it better to measure the product scope (volume of incoming requirements / amount of business functionality) if different parts of product (different requirements / different parts of business functionality) have a different nature?
In our company, we want to develop and implement a methodology for measuring the scope of the product.
We want to reach the following goals:
- To make business requirements measurable and thereby more transparent. I.e. we want to measure all incoming requests for product improvement in some units. These units should not be related with real man-days because we don’t know who exactly will implement these requirements. Furthermore, these units should not be related with ideal man-days because ideal man-days are for the work scope, not for the product scope. For example, we can implement the same requirement in three different ways: we may implement it fast with bad quality of code, slow with good quality of code and extremely slow with parallel refactoring. It’s depends on us, how we will do this item, but we want be honest with our internal customers (another departments of our company) and show the same «price» for all equal requirements (regardless of how we will do it).
- Calculate productivity of the team. As noted above, the work scope is not equal to the product scope. Productivity in our understanding is the amount of the product scope units that we did within a fixed amount of time (that’s iteration). I.e. the team may do a lot of useful work (to reduce technical debt, for example), but if they don’t implement enough requirements, productivity will be low.
To achieve these goals, we need to choose a unit for the product scope and learn how to measure it.
Story points are good candidates for these kind of units, but we have a problem with them: we have a lot of different technical systems within our product. So, there are many different kinds of requirements: make additional automatization for engineers, create new reports to managers, implement new functionality to end users, etc. Furthermore, one requirement may be related with several technical systems. Managers can’t compare such incompatible requirements just as developers can’t compare tasks for different technical systems (to implement such incompatible requirements). It’s like comparing red and hot. I tried to solve a similar problem here: How to use Story Points, if User Stories are completely different?.
At the current moment, we do the following: we have created a table for the different types of requirements, defined the reference stories (the reference requirements) to each of these types, and estimate other requirements based on these reference stories. There are two (three) big disadvantages in this solution:
- We have chosen reference stories such that, their implementation took roughly the same amount of time. So, this is a fundamental problem: we have a relationship between reference stories and man-days at the moment when we defined them (we wanted to avoid this situation, see above).
- As far as we will make changes within technical systems, story points of a different kind will drift apart. In some systems technical debt will increase and related story points will be more «expensive». In others systems technical debt will be decreased and related story points will be «cheaper». As a result, after some time one story point related with different requirements will have a different cost. In that case we will not achieve our first goal.
- If we periodically normalize story points, by choosing the new basic story of each type, that will have the same man-days estimates, then we will not be able to see any change of the team's performance over time. So we will not achieve our second goal.
Also, I heard about a function point but I didn’t look in this direction. It seems a little complicated. Should I look at it more deeply?
Maybe there is another way to solve my problems?
Update after receivied answers (19.12.16)
I meant a volume of business requirements, not a value of it.
I will try to give an example:
Imagine, we are refurbishing an apartment. We have two requirements:
- To hang a picture;
- To install a chin-up bar for pull-ups.
Volume of requirements (i.e. product scope):
- To hang a picture: 1 point, because it is necessary to drill one hole.
- To install a chin-up bar for pull-ups: 4 points, bacause it is necessary to drill 4 holes.
Volume of work to implement requirements (i.e. work scope):
- To hang a picture: 1 point, because to make a hole in dry wall is very easy.
- To install a chin-up bar for pull-ups: 16 points, because a chin-up bar for pull-ups should be installed with wide bolts on load–bearing wall which is usually is made of concrete and I have a low power drill. Accordingly, I know that to make a hole with my low power drill on a load–bearing wall is roughly four times harder than making a hole in dry wall.
Ideally, the volume of requirements should be close to the volume of work to implement the requirements. For example, if I were to buy a good drill, it will be no difference, which material the wall is made of.
The question is, what units and how to measure the volume (not the value) functional requirements, regardless of exactly how we will implement them and how much time we need for this.