Pruning issues and the idle bin
Part of the job of a product owner is to pay attention to the list of issues in the issue tracker. Not just to get a feeling for the cadence of the project, but to have an impact on its direction.
Paying attention to the issues doesn’t mean just tracking down what bugs are still opened, mind. Consider the case of a product owner with the release due date looming over the horizon, you need to start looking at the list of remaining issues and take active steps to make sure that you are going to get done more or less on time.
The usual rules apply, chose any 2 of:
In other words, your team can deliver more features in time, if you are willing to sacrifice quality. On the other hand, they can keep high quality and the same number of features, but the due date will have to move.
As an aside, it is possible to get all three of these aspects at once, but only for a very short amount of time (few days to a week or two at most), but at a very high long term cost.
One of the things that I observed is that in some cases, a lot of complexity and work is in the last 2% of work, where all the the polish work and rough edge cases lurks. In some respects, this is actually a really good thing. Because it gives the product owner the chance to remove features that won’t usually have an explicit impact on the users. A good example for this in RavenDB would be the amount of time and effort we put into the intellisense feature of RQL queries in the studio. That falls under the Nice To Have set of features. It is unlikely that we’ll get many upset users if the intellisense isn’t up to part with something like Visual Studio or ReSharper, so beyond getting some basic functionality right, we can defer improvements there if we don’t have the extra capacity to complete this by the expected date.
I’m sure that you can think of other examples in your own projects. Note that this require you to understand what exactly your users are valuing your software for. In the case of RavenDB, adding more query functionality and speeding up overall system performance ranks much higher than adding extra smarts to intellisense that is mostly used during exploration / demos.
On the other hand, the effect of the pushing such features down the road accumulate over time. In other words, if you keep your priorities straight and select which features should go into the product, you will defer the small fries over and over. At some point, you’ll need to make a decision about them. You can either decide that they don’t make sense anymore or they are never really going to be important enough to actually put in the “let’s get this done” queue.
Alternatively, you might want to put them in the idle bin. In other words, whenever you have an idle portion in your development, you can peek into the idle bin and get some tasks from there. That is also a good place to have a new team member start from. These are tasks that are minor and not that important, after all, so they can use that to learn the codebase. In fact, we have used this in the past as the tasks bin for interns. That is usually a really good fit, for the same reason that they are good tasks for a new team member with the added benefits that they are usually well scoped and if the intern messes up, you didn’t lose too much.
Regardless, the idle bin notion is important, because otherwise your future tasks queue is going to grow larger and larger, and it will be ever harder to figure out what tasks actually matter.
Excuse the semi-rant here. In my situation (financial industry) the choice is between regulatory requirements and "nice-to-have", the latter in our case often being a feature that will save a day's manual work. Faced with a FINRA or SEC fine of 1 or 2 mil versus keeping 4 or 5 people paid to keep doing manual stuff it makes sense to devote resources to the former. I get forwarded stuff like https://www.finra.org/sites/default/files/notice_doc_file_ref/Regulatory-Notice-16-31.pdf that I have to turn into a spec (imagine sitting in meetings with users over months trying to parse the doc) and then into code and then into working UI. Multiply this by 20 and you can rightly assume my UIs are function over form.
Peter, Actually, that is a pretty good example. You have here a document from Aug 16, talking about changes in Dec 16 and Dec 17. Now, obviously what will happen, as we recently saw with GPDR, is that everyone will only act on Nov 17 at best on that.
However, the key concept is the same. The product owner gets to prioritize the work, and need to see how far they can push unnecessary changes. And in some environment, the regulatory authority gets to make that decision for you. That ends up requiring either a larger team size or a focus on stream lining this.
That is _annoying_, absolutely, but take into account that I gave the UI example because it is easy to relate to. In the same manner, we prioritize setup procedure for a few well define paths and ignore everything else for a completely manual setup process. Or only support specific platforms, etc.