Skip to main content

10 things to help you suck less in prioritisation


Improvements in how things are being done don't help that much if you are doing the wrong things.

Focusing on cutting down the deployment/production pipeline, using the latest and greatest languages and tools, exploratory testing, mob programming, etc will surely be a boost to efficiency. But efficiency is not key if you are doing the wrong things.

And quite often we are.

And a big reason for that is, that we suck at prioritisation. We suck at it because we:
- spend too little time on it: "But we could save minutes of talking by hours of coding!"
- do it too rarely: "Welcome to our annual roadmap revision meeting."
- try to have specific people/roles be responsible for it: "Ask the PO..."
- do not think about different dimensions enough: "But the customer needs it!"

But mainly we suck at it because it is so hard.

Here tho is list of 10 things I think might help.

1. Don't keep a big backlog. Focus on the things being done now, and on the few things to do next. Forget the rest.
2. Do not rank things with labels, instead just rank them in an order. We all have seen too many priority1 projects..
3. It's ok and good to have visions and high level plans for longer times. But don't put them on a "roadmap" and then forcefully execute that.
4. Avoid long and seldom happening prioritisation meetings. Instead prioritise often and ad-hoc.
5. The value is in the idea, not in who presents the idea. Let the ideas compete, not the people.
6. Do not only consider the cost to build, but also the cost of delay (how much do we lose or not gain while this is not done, opportunity cost (what else could we be doing instead of this), cost to maintain, etc
7. Do not only consider the value to customer but also team motivation & wellbeing, code and system infrastructure simplicity, brand, support, relationships between stakeholders, etc
8. Involve everyone to prioritisation. It's hard. It's messy. It's important.
9. Try to get everyone to understand why we decide what we decide. Not everyone needs to agree, but understanding is very important.
10. Look back at the good&bad decisions. What helped you to select the right thing back then? Why the hell did we end up doing that?

Why ten? It sounds nice, fits into a board made of stone, and because this post was very late already due to some bad prioritisation.

I'll try to do better next week..

Comments

Popular posts from this blog

Testers doing test automation - is that the most important thing for you to do right now?

I've been thinking quite a lot about tester's moving to do test automation.  Lately beause of these three things: 1.  European testing conference , a great testing conference I attended couple of weeks ago. It is very cool due to many things; the way the speakers get compensated, the focus on the conferring side of conferences making it very easy for people to discuss stuff, the way the talks are chosen, and because there are also a lot of developers joining. So anyway when I was talking with several of the attendees, it was a bit strange how it was easier for me to talk about the product development as a whole with the developers, where as with the testers it more naturally moved into talk of automation and tools. Also on the open space, I think the majority of the topics pitched was automation or tool related. And quite little on the process or on the customer facing side of product development.  2. In my company there are a lot of different products and...

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.

Six reasons why testers should do code reviews

I have had quite a lot of discussions about code reviews. Quite many also with testers, by which I have understood that many do not do those. I will not start arguing here on whether code reviews are good/important or not. But I will list a few things why I think testers would benefit of doing them. 1. Code is the only documentation that is up to date . If you really want to know how something really functions, you want to be able to see and read the code. 2. Knowing more about the thing done enables you to do better testing . You can spot things that you should definitely test, and things that you probably don't need to test that much. Like extra things added by coder, usage&modifications of existing functions, data types, etc. And to arguments thinking that one loses their "independence" as a tester by knowing too much, I would worry a lot less about that than about testing stuff that you have no idea on how it has been built. 3. Improve logging . I obse...