i most certainly am not an expert on data compression, but i can see a fairly simple method that would shrink it a bit.

At present, each pixel is represented in the data by two bits (one to determine if the back buffer is set or reset, and one for the front buffer, yes?). Well, it looks like, in your image here, you have quite a bit of horizontal colour repetition, meaning a form of rle wouldn't be all that bad. The method I was thinking of would ascribe four bits to each pixel, the first two to determine colour and the next two to hold the number of pixels in a row of the same colour(1-4). This means that, although the data representing a single pixel is doubled, the data representing four contiguous pixels of the same colour is halved.
currently, your sprite takes up 256 bytes of data, but using this method it would be compressed to 241.5. Obviously, it's not a huge decrease(5.6%), and it may not work even this well for your larger sprites, but it's an idea.
Another possibility is, if large sections of white space are a common theme in your sprites, using this method only for white pixels and leaving other colours to the two bit method, or even using the method for every colour but black, which seems to show up mostly in a single pixel wide, form-defining barrier around the outside of your sprites and not in large areas. I don't feel like calculating these by hand right now, but I think compressing only white is the method most likely to work best on this bulbasaur.

or maybe one could exclude the surrounding white pixels altogether?
Because there is a border of white pixels surrounding everything that is drawn, maybe one could begin the data for each line with a five bit string dictating where to start drawing pixels that aren't white(meaning that any intro stretch of more than two white pixels would yield saved space)?
This on it's own, even if you kept the two bit method for the remainder of each line past that, would shrink your bulbasaur to 208.25 bytes(an 18.6% decrease).