I would like to measure requirement volatility but the problem is that our specification is not consistent in size of requirements. Sometimes, one requirement describes a whole workflow. Sometimes it just states X=10. Would it make sense to still count them and track changes? Actually with those big requirements, the volatility will be higher (5 changes to 1 large requirement, which could be 5 changes to 5 requirements). So maybe it could help to visualize lack of granularity?
3 Answers
Right now I guess you know nothing (but perhaps have some hunch that there is a lot of volatility) - so any measurements you make will be an improvement. Unless you have lots of capacity to do a complex data capture / analysis, just do something simple -- and you will learn something, even if it is not 100% accurate.
To get started quickly and cheaply, I would recommend just counting changes per requirement, even if they do not all match in size. After a reasonable period of time if it turns out that the largest requirements have the most changes (which would not be a surprise) and you are struggling to infer anything from the data then you can think about whether it is worth putting a bit more refinement into it: the next refinement step might be to "T-shirt size" requirements, then you can look at stats for (say) the L and XL requirements and compare that to overall stats or for the M and S requirements.
You could then create some sort of "requirement volatility index" where you multiply number of changes by the requirement "size" (1, 2, 5, 10 for S, M, L, XL perhaps) and sum the products -- it won't be 100% spot-on but it will give you some visibility of the issue and it will be cheap.
Break the requirements down.
5 changes to 1 large requirement, which could be 5 changes to 5 requirements
You specify yourself an example of a big requirement made of 5 smaller requirements... so why not just treat it as 5 requirements?
Try to follow the INVEST mnemonic when creating/tracking requirements.
-
-
1@JohnV And? Is there some reason you can't then slice up those requirements (either on your own or collaboratively)?– SarovOct 9, 2018 at 15:53
-
We are talking about real world, you cannot do that for free or on your own account...– John VOct 10, 2018 at 6:40
-
1@JohnV "on your own account" - I disagree. What does the client care about how you visualize/deconstruct requirements, as long as their requirements get done? You can always track them separately, if necessary, and record that 'Story 27 is part of Requirement 8'. "cannot do that for free" - True, but the same can be said for measuring. By that logic, since you can't measure velocity for free, why bother?– SarovOct 10, 2018 at 13:10
-
1@JohnV If a lot of effort is needed to understand a requirement enough to split it, then you absolutely must put in that effort anyway because working on requirements that are completely not understood is not a good place to be...– SarovOct 12, 2018 at 15:40
I would start with a visual analysis. Bin the requirements by size (tshirt or similar), then plot (x=size, y=Nchanges) for each requirement.
The resulting plot will convey any interesting or surprising trends, and you can figure out how to reduce it to scalars if you need to do a more quantitative analysis.
