The answer is that if you have a requirement to have contiguous ids, you should absolutely not use the IDENTITY features. It is designed to produce gaps. More precisely, it is designed to permit multiple processes inserting auto-numbered rows in parallel without having to wait to get the next id. This means that if one process is rolled back, the IDENTITY value that was assigned to it wil not be reused and there will be a gap. The reason you get this big jumps is that the IDENTITY value is only updated on disk only after each 1000 rows (depending on the data type). Again, this is for performance reasons.
Karen pointed you to a blog how you can change this. But please tell me, why would you press a go-slower button?
IF, and I said IF, you need contiguous numbers there are solutions. And, yes, such business requirements exists. I've worked with them myself. But it many cases, people just think it's for the sake of prettiness. And contiguous number will slow down parallel inserts. If you only want a surrogate keys, just accepts these gaps. The values does not mean anything anyway.