… something on business value, stories and prioritisation

I have recently taken the opportunity of participating in Allan Kelly’s online workshops on Stories & Value.

I’ve seen a few talks by Allan at various conferences around the UK, and had seen some of the material before, but I found it really insightful, with each week building on the previous.

This was near the beginning of the Covid-19 Pandemic, and Allan was trying out his training in a Virtual form, so Allan was experimenting with the format and technology.

Whilst not a Product Manager myself, I try to take an interest to see the bigger picture and understand the thinking and supporting tools. This course really helped me tie lots of different things together, and has led me to focus even more on delivering value and quickly and incrementally as possible.

Workshop 1: How do you price work?

The first workshop was on how we value the work we do, primarily in this case through the prism of bidding for some work.

For this workshop, after some initial scene setting and overview we were split in to smaller groups and asked to bid for some work. The groups were given slightly different scenarios, but the exercise drew out a few things:

• do you price to how much it will cost to do? Do you add in a certain profit margin?
• do you price to what the customer can afford? If you happen to know there is a budget of a million, do you try to grab all of it?
• do you price to what you think, or are told, what the going rate is for the industry
• do you price to make sure you win the work? my group went with the smallest amount of work possible to do a ‘Proof of Concept’ to establish a relationship so be in a position to win further work.

When pricing work it is essential to understand what assumptions, and biases, you have baked into your thinking. Whilst it can feel very clever to ‘read between the lines’, great danger awaits if you misread between the lines.

assumptions, assumptions, assumptions

Workshop 2: What is a story

The second workshop looked into what a story might be.

Most people are familiar with the format of:

As a… role or persona
I want to… do something
So that… objective

A story should have business benefit or you shouldn’t be doing it.

It is also important that there is someone definite in the role or persona, the more specific the better, otherwise the benefit may be lost, or the scope blown, by trying to please everyone in one go.

No matter how good your stories are, any sort of story is “a placeholder for a conversation”. This is partly because it is so easy to make assumptions about or misunderstand about a written specification, but also because time and requirements move on, and a quick conversation can ensure the story is still relevant.

All sins are forgiven if you have the conversation — Allan Kelly

So, roughly, there are three sizes of ‘things’ that you might work to deliver. To use a Goldilocks analogy, there are things that are too hot (big), things that are too cold (small), and things that are just right.

Epic — has business value but too big to deliver in one go (noting that, as Allan Kelly says, software has diseconomies of scale)

Software has diseconomies of scale — Allan Kelly

Story —ideally represents the smallest amount of work that can deliver business value. Should have a number of ways to solve. A placeholder for a conversation. A story should include everything needed to deliver some value, so should be end-to end; there should not be separate front end or back end stories. It can however be as thin as possible through the stack.

Even if a story does feel story size, always take the opportunity to break down in to smaller stories and descope if you can; this will move you towards Continuous Delivery of incremental value.

A story should not take longer than a week to deliver. In Allan’s eyes “Every story is an Epic until proven innocent”.

Task — Won’t deliver business value by itself, but is the thing you need to do to deliver a story. Ideally there are still different ways of achieving, but may only be one. At this point you may have a ‘back end’ task (adding the business logic) and a ‘front end’ task (adding the button so you can use the new functionality), but again, keep the scope as small as possible.

A task should not take longer than a day ideally, interestingly, fitting in with the Trunk Based Development mantra.

Until next time…

In the next blog I’ll describe the second two workshops, I’ve mostly written it, but not quite finished, so in the spirit of incremental delivery, look out for the follow up….

And here it is:

… something more on business value, stories and prioritisation