For me it was about making a game from start to finish, and adding in a new feature every time. So it would have a start screen, basic menu,  a final level, a win screen and a way to restart. The first few games I wrote did not have a save, but they were short enough that someone could play it through in a single session. They had at least 10 levels, and it takes about 2-3 minutes to complete a level and two to three difficulty settings so that there was replay ability.  Every game was a little longer, had more options etc.   

With an adventure game - work on how many scenes, or how many interactions, so consider each scene a level, and how long the player is going to walk around for i.e. how big the scene is and how much dialogue there is.  It's also something you learn with experience - you need to first create a playable scene and then time yourself - if it's taking you 10 seconds or 10 minutes, there's a problem.  (the first is too short - put more obstacles in the way, the latter is too long - players will get bored, have more scene changes.)  

My criteria for free games is that it should not take someone longer to find, download and install the game than to play it. And it should be a game they can replay to make it worth their while i.e. it will be different next time because of random elements. (That's a little harder to do in adventure games.)

My personal criteria for the the paid games I develop is that it should be at least 5 hours of game play (which includes reading the stories - those that have them in) - to justify the price. (That's more or less the benchmark for casual games - I read a lot of forums / reviews to get a feel for what people liked / disliked - and below that benchmark people often ask for their money back - longer than that adds more value, you can charge more or they feel that they are getting good value for money - this is at the $2.99 - $6.99 price point.) 

You can find good quality adventure games here (free) that will give you an idea. 

If you don't mind me asking, I'm curious about my next questions because it's nice to get some experience in knowing the way that other people work on their projects. When you spent 1-2 weeks developing your games, How many days do you think you worked on it in a week, and for about how many hours per day?  One of the reasons I am curious is because I generally only have time during the weekend to work on my games and I feel that may be slowing down my progress.

I work full-time but don't have many demands on my time outside of that.  Most of these were made for game jams, so I worked more intensely on them then I otherwise would have, probably a couple hours a night on weeknights and more on the weekends.  They would probably have taken 3-4 weekends to complete if I were only working on them then.  I also can't keep up a jam pace of development indefinitely, so this time frame doesn't necessarily scale up for larger games.  Note that these aren't extensively-polished games with full option menus and such; they were made quickly to a minimal standard, and I moved on after finishing them.

Something else that interests me is that you said you made an RPG game in two months. I don't generally play RPG games so forgive me if I'm way off... But when I think of RPG games I imagine them including Inventories, characters, missions, maps, maybe some animals, a storyline, interactions, music, rewards, save points, etc... And while all of these things can be cut down — for example maybe the game only has 1 map instead of 5 — It is not much different from what I'm trying to achieve. Perhaps I'm just slower lol, but what do you think helped you to efficiently develop those aspects of the game? and Also what did your "bare-bones" game include or not include that made the initial development phase quicker? 

The game is a traditional dungeon crawl, so I asked myself, what does a dungeon crawl really need and what can I do without?  Thinking about what worked in the classic games was helpful here.  Graphics are low-resolution, largely iconographic, and all flat images / sprites that I could draw fairly quickly.  You control five characters, but they are predefined, not custom.  Combat is turn-based against up to ten enemies at once.  Stats and skills are very simple and balance is hand-tailored to this scenario; it is not a full-fledged and fully-scalable system.  There is basic equipment and inventory, but only static NPC interaction, no shop feature, and no "side quests" as such.  The game world is small - five dungeon levels, each a 12x12 grid, and your objective is to explore them all and overcome the challenges presented in each, ending with a final boss.  The game being built on a grid made it easy to rapidly snap dungeon geometry and events into place.  There are save/load and automap features.  I wrote a post-mortem where I talk about some of these decisions and fitting the work into the allotted time frame.

Turn-based combat in particular appears straightforward, and it some ways it is, but it also demands a lot of menu programming and a strictly-controlled cadence of play and visual feedback.  This can be considerably more time-consuming to implement than, say, moving a fireball across the screen each frame and checking for collisions (unless maybe you're working from scratch and haven't implemented a collision API at all yet).

If your objective is just to tinker and play with code, then it doesn't really matter how you spend your time, but if your objective is to ship the game, the key is really to nail down your scope early and try not to get sidetracked adding stuff that might be cool, but isn't really important.  You can always add that stuff in the sequel.  As hobbyists, it is crucial to not let ourselves get carried away, because we can only do one thing at a time.

Also, know when good enough is good enough.  That goes for both game design and code architecture.  Don't spend time significantly refactoring code unless doing so will really save you time later.  Otherwise, save it for the next game.  It is much easier to declare a feature complete if you know when to stop.  I learn better practices and techniques with each game I complete, and since my next game is also an RPG, it is built directly on the framework I created for the last one.  I can now make something bigger and better, with new features, improved workflow, and enhanced playability, while also having shipped a complete game in the mean time.  Shipping is good for motivation.

I find it helpful to design things on paper first.  Whether it is a complex algorithm, a dungeon map, a statistical formula, a monster's behavior script, a gameplay feature or whatever else, I get my clipboard and sit in my bedroom for a while to work it out.  This eliminates the distraction of the IDE and level editor and lets me focus entirely on creating or problem-solving.  Then when I come back to the computer, it is much easier to implement the design I have settled on.