OK, you are right, if we look at it as a short informal strategy, it is great, although it differs from my strategy (but not too much):
0) I start testing in parallel to getting the "realistic" workload defined which typically take time and is never exact.
I perform steps as described above for any script I could create until I got the the realistic workload defined which for sure is the ultimate goal. Then I repeat those for the defined most typical scenarios and defined percentage:
1) I do run slow rump-up in order to draw chart: how response times/utilization/throughput changes as more and more users are added. My rule of thumb is new user starts within about half a scenario time (once started in cycles forever until I stop all of them).
2) Once I did “1)” I know the knee load, I run new test with fast rump-up and load about 90% of knee. Run for half an hour to get averages. I define this load as capacity and the write down the average response times. I describe to stakeholders that beyond defined capacity response times will start to increase dramatically.
3) I run stress tests creating a huge load and then reducing it to the same 90% of knee. I see if system is able to stabilize and come up to the same response times/utilization as in test at 3)
4) Run the same load 90% of knee over weekend