Does adding more bandwidth solve issues of jitter and latency?

In short, what you are going to hear from any competent consultant is: No. Both Jitter and Latency are intermittent issues that can't be addressed by throwing bandwidth at the problem. Although a lack of bandwidth can definitely affect call quality the single most important factor in high quality voice over an IP network is Quality of Service (QoS).

QoS should be provisioned to provide voice with the highest throughput and availability at EVERY layer of your network. On the switched/LAN portion of your network the best practice is to create a Virtual LAN (VLAN) strictly for voice and to give that VLAN the highest priority through your switches. At the WAN level your routers should be programmed to use Class-Based Fair Weighted Queuing with Low-Latency Queuing or another similar prioritization scheme to ensure that voice gets priority on the network.

Finally, you need a WAN infrastructure that actually recognizes these protocols. A private network (Frame Relay, Point-to-Point, MPLS, etc.) is a must. Too many times I have seen companies try to shortcut the WAN by running a Virtual Private Network over the Internet (for example). This destroys all of the work you've done to prioritize your voice traffic by falling back to a best efforts network (I'll get it there when it gets there) like the Internet.

I like to explain this like lines in a Grocery Store. Adding bandwidth is like adding more checkers at the counter. You will get through the checkout faster with more checkers. However, if there is still a wait at each counter, you will still have issue. For QOS, you need a policy that says anyone buying milk automatically gets to jump to the front of the line, and get serviced immediately. If they have to wait, you will no doubt have issues.

In many cases today, I am deploying VOIP with less bandwidth. Odd I know, but it works. Rather than trying to manage a 80k packet through a 10MB, 100MB, or 1000MB connection with the rest of the high bandwidth hog applications that don't care about real time delivey, we use a product that basically deploys VOIP over the separate Voice cabling in most buildings. The product, Phybridge, uses a DSLAM in place of a POE Switch, at roughly the same cost, and a DSL router with POE at the actual phone location. This provides 25MB down, and 1.5MB up for a phone that only required about 80K.

The real benefit is we remove the QOS issues from this part of the network, and have just one point where we need to apply it, where it connects to the rest of the data network. It has proven to be an extremely reliable method of deploying VOIP networks. IN the example used in this answer with the Grocery Stores, this is like opening a series of Counters for checkout that are only for Milk - dedicated Bandwidth for Voice, using IP, with interconnection to the rest of the network for the enhanced services that require it.

Bandwidth capacity is only one factor that impacts call quality. To Derek's point, a QOS solution is really the only way to maintain voice quality. Some voice/data consultants can successfully shortcut a true QOS solution by dedicating access to voice traffic or balancing the volume of call data against the throughput of the access. When you have dynamic access a QOS solution and adequate bandwidth to meet acceptible levels of data traffic are required to minimize call quality issues.

I totally agree with Derek. The unique alternative to QoS management is to use separate connections between real time services (VoIP, FoIP, Video Conference, etc.) and other services. The choice tipically depends on the traffic volumes and costs.
Regarding QoS and Traffic Shaping I suggest to make attention to the performance of the tool used because many routers can't support huge amount of traffic with a good level of QoS management.

I think this has really been answered above (Jim's response is great). What you also need to consider is that jitter can be caused by many aspects of a given solution. If you consider that a voice call begins on a desk (handset or soft client) and then across a switched infrastructure, to a gateway, through a router, across a WAN and then through to a destination. At any point jitter could be an issue - ensuring the router has enough CPU cycles or simply that your soft client isn't running on an old, slow PC etc. The WAN is often the issue depending on which provider you're with, the distance and quality of the circuit. At the end of the day you could have a 2.5GB wave length to yourself but if one part of the component is weak, it makes no odds how much bandwidth you have.

Many links to making a successful VoIP call. Bandwidth is one large component of the equation. However, you are only as strong as your weakest link. Lots of bandwidth will not solve the problem unless everything else is on a par (I.E.: QoS routers, switches, LAN, WAN, cabling, etc.).

I didn't see anyone mention that G.729 calls consume less than 30kbps. This is a miniscule amount of data for network links today, so unless you are handling hundreds of concurrent calls or using the link for a high bandwidth application already, bandwidth should not be your issue, and adding bandwidth will not solve latency and jitter problems. Latency and jitter are caused by traffic through transient equipment issues. Bandwidth may help you push more traffic through the pipe, but equipment can still cause latency and jitter. QOS offers the best solution to handle these anomalies as it moves the high priority traffic up to the front of any slow lines (i.e.; queus). For a great lesson on Basic QOS and methodology, I recommend http://blog.humanmodem.com/?p=104