Before implementation, we use experience to estimate the difficulty of requirement implementation.
After the code has been tested and implemented, I want to examine a metric to measure the actual difficulty of the requirements.
Which metric could I consider to do that?
I will qualify my contribution firstly by stating that I am not a technologist; however, I think this generalizes to task complexity and performance no matter the specialty.
Complexity is a metric itself. However, it is qualitative and subjective. So it sounds like you are looking for a quantitatively measured condition that is always present with complexity, so that if and how much the condition is present you can assume reasonably that the requirement was therefore complex.
Time, by itself, does not cut it. Indeed, a complex task will take time. But there are factors of time that will skew the results and provide false positives: Time is relative. What is 'a long time?' If you measure duration, other events can interfere causing the duration to expand. If you measure work hours, then you have to somehow normalize it depending on the skill level of the resource(s) used or the typical op tempo one resource has over another, i.e., some people work quickly, others slowly.
Finally, some easy tasks simply take a long time.
I do not know if you will find a single quantitative metric, but rather the presence of multiple conditions to indicate complexity, e.g., time, number of defects, re-work, need for consultation and extensive peer reviews, and finally the subjective opinion of those who worked it.
After all, complexity is subjective. You need to conclude complexity after human analysis of the total picture. A quick, single measurement will not cut it.
You need to differentiate between time (i.e. it was really hard and therefore took a long time) and difficulty (i.e. wow, that was much more challenging to solve then we thought it would be).
You can track estimate versus actual time to get a sense of the first.
For the second, use a subjective survey. Have team members rate the difficulty on a scale of 1 - 5 (you can do that during estimation). Then have them take the same survey after it was done and see how the numbers compare.
Alternatively, if you are looking for some semblance of "complexity" there are a number of tools in the systems engineering world you can use to describe, model and measure complexity.
Software requirements' complexity is a matter of how long it takes to implement them.
The longer it took (including coding, testing, fixing, testing and etc.), the more complex it was.
The complexity of the actual code doesn't mean anything, since the implementation may have effected other existing code, which needed changing too, it may have been in a region that could effect multiple existing requirements, which required retesting all those requirements.
To sum things up: Measure the time the requirement was worked on.
I'm afraid that the currently available tools cannot give you the data you are looking for. If you run any checker on the code, it will tell you how complex the implementation is, but it won't tell you anything about the complexity of the requirement.
Here's a simple example. Let's say you have to group certain data by year and month in an ascending order:
ee.sort_by { |e| e.date }. group_by { |e| e.date.strftime("%B %Y") }
Or you can have a quite complex solution with several lines of code
# several lines of code
If you run any checker on the implementations, I'm pretty sure that the second one will be more complex than the first one, and this will give you a false positive result, because the requirement wasn't that difficult after all.
I suggest that you have a quick talk after the delivery of each requirement, where you compare the estimated efforts/complexity to the actual one and keep the result. When you have a new requirement, you compare this requirement to an already delivered one and use the result to set the efforts and difficulty of the new one.
We used the following approach: we created three groups: S, M, L and categorized our finished requirements into these groups by their complexity (result of a quick discussion). When we received a new requirement, we checked which group it fit into. Let's say the new one was an 'M'. After delivery we checked it again, and when it was still an 'M' we put it into the 'M' group, if not, we marked the change - e.g. 'M' -> 'S' - and put it into another group.
Two good indicators are:-
Effort Deviation (for the particular requirement) is one way to measure the complexity. (Schedule deviation may also be employed for similar purpose)
Requirement volatility is another good measure to understand the complexity of the requirement. The reason I say this is, the more volatile the requirement is that means the less we were able to understand it comprehensively.
Presumably a more complex product will require more iterations to "get right", so you may be able to get a rough idea of complexity by tracking the number and criticality of bugs in your code, the number and duration of iterations to resolve issues with the product, etc.
There are a number of caveats to this approach, some of which are:
EDIT: Oops, I didn't read the question properly the first time.
Measuring "difficultly" after the fact is simple if your developers log their time.
It is exactly proportional to the total amount of time spent implementing that particular requirement and any dependencies it spawned.
while others have mentioned it, I think time is truly the only measure you're going to be able to use.
You said you fist estimate the difficulty. So you'll compare estimated to actual.
Beyond that, I don't think there's really any way to reliably measure it. Difficulty is subjective. What's difficult for one may be simple for another.
The other issue is definition - how do you define difficult? What are the factors that would cause a requirement to look difficult? I know that in ranking projects on a complexity scale, many organizations factor in such things as environmental factors, political landscape, mgmt support, risk, external vendors, etc.
Before you try to measure anything other than time, you'll need to get that definition understood.
I suspect this is an X/Y Problem. In this particular case, the purpose of measuring the complexity retroactively seems like an attempt to solve "How accurate were the complexity estimates?" which is really yet another proxy for "How can I improve the accuracy of the team's estimates and/or the project plan?"
It seems like the real measurement ought to be the differential in estimated time vs. "wall clock" time, or changes in team velocity over time. Small deviations are a part of life; large deviations usually mean a problem with a hidden process or inaccurate estimates. Either way, if your estimates are consistently off, then there's a problem to be uncovered.
I believe the consensus is that the metric you're looking for is really a very subjective thing. However, that does not mean you cannot get the data you want. @Zsolt's suggestion to have a conversation with your team afterwards is definitely a great approach to getting that metric.
The piece I would more explicitly add to that idea is to include some notion of relative sizing into the process. You can read about that in detail many other places, including this article on AgileBOK.org.
30-second version... The idea is to take values from previous work and use those as data points to give a value to either estimated or just completed work. This can be done regardless of the measuring scale you use. The T-shirt size above is often used, but also some form of Fibonacci sequence is popular. It's best to look at the X most recent completed work items since the scale will tend to change over time... it's all relative anyway! :)
The teams I've used this tactic with have also experienced other benefits other than just recording a metric. I've actually seen these conversations have an even greater advantage of getting a team much more on the same page about the intended scope of work when using this method for estimation. After the work is completed, this is also a really good way to reflect on the work that was done with those involved and look for ways to be better in the future. Done well and consistently, those discussions can provide huge gains in improving the team while killing multiple birds at the same time.
While relative sizing is used a lot in the Agile realm, there's no reason why you can't use it in other environments/methodologies. After a while, you can then also layer those relative sizes over the actual time taken. That's when you can start using relative sizes as an estimation tool without asking people for "man-hour" type estimates that most people loathe doing and are rarely, if ever, within a desirable margin of error.
Hope that helps!
