… something more on business value, stories and prioritisation
In my previous post, here, I wrote about Allan Kelly’s first two workshops I attended.
This post describes the second two workshops and some final observations.
Workshop 3: How do you value a story?
The third workshop contained one of my major memories of the course.
As a developer there’s been plenty of times where we’ve been asked ‘how long will it take to do this epic/story/feature/task?’. One of the *better* ways to answer this is to *estimate* by play Planning Poker.
This is where everyone in the team votes using a set of cards numbered with the Fibonnaci series (often rounded off for bigger numbers) eg 1, 2, 3, 5, 8, 13, 20, 40, 100. Stories you should consider doing should be no larger than 13 as an exception, and preferably 8.
There are a number of ways this can go wrong, firstly, developers are rubbish at estimating (simple things can take ages, sometimes what looks like a large change can turn out no work at all). Secondly, when estimates are given, they magically turn into cast-iron commitments.
Thirdly, and I have seen this, having gone through the whole process and come up with an estimate of 9 months for all the work described, we were told “the business isn’t going to like that, can we call it 6?”. As it happened, 9 months was actually a very good estimate, but we missed the 6 month deadline.
So, I digress, but what made it memorable was, we, playing the role of a group of Product Managers were asked to *estimate* the relative value of a list of features. And in being cornered into doing these estimates, all the reasons that developers don’t like being made to estimate were given as reasons that Product Managers shouldn’t have to do this sort of thing either.
When the boot is on the other foot...
So the point of the exercise was to crowd-source an estimated value for a list of features. This was done in arbitrary currency, and may have well been Bells. The absolute value (in an arbitrary currency) is irrelevant, but it gives you a list of values relative to each other, on which you can start to make prioritisation decisions.
So, you have a list of features, or groups of features you think might be useful. How do you decide which is the most important epic to do? This value estimation ‘game’ can inform that decision.
In the absence of detailed user research, which has time and cost implication in itself, and may or may not be the right thing to do, Business Value estimation at least allows you to start getting feedback quickly by identifying what you *think* the most valuable feature is and allow experiments around that.
Workshop 4: Prioritising in face of constraints?
Deadlines are often quite elastic (more sadlines), indeed I’ve recently used the term flexline for one particular requirement, it is rare they are binary — perhaps a legal requirement might make it so — so the value you might derive from a particular feature being available may decrease over time but not fall to zero straight away (launching on a Friday instead of the Monday before, for example).
It’s only a “deadline” if your project will die failing to meet it. Otherwise it’s just a sadline. I’m going to call them that from now on. — Liz Keogh (@lunivore)
So the value of work often decreases over time; it rarely increases, though you do hear of things that were too early to market.
An example may be hitting the Christmas market, the realisable value of sales will reduce the closer to Christmas a feature or product is available, up to the day itself. But if it gets too close there will be little point in doing the work; so if you haven’t started the work early enough, it may worth investing in something else — consider the Opportunity Cost of not doing something else.
Remember also that however long you think implementing a feature will take, an estimate is just that; the chance of it overrunning is high, and what does that do to your expected returns?
The reference text on this, though not the most approachable, is of course Donald Reinertsen’s The Principles of Product Development Flow, and this particular topic is describing Cost of Delay.
Allan ran a really good exercise with us to see the effect of prioritising work in different orders, and even more so with the effect of overruns (which *do* happen).
A few years ago I had the privilege of attending a workshop at Agile in the City: Bristol by the late, much missed, Martin Burns, looking at the Cost of Delay, and specifically Weighted Shortest Job First (WSJF) — which I’ll sum up as don’t let the big things block the small things getting through (as the analogy goes, if you fill a pint glass with big rocks, there’s still room for beer, or is it sand?) — if the bug is trivial to fix (and annoys a lot of users), just fix it.
Sign yourself up
Overall, I can highly recommend Allan’s workshops — I believe he’s now split the course into two, making attendance an even easier decision. And I note he was providing spaces for those that had been furloughed.
Attendee’s from conferences he’s spoken at will be familiar with some of the content, but here you get the full picture and participate in some thought-provoking exercises.
As I’ve also already said, this is a useful course whether you’re a Product Manager or not; as a developer (or anything else) seeing a different perspective adds *so* much and gets you out of your box.
