by Chris Cardello on February 8, 2016

So you're in full-scale development on your app. Congratulations! Now you have a new problem: A huge pile of upcoming features, bugs and user requests. Wise prioritization is crucial to ensure you achieve your goals.

Here's the ideal flow of a new idea into your project:

1. Idea Curation: Management reviews research and metrics to determine which initiatives to pursue.
2. Marching orders: Product owners work with design, development, and project management to define how those initiatives will manifest themselves within the product.
3. Delivery: Those requirements are turned into functional features.

That's how everything is supposed to work, in a vacuum – ideas come in, they're defined, they're delivered, wash, rinse and repeat. Back in reality, though, there are typically multiple initiatives all coming at once, each of ostensibly equal importance. Throw bug fixes, maintenance, and minor enhancements to appease your user base into the mix, and you're at risk of nothing getting done on time at all.

Here at Hashrocket, we use the term "Epic" to refer to a collection of features which equal a fully functional enhancement to your application. An example of an epic would be "Customer Manages Payment Options". This epic could have individual features which support managing credit cards, managing addresses, loyalty options, default payment options, etc.

Find how each new idea and feature request fits into the big picture, and organize them into epics. Soon you'll have a much more manageable and shorter list of items to prioritize.

A workstream is a set of features within the same epic which can be worked in tandem with another set of features without interference. In the example above, managing addresses and implementing loyalty features could be two different workstreams in the "Customer Manages Payment Options" epic, as developers could potentially work on these two things independently without affecting each others' code.

There's one workstream that will always exist in some form: bugfixing. It’s always smart to have a developer (or a pair) dedicated to bugfixes and minor user-generated enhancement requests. Your userbase is your lifeblood, and when you can address their issues quickly, you'll increase their confidence in your product.

How do you allocate your developers across epics so that your goals are achieved in the shortest time possible? It'd be great to just assign everyone to the highest-priority epic, but reality rarely allows this. Typically there are 2-3 epics all of equal or close to equal priority, but now that we're thinking in terms of workstreams, we can identify which epics can support larger teams without conflict and overlap.

Your stakeholders, after all, are most interested in delivery of epics. Defining features at such a macro level enables you to set straightforward expectations with stakeholders to ensure they know the estimated timeline for delivery.

If you don't have the staff to support all of your desired workstreams and bugfixes in tandem, try to schedule in terms of 'dedicated days'. For example, feature work gets done on Mondays, Tuesdays, and Wednesdays, with production support, hotfixes, deploys, etc. happening on Thursdays and Fridays.

Endless tinkering has been the death of far too many companies. I’m all for being agile, and am a big proponent of being able to switch gears and focus at a moment's notice, but even the best-laid plans can devolve into chaos when unanticipated scope is introduced. There's something to be said for making a plan and sticking with it, and there's nothing unhealthier for an application than having multiple features started and unfinished because priorities changed too often.

Make sure any added features will directly support your value proposition, and do not interfere with an active work stream. Vet any new ideas without development effort whenever possible. If the new idea is a design or user experience change, build it out in a clickable prototype outside of the app so you can get a feel for the change without having to actually implement features and disrupt your existing workstream. For high-risk features, timebox and research implementation prior to moving directly to development so that you can get feel for the time investment required.

Never underestimate the cost of switching context. Whenever a developer is hopping from one epic to another, or moving from support to feature work and back again, there is an inherent loss of efficiency. If you stay focused, you'll build momentum, and disrupting that momentum by making people move back and forth across areas of responsibility will negatively impact delivery.

After all, it boils down to this: people can only work on one thing at a time, so pick that thing wisely.