Value and effort and prioritisation

Every sprint, Neontribe’s developers are faced with a stack of work, in an order. Every sprint, we start with work from the top of the stack, and carry on until the sprint finishes.

We order this stack using Vs and Es; rough ideas of the Value and Effort of a piece of work. Normally, these pieces of work at least start as user stories; value we are delivering to a user of the software we’re creating. Every piece of work will start with one to three Vs and one to three Es.

(V) means the team believes a user story is Valuable to the project. It is Valuable enough to include, and helps the project meet its objectives in the light of the user research. If a user story is without Value, it has no place in the software the project delivers.

(VV) means the team believes a user story is Very Valuable to the project. It is more Valuable than a user story which is just Valuable.

(VVV) means the team believes a user story is Very Very Valuable to the project. It is more Valuable than a user story which is simply Very Valuable.

(VVVV) is not an acceptable value; it probably means there’s something epic there that needs to be shattered into smaller tasks.

These assessments of Value are used to help prioritise user stories. The more Valuable a user story is, the more likely it is to be included in the software the project eventually delivers but it’s the product owner’s call. Value gives us a good first stab at prioritisation, which we then consider again when we know more about Effort.

(E) means a user story will take some Effort. Any user story needs design thinking, coding, testing and some discussions to deliver. No user story, however seemingly trivial, is without effort to finish to a satisfactory level of quality. A developer who gives a story an E probably knows exactly how to do it and that it’ll be only a few lines of code.

(EE) means a user story will take Extra Effort. It's more work than a user story that only takes Effort, but less than one which takes Extra Extra effort. It’s likely a developer who gives a story an EE will have a pretty good idea how to do it but it's more than a few lines of code.

(EEE) means a user story will take Extra Extra Effort. This has some relationship to time, but it's not a linear quantity. Perhaps there's a complexity to the coding which will require time to work out the best way of doing the programming, perhaps it's simply a lot of code to write, perhaps there's no existing open source code which provides just the right solution to the problem, or just the right behaviour for the design that's been tested as the best solution to our users' problem.

These measures of effort are as close as we ever get to estimates. In our experience, the only way of estimating precisely how long a feature or piece of design will take to code is to actually do the work. In general, however, the more effort, the more time it'll take. It's likely that the level of effort has some relationship to the value of the story, but that's not always the case.

It must not be the case that all user stories are deemed to have the same Value and the same Effort. The reason we do any of this is to be able to prioritise work for a sprint which we’ll get through in a ranked order. As developers, we don’t mind what order we end up with, as long as the team understands the tradeoffs. That makes ranking a series of difficult decisions, and they end up with the product owner. We do start with a default though, just to have something to work on. We start with highest Value, lowest Effort and proceed from there.

You’ll have seen by now we really have no such thing as "Must Haves", just a prioritised list. At any time, a product owner can re-order the work in a sprint, and the only opportunity cost is the work already done on de-prioritised work. They're in control, they decide what's most important at any time.