The earlier the business, the less data you have. Frustratingly, that's also where your risk of failing is the highest.

Figuring out what to work on is both the hardest and most rewarding challenge. And gleaning the path from everyones crystal ball can be a mixed bag, more so as the user-community and offered services grow. Add in partners, investors, and teammates of varying backgrounds, and it becomes clear that alignment itself requires some level of dedicated attention.

This is where adding business value points as part of your process can shed some of that much needed light.

In agile methods, developers give point values, usually integers, as a simple and effective way to conceptualize 'how much work' is in front of them, ie. the chunks.

Pointing business value is a similar practice, only instead of roughly estimating effort and complexity with simple integers, you roughly estimate the business value generated, where business value = impact to the business.

i know... Value is subjective and this sounds like a nightmare to get right. Like story points, though, they don't necessarily have to be right to help your team. The practice of trying is where they shine most. And as you continue the numbers will have a more reliable meaning with a richer history of what did and did not work out as planned.

Imagine a large backlog of ideas, complaints, stories, etc...

Maybe members of the customer-success team will place a high value on features that alleviate frustration in the UX, eg. bug fixes, tours, etc.. Maybe engineers will place a high value on items that simplify complex parts of the codebase. And maybe the CEO will place a high value on enabling a new partnership through an API integration. They are all important in one way or another. But if your company is not WeWork or Uber, thinking that way can cause some serious problems.

There's just not enough time for everything to be equally important. And living this fantasy for too long can be dangerous as saying "yes" too quickly can become part of your companies culture.

In a nutshell, you're almost always tasked with working towards alignment on what to do with the time and money you have.  This can feel like a very not-so-fun amount of saying "No".

Pointing stories by business value is a quick and open way build-in regular discussions about the things that make the business model work, and scale the desire and judgement to make improvements.

Every task at every business should relate to these concerns in some way. The more we share understanding of how tasks relate, the more vital tasks can be done with fluidity and team buy-in, and without the unhealthy friction that comes with siloed concerns.

Fibonacci story points: 1,2,3,5,8

Fibonacci is an agile favorite because the 5 and 8 on the higher end leave room for the unknowns that come w/ larger stories and 8 is a reasonably manageable maximum for most work-flows.

Points give us a simple estimation tool that sums up into a reliable velocity we can plan with.

In other words, with points we can say things like: we do an average of 20-25 every two weeks; we shouldn't do two 8-pointers in the same sprint; after breaking that project plan up and pointing it should be about 4 months of work; with bob on vacation we should only plan about 15 points, etc...

Business value points add another dimension, enabling a measurement of the quality of effort. In a great article from 2010, Elena Yatceck at Thoughtworks succinctly makes this case:

"If you were CEO of your company and you were being briefed on your project every two weeks, what do you want to hear from your agile team?
"We delivered 14 value points this iteration" (which translates into some specific thing the company values, in terms of cost avoidance, expected revenue within a portfolio, increased quality, or faster time to market)
"We delivered 14 story points this iteration" (which translates directly into "2 weeks of effort")

Have you ever played planning poker?

As simple as integers can be, it's not always easy to get right. One of the harder problems dev teams face while pointing stories is avoiding group-think. This becomes even more of a challenge when predicting business value which can seem even more ambiguous.

The first person to say something like, "oh, that's a 2 pointer", often anchors the opinions of others. Some may nod in agreement too early, some may go full-on-contrarian, 5 points!  Maybe 3 points is right? Who knows.

So how to get impartial opinions from our easily-swayable-glass-half-full-half-empty minds?

Enter planning poker: Everyone closes their eyes, puts up point estimates (with fingers), then re-open all at once.  that's where it starts to get interesting.

The higher estimates are explained, same with the lower, and truth come out. Some where in there is a most-likely-scenario that the team can feel good about.

Give it a try!

It's quick, easy and often pretty funny. It can be added, adhoc, into any prioritization or grooming discussion. Just don't forget to give space for everyone, especially outliers, to make their case. And if you'd like a head start on accuracy, you can always have a pointing session on past work to get your team oriented.

Most importantly, keep it casual and have fun. It doesn't have to be right, just exploratory. the bigger win is building a value discussion into your process so your team can grow with more alignment.

You may be surprised at how different the opinions are, and how much they change after some discussion.