Maybe this fits in that special category of simple concepts that are fiendishly difficult to actually achieve. All I want is a ‘Prioritised List of Features™’ to work on. It is vanishingly rare though, I think I have worked with one product person who could do this, but they were unceremoniously moved on for embarrassing everyone else.
A ‘Prioritised List of Features™’ is a list of the features we want to work on, in the order that it makes sense to work on them. Features could be new functionality, technical debt we want to do, operational improvements to monitoring. Whatever really.
As I sat in yet another meeting about how to deliver a ‘Prioritised List of Features™’ without actually knowing what the ‘Prioritised List of Features™’ actually are, my mind wandered back to the concept. I was going to say something but it seems so obvious. I often think that if I was a product person I’d have my ‘Prioritised List of Features TM’ ready at all times. I’m not though and there is more to it obviously than obsessing over a single list. I’m also wary of the trap of thinking I can do all the roles. I have recently been involved in drawing together a ‘Prioritised List of Features TM’ for a side project. It’s very difficult to be fair.
So what can the Quality Engineer do about this? I would say you can influence and facilitate, over being able to outright decide. I guess you could take over the the Product Owner or Manager role, that would be a great way to influence quality (as the product person should, more than most in my eyes be responsible for quality, they have many levers to pull) but that is unlikely. Prioritised is the key word here, as that the hard thing about the list. Or at least I hope most product people can do a list of features, but giving a hand with prioritising will be helpful.
You can size the features, which helps to prioritise, you might decide to tackle complex features first or last. Beware of estimation though, especially test estimation, which is the end of all sensible conversations. You can rank them, which helps with dependencies and value when features are compared to each other. You can use frameworks with silly names like WSJF and MoSCoW too if you want.
What I would actually advise, is to help the team discover the starting point and then figure the rest out later. Ask the question about where that starting point should be, effort expended in other directions increases the danger of maximising the amount of work done, aim to help the team do the right work in the right way.
The real magic of a ‘Prioritised List of Features™’ is that it should be short, with a well defined starting point.
Diagram Industries 