When implementing a new feature or reworking an existing feature it's very important to have a clear specification of what is expected at the finish. Some time initially working through rough designs and identifying any upcoming problems. It's important that you know what you are not trying to do as much as what you are trying to do. This can keep the development team focused on the objectives. It's also key to get something visible very quickly to the end user to make sure the development is what was envisaged at the start. The core features should always take preference so worse case scenario is you could ship a modified version of the core requirement, not perfect but good enough for now. Bells and whistles can come later if needed. You should always have a working system if you follow TDD correctly. It's important the development team know the end is near to keep motivation high, projects that drag on tend not to work out and appetite for future work diminishes. Break a big feature/problem into smaller features, work on the most important items and get those complete. Morale is high as progress is visible, small wins can be very powerful having a compound interest effect for exceeding expectations and future work.